Re: [gentoo-portage-dev] [RFC] Inherit updates settings from master repositories by default
On Wednesday, February 05, 2014 19:11:12 Sebastian Luther wrote: Am 05.02.2014 09:03, schrieb Mike Frysinger: On Saturday, February 01, 2014 20:38:05 Arfrever Frehtes Taifersar Arahesis wrote: this i'm not so sure about. when you have a local overlay, portage complains when there are no masters which means most people have just blindly added masters = gentoo. but if they have packages in there using the old name (on purpose), then updates will constantly tromp on that. The old behavior was to always apply the updates from ::gentoo as long as the repo didn't have its own updates. This means it doesn't matter if the repo sets the masters = gentoo as long as it doesn't contain updates. ok, i thought it always ignored the gentoo updates dir at least, there should be one of: - one-time automatic migration of existing layout.conf files where we set updates-master = for them. How do you know if it's the user's repo or a layman repo, where layout.conf is manged by other people? you ask layman. this isn't difficult. - a warning phase where we complain if the field isn't set, and we default to current behavior. once some time has elapsed, we stop warning and we change the default. Be sure to only hit users which are really affected by the change (i.e. repos with existing updates and master repos which contain updates, which affect packages in the repo). doing it based on the current set of affected packages doens't make sense then the set of possible updates is constantly changing -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [RFC] Inherit updates settings from master repositories by default
On Wednesday, February 05, 2014 03:03:10 Mike Frysinger wrote: On Saturday, February 01, 2014 20:38:05 Arfrever wrote: If this attribute is not set explicitly, then it defaults to value of 'masters' attribute. this i'm not so sure about. when you have a local overlay, portage complains when there are no masters which means most people have just blindly added masters = gentoo. but if they have packages in there using the old name (on purpose), then updates will constantly tromp on that. if portage is already processing updates from the main gentoo-x86 tree in repos (that lack an updates/ dir) then i think it simplifies things to: - if updates/ exists in the repo and the attribute is not explicitly set, then default to instead of the value of masters and issue a warning telling the user to explicit set the attribute -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Always warn about unknown mirrors (bug 501352)
On Sat, 15 Feb 2014 13:40:23 +0100 Sebastian Luther sebastianlut...@gmx.de wrote: --- pym/portage/package/ebuild/fetch.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Yeah, looks fine. Merge it :) Sorry for the delay reviewing. -- Brian Dolbec dolsen
Re: [gentoo-portage-dev] [PATCH] Implement --newrepo flag.
Am 17.02.2014 17:39, schrieb Brian Dolbec: Mike, if you can confirm the tests pass. Go ahead and merge it. Please give me some more time to review it. I'll commit it if it lgtm.
Re: [gentoo-portage-dev] [PATCH] Implement --newrepo flag.
Am 17.02.2014 18:52, schrieb David James:
@@ -96,6 +105,68 @@ class MultirepoTestCase(TestCase):
snip
+
+ #--newrepo: pick ebuild if binpkg/ebuild have different
repo
+ ResolverPlaygroundTestCase(
+ [dev-libs/C],
+ options = {--usepkg: True, --newrepo: True,
--selective: True},
+ success = True,
+ check_repo_names = True,
+ mergelist = [dev-libs/C-1::repo1]),
Why should it take the ebuild from the repo with lower priority?
I thought the intend was that the package should be reinstalled if it is
now pulled from a repo with higher priority than the repo from which the
installed package came.
Re: [gentoo-portage-dev] [PATCH] Remove bogus countdown during clean list printing (bug 501296)
Am 17.02.2014 08:56, schrieb Mike Frysinger: On Friday, February 14, 2014 22:22:03 Sebastian Luther wrote: Before this patch a fake unmerge countdown would be shown after an @system package was printed. If the users aborts at this point, it looked as if some packages were missing from the clean list compared to the --pretend output. Acked-by: Mike Frysinger vap...@gentoo.org -mike committed
Re: [gentoo-portage-dev] [PATCH] Always warn about unknown mirrors (bug 501352)
Am 17.02.2014 17:21, schrieb Brian Dolbec: On Sat, 15 Feb 2014 13:40:23 +0100 Sebastian Luther sebastianlut...@gmx.de wrote: --- pym/portage/package/ebuild/fetch.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Yeah, looks fine. Merge it :) Sorry for the delay reviewing. committed
Re: [gentoo-portage-dev] [RFC] Inherit updates settings from master repositories by default
Am 17.02.2014 09:06, schrieb Mike Frysinger: On Wednesday, February 05, 2014 19:11:12 Sebastian Luther wrote: Am 05.02.2014 09:03, schrieb Mike Frysinger: On Saturday, February 01, 2014 20:38:05 Arfrever Frehtes Taifersar Arahesis wrote: this i'm not so sure about. when you have a local overlay, portage complains when there are no masters which means most people have just blindly added masters = gentoo. but if they have packages in there using the old name (on purpose), then updates will constantly tromp on that. The old behavior was to always apply the updates from ::gentoo as long as the repo didn't have its own updates. This means it doesn't matter if the repo sets the masters = gentoo as long as it doesn't contain updates. ok, i thought it always ignored the gentoo updates dir At least that's what Arfrever wrote in the first mail as 'old behavior'. I assume that's correct. at least, there should be one of: - one-time automatic migration of existing layout.conf files where we set updates-master = for them. How do you know if it's the user's repo or a layman repo, where layout.conf is manged by other people? you ask layman. this isn't difficult. layman was just an example. The user could as well have cloned a repo by hand. When you said one-time automatic migration I thought of an update during portage installation (like it's done for other things). Do you have something else in mind? - a warning phase where we complain if the field isn't set, and we default to current behavior. once some time has elapsed, we stop warning and we change the default. Be sure to only hit users which are really affected by the change (i.e. repos with existing updates and master repos which contain updates, which affect packages in the repo). doing it based on the current set of affected packages doens't make sense then the set of possible updates is constantly changing It's true that it may change, but this should only happen very seldom and only during the transition period. The idea is that if you don't restrict the warning like that, you're going to create a lot of noise. -mike
