Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Wed, 30 Oct 2019 10:52:35 -0500 William Hubbs wrote: > If not, I would rather see you pick one of the two options above. -r1 bump all existing consumers of that eclass first? :) pgpOohqnJQZK6.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Thu, Oct 31, 2019 at 03:49:32AM +1300, Kent Fredric wrote: > On Wed, 30 Oct 2019 09:26:09 -0500 > William Hubbs wrote: > > > I don't know portage internals, so I have no idea what the deal with > > this is or how to fix it. > > > > Did you report it to the portage team? > > Report what? > > 1. Didn't have access to the box > 2. No way to even conceive of producing enough information to replicate > it reliably enough that somebody could anticipate digging into the why. > > > > > I've noticed it gets messy very quickly if you wait a while to upgrade > > your system also, so I would be curious how long the user waited to do > > an upgrade? > > And yeah, it was one of those cases of "bad sync length", the user in > question inherited the box from somebody else, and they were left to > pick up the pieces where the other person left off. > > And one of the common things I see that frustrates me, is generally, > when you see these mountains of mess, somebody tries to argue its the > *users* fault for not updating more frequently. > > But IMO, that's a rather distasteful buck-pass. > > The duty of a linux vendor/linux vendor maintainer is to isolate users > from these kinds of problems, and we're clearly failing in this way. > > > > Python is also more complex than most things because we allow multiple > > versions. > > > > There's no way to know whether removing virtual/rust will cause these > > kinds of issues, so I'm still not convinced that we shouldn't remove > > it. > > In light of the aforementioned axiom of "protect the user from messes", > I think it makes sense to approach this from the perspective of: > > If we imagine it could possibly cause a problem, until we prove it > doesn't and can't, we must assume it _will_ There are no ebuilds in the entire tree that directly depend on virtual/cargo; only cargo.eclass lists it directly. Because of that, There are two ways to get rid of virtual/cargo. 1. Apply the patches in this thread. 2. Create cargo-r1.eclass with the patches applied then move all consumers in the tree to it and remove cargo.eclass. The second option seems like overkill and would require a lot more work than the first, but it could be done. You are voicing concerns about either option, so is there a third option other than removing the dependencies from cargo.eclass and requiring the ebuilds to set their own dependencies? If not, I would rather see you pick one of the two options above. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Wed, 30 Oct 2019 09:26:09 -0500 William Hubbs wrote: > I don't know portage internals, so I have no idea what the deal with > this is or how to fix it. > > Did you report it to the portage team? Report what? 1. Didn't have access to the box 2. No way to even conceive of producing enough information to replicate it reliably enough that somebody could anticipate digging into the why. > > I've noticed it gets messy very quickly if you wait a while to upgrade > your system also, so I would be curious how long the user waited to do > an upgrade? And yeah, it was one of those cases of "bad sync length", the user in question inherited the box from somebody else, and they were left to pick up the pieces where the other person left off. And one of the common things I see that frustrates me, is generally, when you see these mountains of mess, somebody tries to argue its the *users* fault for not updating more frequently. But IMO, that's a rather distasteful buck-pass. The duty of a linux vendor/linux vendor maintainer is to isolate users from these kinds of problems, and we're clearly failing in this way. > > Python is also more complex than most things because we allow multiple > versions. > > There's no way to know whether removing virtual/rust will cause these > kinds of issues, so I'm still not convinced that we shouldn't remove > it. In light of the aforementioned axiom of "protect the user from messes", I think it makes sense to approach this from the perspective of: If we imagine it could possibly cause a problem, until we prove it doesn't and can't, we must assume it _will_ pgpsbFwzk5dUG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Wed, Oct 30, 2019 at 09:26:09AM -0500, William Hubbs wrote: > There's no way to know whether removing virtual/rust will cause these > kinds of issues, so I'm still not convinced that we shouldn't remove it. Sorry, I meant virtual/cargo here. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Wed, Oct 30, 2019 at 09:19:14PM +1300, Kent Fredric wrote: > On Tue, 29 Oct 2019 12:27:49 -0500 > William Hubbs wrote: > > > No, I'm just saying this: > > > > We don't know that there is a portage bug from what I'm reading in this > > thread. We are talking about possible bugs, but a possible bug isn't a bug. > > If there is an issue cite it otherwise move on. > > > > --with-bdeps=y is the default for a good reason as far as I am aware. > > > > William > > It only took a 3 days, but today, I'm helping a user who has a massive > upgrade problem. > > Among it, is this gem of a "conflict" > > > dev-python/setuptools:0 > > (dev-python/setuptools-41.1.0:0/0::gentoo, ebuild scheduled for merge) > pulled in by > > dev-python/setuptools[python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required by (dev-util/meson-0.51.2:0/0::gentoo, ebuild scheduled for merge) > > > > > > dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required by (dev-python/certifi-2019.6.16:0/0::gentoo, ebuild scheduled for > merge) > > > > > > > > > (dev-python/setuptools-20.6.7:0/0::gentoo, installed) pulled in by > > dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] > required by (net-misc/youtube-dl-2016.09.19:0/0::gentoo, installed) > > > > > > dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] > required by (dev-python/jinja-2.8:0/0::gentoo, installed) > > > > > > > dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] > required by (dev-python/numpy-1.10.4:0/0::gentoo, installed) > > > > > > dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] > required by (dev-python/certifi-2015.11.20:0/0::gentoo, installed) > > > >
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Tue, 29 Oct 2019 12:27:49 -0500 William Hubbs wrote: > No, I'm just saying this: > > We don't know that there is a portage bug from what I'm reading in this > thread. We are talking about possible bugs, but a possible bug isn't a bug. > If there is an issue cite it otherwise move on. > > --with-bdeps=y is the default for a good reason as far as I am aware. > > William It only took a 3 days, but today, I'm helping a user who has a massive upgrade problem. Among it, is this gem of a "conflict" dev-python/setuptools:0 (dev-python/setuptools-41.1.0:0/0::gentoo, ebuild scheduled for merge) pulled in by dev-python/setuptools[python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-util/meson-0.51.2:0/0::gentoo, ebuild scheduled for merge) dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/certifi-2019.6.16:0/0::gentoo, ebuild scheduled for merge) (dev-python/setuptools-20.6.7:0/0::gentoo, installed) pulled in by dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (net-misc/youtube-dl-2016.09.19:0/0::gentoo, installed) dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/jinja-2.8:0/0::gentoo, installed) dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/numpy-1.10.4:0/0::gentoo, installed) dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/certifi-2015.11.20:0/0::gentoo, installed)
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Tue, Oct 29, 2019 at 05:48:14PM +0100, Michał Górny wrote: > 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 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. No, I'm just saying this: We don't know that there is a portage bug from what I'm reading in this thread. We are talking about possible bugs, but a possible bug isn't a bug. If there is an issue cite it otherwise move on. --with-bdeps=y is the default for a good reason as far as I am aware. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
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 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Mon, 28 Oct 2019 10:34:40 -0500 William Hubbs wrote: > Let's go ahead and do the change and file bugs against portage if there > are issues. Any time I find something that I'd imagine portage could fix, I file a bug. But I already have so many open bugs for things portage does wrong that have been languishing for years, that I have to revert to the "assume portage just wont do the right thing" mentality. I'm literally tired of filing these kind of bugs, and tired of having to spoon-feed users in #gentoo with workarounds to get their systems working. Progress here on the problems I see seems *glacial*. pgpwq18AknAy5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Mon, Oct 28, 2019 at 10:18:17AM +1300, Kent Fredric wrote: > On Sun, 27 Oct 2019 12:05:02 -0500 > William Hubbs 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. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sun, 27 Oct 2019 12:05:02 -0500 William Hubbs 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. /me has *only* had to write tools to get around this problem pgpLsAGDSXUkK.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sun, Oct 27, 2019 at 08:36:47PM +1300, Kent Fredric wrote: > On Sat, 26 Oct 2019 18:55:11 -0500 > William Hubbs wrote: > > > Sure, but rebuild changes are exactly what you would want. that's how > > software written in go gets rebuilt for example, which is exactly what > > you want when go is upgraded. > > > > I agree that some rebuilds might be unnecessary, but if you don't like > > compiling/building software Gentoo isn't for you. > > > > William > > I suspect the problem might be moreso that --with-bdeps=y makes portage > prone to barf in this condition, not try recompiling. No one has said there is a bug in portage in this situation, so I'd rather not speculate until we have a bug report. If a build dep of something changes, the correct response with --with-bdeps=y is to rebuild everything that depends on the changed dep. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sun, 27 Oct 2019 01:42:48 + Michael Everitt wrote: > > I agree that some rebuilds might be unnecessary, but if you don't like > > compiling/building software Gentoo isn't for you. > > > > William > > > There's a subtle difference between compiling for compiling's sake, and > compiling with good reason .. especially for those who don't have copious > quantities of free cpu resources at their disposal 24/7/365 ... just sayin' > ... > > And not everyone is using rust, go, java and systemd as their prime movers, > even if you are .. *shudders* You do know that Rust code takes an age to compile, right? :P -- James Le Cuirot (chewi) Gentoo Linux Developer pgpCbzezD2Qtw.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sat, 26 Oct 2019 18:55:11 -0500 William Hubbs wrote: > Sure, but rebuild changes are exactly what you would want. that's how > software written in go gets rebuilt for example, which is exactly what > you want when go is upgraded. > > I agree that some rebuilds might be unnecessary, but if you don't like > compiling/building software Gentoo isn't for you. > > William I suspect the problem might be moreso that --with-bdeps=y makes portage prone to barf in this condition, not try recompiling. pgpwC9Ho96hFA.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On 27/10/19 00:55, William Hubbs wrote: > On Sun, Oct 27, 2019 at 12:14:59AM +0100, Michael Everitt wrote: >> On 26/10/19 23:35, William Hubbs wrote: >>> On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: > On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > >> On Fri, 25 Oct 2019 15:03:39 -0700 >> Georgy Yakovlev wrote: >> >>> not used anymore >>> >>> Closes: https://bugs.gentoo.org/695698 >>> Signed-off-by: Georgy Yakovlev >> Its likely this removal will cause the same kinds of problems faced by >> the recent virtual/pam removal, just its more insidious, as the >> dependency on the virtual is hidden away inside an eclass. >> >> But this still means that anything users have already installed will >> still depend on this, and without --changed-deps=y, it will break >> portage's resolution of anything currently installed using this crate. >> >> You can work-around this by -r1 bumping everything that used this >> eclass but this just goes to show why there's policy against >> eclasses changing the dependencies of their consumers without any >> consumer involvement. >> > In most if not all cases, this is just a build-time dependency. Do we > really have all these problems for build-time only dependencies? > Yes. Because of --with-bdeps. >>> I disagree, build-time dependencies can change in place because they >>> only affect the build. The problem with virtual/pam was that it was a >>> runtime dependency as well. >>> >>> William >> The problem is that portage defaults to --with-bdeps=y, so any emerging of >> packages now triggers anything that has a build-dep change, unless, as >> previously stated, you exclude that case or change the defaults. > Sure, but rebuild changes are exactly what you would want. that's how > software written in go gets rebuilt for example, which is exactly what > you want when go is upgraded. > > I agree that some rebuilds might be unnecessary, but if you don't like > compiling/building software Gentoo isn't for you. > > William > There's a subtle difference between compiling for compiling's sake, and compiling with good reason .. especially for those who don't have copious quantities of free cpu resources at their disposal 24/7/365 ... just sayin' ... And not everyone is using rust, go, java and systemd as their prime movers, even if you are .. *shudders* signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sun, Oct 27, 2019 at 12:14:59AM +0100, Michael Everitt wrote: > On 26/10/19 23:35, William Hubbs wrote: > > On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: > >> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: > >>> On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > >>> > On Fri, 25 Oct 2019 15:03:39 -0700 > Georgy Yakovlev wrote: > > > not used anymore > > > > Closes: https://bugs.gentoo.org/695698 > > Signed-off-by: Georgy Yakovlev > Its likely this removal will cause the same kinds of problems faced by > the recent virtual/pam removal, just its more insidious, as the > dependency on the virtual is hidden away inside an eclass. > > But this still means that anything users have already installed will > still depend on this, and without --changed-deps=y, it will break > portage's resolution of anything currently installed using this crate. > > You can work-around this by -r1 bumping everything that used this > eclass but this just goes to show why there's policy against > eclasses changing the dependencies of their consumers without any > consumer involvement. > > >>> In most if not all cases, this is just a build-time dependency. Do we > >>> really have all these problems for build-time only dependencies? > >>> > >> Yes. Because of --with-bdeps. > > I disagree, build-time dependencies can change in place because they > > only affect the build. The problem with virtual/pam was that it was a > > runtime dependency as well. > > > > William > The problem is that portage defaults to --with-bdeps=y, so any emerging of > packages now triggers anything that has a build-dep change, unless, as > previously stated, you exclude that case or change the defaults. Sure, but rebuild changes are exactly what you would want. that's how software written in go gets rebuilt for example, which is exactly what you want when go is upgraded. I agree that some rebuilds might be unnecessary, but if you don't like compiling/building software Gentoo isn't for you. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: > On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: > > On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > > > > > On Fri, 25 Oct 2019 15:03:39 -0700 > > > Georgy Yakovlev wrote: > > > > > > > not used anymore > > > > > > > > Closes: https://bugs.gentoo.org/695698 > > > > Signed-off-by: Georgy Yakovlev > > > > > > Its likely this removal will cause the same kinds of problems faced by > > > the recent virtual/pam removal, just its more insidious, as the > > > dependency on the virtual is hidden away inside an eclass. > > > > > > But this still means that anything users have already installed will > > > still depend on this, and without --changed-deps=y, it will break > > > portage's resolution of anything currently installed using this crate. > > > > > > You can work-around this by -r1 bumping everything that used this > > > eclass but this just goes to show why there's policy against > > > eclasses changing the dependencies of their consumers without any > > > consumer involvement. > > > > > > > In most if not all cases, this is just a build-time dependency. Do we > > really have all these problems for build-time only dependencies? > > > > Yes. Because of --with-bdeps. I disagree, build-time dependencies can change in place because they only affect the build. The problem with virtual/pam was that it was a runtime dependency as well. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: > On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > > > On Fri, 25 Oct 2019 15:03:39 -0700 > > Georgy Yakovlev wrote: > > > > > not used anymore > > > > > > Closes: https://bugs.gentoo.org/695698 > > > Signed-off-by: Georgy Yakovlev > > > > Its likely this removal will cause the same kinds of problems faced by > > the recent virtual/pam removal, just its more insidious, as the > > dependency on the virtual is hidden away inside an eclass. > > > > But this still means that anything users have already installed will > > still depend on this, and without --changed-deps=y, it will break > > portage's resolution of anything currently installed using this crate. > > > > You can work-around this by -r1 bumping everything that used this > > eclass but this just goes to show why there's policy against > > eclasses changing the dependencies of their consumers without any > > consumer involvement. > > > > In most if not all cases, this is just a build-time dependency. Do we > really have all these problems for build-time only dependencies? > Yes. Because of --with-bdeps. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > On Fri, 25 Oct 2019 15:03:39 -0700 > Georgy Yakovlev wrote: > > > not used anymore > > > > Closes: https://bugs.gentoo.org/695698 > > Signed-off-by: Georgy Yakovlev > > > Its likely this removal will cause the same kinds of problems faced by > the recent virtual/pam removal, just its more insidious, as the > dependency on the virtual is hidden away inside an eclass. > > But this still means that anything users have already installed will > still depend on this, and without --changed-deps=y, it will break > portage's resolution of anything currently installed using this crate. > > You can work-around this by -r1 bumping everything that used this > eclass but this just goes to show why there's policy against > eclasses changing the dependencies of their consumers without any > consumer involvement. > In most if not all cases, this is just a build-time dependency. Do we really have all these problems for build-time only dependencies? >
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sat, 26 Oct 2019 08:34:50 +0200 Francesco Riosa wrote: > So basically the eclass should be bumped, with the old one deprecated? I don't think rev-bumping the eclass is a useful way to fix this either. It could work, but I suspect it just expands the problem slightly. pgp4WzprN2xLh.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
Il giorno sab 26 ott 2019 alle ore 06:24 Michael Everitt ha scritto: > On 26/10/19 04:59, Kent Fredric wrote: > > On Fri, 25 Oct 2019 15:03:39 -0700 > > Georgy Yakovlev wrote: > > > >> not used anymore > >> > >> Closes: https://bugs.gentoo.org/695698 > >> Signed-off-by: Georgy Yakovlev > > > > Its likely this removal will cause the same kinds of problems faced by > > the recent virtual/pam removal, just its more insidious, as the > > dependency on the virtual is hidden away inside an eclass. > > > > But this still means that anything users have already installed will > > still depend on this, and without --changed-deps=y, it will break > > portage's resolution of anything currently installed using this crate. > > > > You can work-around this by -r1 bumping everything that used this > > eclass but this just goes to show why there's policy against > > eclasses changing the dependencies of their consumers without any > > consumer involvement. > tl;dr - play with fire .. you're gonna get burned .. :] > > Good luck with the core aim .. there is probably a slow-and-steady approach > that will win through .. > > So basically the eclass should be bumped, with the old one deprecated?
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On 26/10/19 04:59, Kent Fredric wrote: > On Fri, 25 Oct 2019 15:03:39 -0700 > Georgy Yakovlev wrote: > >> not used anymore >> >> Closes: https://bugs.gentoo.org/695698 >> Signed-off-by: Georgy Yakovlev > > Its likely this removal will cause the same kinds of problems faced by > the recent virtual/pam removal, just its more insidious, as the > dependency on the virtual is hidden away inside an eclass. > > But this still means that anything users have already installed will > still depend on this, and without --changed-deps=y, it will break > portage's resolution of anything currently installed using this crate. > > You can work-around this by -r1 bumping everything that used this > eclass but this just goes to show why there's policy against > eclasses changing the dependencies of their consumers without any > consumer involvement. tl;dr - play with fire .. you're gonna get burned .. :] Good luck with the core aim .. there is probably a slow-and-steady approach that will win through .. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Fri, 25 Oct 2019 15:03:39 -0700 Georgy Yakovlev wrote: > not used anymore > > Closes: https://bugs.gentoo.org/695698 > Signed-off-by: Georgy Yakovlev Its likely this removal will cause the same kinds of problems faced by the recent virtual/pam removal, just its more insidious, as the dependency on the virtual is hidden away inside an eclass. But this still means that anything users have already installed will still depend on this, and without --changed-deps=y, it will break portage's resolution of anything currently installed using this crate. You can work-around this by -r1 bumping everything that used this eclass but this just goes to show why there's policy against eclasses changing the dependencies of their consumers without any consumer involvement. pgptWuHVHE_yM.pgp Description: OpenPGP digital signature
