From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
Date: Tue, 29 Oct 2019 17:48:14 +0100 [thread overview]
Message-ID: <7dc26dccaca7ab647c656c448ffa6a67875e2a03.camel@gentoo.org> (raw)
In-Reply-To: <20191028153440.GA15356@whubbs1.dev.av1.gaikai.org>
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
On Mon, 2019-10-28 at 10:34 -0500, William Hubbs wrote:
> On Mon, Oct 28, 2019 at 10:18:17AM +1300, Kent Fredric wrote:
> > On Sun, 27 Oct 2019 12:05:02 -0500
> > William Hubbs <williamh@gentoo.org> wrote:
> >
> > > If a build dep of something changes, the correct response with
> > > --with-bdeps=y is to rebuild everything that depends on the changed dep.
> >
> > Unfortunately, my learned experience of portage is the "correct
> > response" is not something portage wants to do on its own without hand
> > holding.
>
> One thing I've noticed is you say things that portage might do without
> giving any specifics.
>
> Let's go ahead and do the change and file bugs against portage if there
> are issues.
>
The whole point of PMS/EAPI is that we can rely on package managers
behaving reasonably for any input. Any package managers, in any
version.
You seem to be suggesting going in the opposite direction of making
newest Portage version handle bad input. Using old version? Tough
luck. Using another package manager? Tough luck. Not fitting
in narrow space of solutions currently hacked around? Tough luck.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
next prev parent reply other threads:[~2019-10-29 16:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 22:03 [gentoo-dev] RFC: cargo.eclass changes and virtual/cargo retirement Georgy Yakovlev
2019-10-25 22:03 ` [gentoo-dev] [PATCH 1/3] cargo.eclass: do not use virtual/cargo anymore Georgy Yakovlev
2019-10-25 22:03 ` [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual Georgy Yakovlev
2019-10-26 3:59 ` Kent Fredric
2019-10-26 4:24 ` Michael Everitt
2019-10-26 6:34 ` Francesco Riosa
2019-10-26 7:17 ` Kent Fredric
2019-10-26 9:14 ` Dirkjan Ochtman
2019-10-26 9:17 ` Michał Górny
2019-10-26 22:35 ` William Hubbs
2019-10-26 23:14 ` Michael Everitt
2019-10-26 23:55 ` William Hubbs
2019-10-27 1:42 ` Michael Everitt
2019-10-27 10:09 ` James Le Cuirot
2019-10-27 7:36 ` Kent Fredric
2019-10-27 17:05 ` William Hubbs
2019-10-27 21:18 ` Kent Fredric
2019-10-28 15:34 ` William Hubbs
2019-10-29 16:43 ` Kent Fredric
2019-10-29 16:48 ` Michał Górny [this message]
2019-10-29 17:27 ` William Hubbs
2019-10-30 8:19 ` Kent Fredric
2019-10-30 14:26 ` William Hubbs
2019-10-30 14:28 ` William Hubbs
2019-10-30 14:49 ` Kent Fredric
2019-10-30 15:52 ` William Hubbs
2019-10-30 20:49 ` Kent Fredric
2019-10-25 22:03 ` [gentoo-dev] [PATCH 3/3] cargo.eclass: use verbose cargo invocation Georgy Yakovlev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7dc26dccaca7ab647c656c448ffa6a67875e2a03.camel@gentoo.org \
--to=mgorny@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox