Re: [gentoo-dev] Re: don't rely on dynamic deps
On 27/07/14 16:47, Michał Górny wrote:
Dnia 2014-07-27, o godz. 14:42:24
Samuli Suominen ssuomi...@gentoo.org napisał(a):
On 26/07/14 15:49, Ciaran McCreesh wrote:
On Sat, 26 Jul 2014 12:41:16 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
hasufell hasuf...@gentoo.org wrote:
Dynamics deps are already broken, not consistently enabled (e.g.
when subslots are in use)
Just to make it clear: No, dynamic deps are not broken.
Yes they are.
We just succesfully converted ~300 ebuilds in tree without revision
bumps from virtual/udev[gudev,introspection,static-libs]
to virtual/libudev and virtual/libgudev
Tested it on multiple boxes, went fine.
How did you exactly test them?
That you could still emerge packages, even world, without Portage
complaining about unsatisfied
deps
Did you at least bother checking if
portage actually uses the deps you added?
When you `cd /var/db/pkg` and run `grep virtual/udev.*gudev
*/*/*.ebuild`, you can indeed still see some:
app-cdr/xfburn-0.5.2/xfburn-0.5.2.ebuild:udev? ( virtual/udev[gudev] )
gnome-base/gvfs-1.20.2/gvfs-1.20.2.ebuild:virtual/udev[gudev] )
media-gfx/gimp-2.8.10-r1/gimp-2.8.10-r1.ebuild:udev? (
virtual/udev[gudev] )
sys-fs/udisks-1.0.5-r1/udisks-1.0.5-r1.ebuild:=virtual/udev-208[gudev]
sys-fs/udisks-2.1.3/udisks-2.1.3.ebuild:
=virtual/udev-${UDEV_VERSION}[gudev]
virtual/libgudev-208/libgudev-208.ebuild:# $Header:
/var/cvsroot/gentoo-x86/virtual/libgudev/libgudev-208.ebuild,v 1.7
2014/06/18 20:55:21 mgorny Exp $
xfce-extra/thunar-volman-0.8.0/thunar-volman-0.8.0.ebuild:
virtual/udev[gudev]
But if you try to emerge these packages, like, for example:
$ sudo emerge -pv xfburn thunar-volman
These are the packages that would be merged, in reverse order:
Calculating dependencies... done!
[ebuild R] xfce-extra/thunar-volman-0.8.0 USE=libnotify -debug 0 kB
[ebuild R] app-cdr/xfburn-0.5.2 USE=udev -debug -gstreamer 0 kB
Portage is using the fresh copies from gentoo-x86
I'm _not_ a Portage, the package manager, developer, so I'd really
appericiate some *examples* where this would become a problem, binary
packages is known one, we have lived with that problem since forever, so
something else, please.
For everything I do with Portage, this is fine with me, and I expect
it's fine for the vast majority of users as well.
And this majority of users won't appericiate the suggested solution of
lets always revision bump, despite of triggering rebuild for everyone
To clarify, I know dynamic deps is not perfect, but it's the best
solution we have implemented to avoid the rebuilding problem, and long
as that's true... And seems like you, yourself, have thought about the
same issue:
http://bugs.gentoo.org/show_bug.cgi?id=486778
As in, you can't skip that bug, and go directly to
http://bugs.gentoo.org/show_bug.cgi?id=516612
- Samuli
(Excuse my grammar, woke up five minutes ago, to make some coffee now...)
Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a
On 27/07/14 14:33, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (27 Jul 2014) # Not buildable for a long time, bug #414903 # Removal in a month. media-plugins/vdr-dxr3 media-video/dxr3config media-video/em8300-libraries You forgot to mask em8300-modules. That's the package that's actually broken. Those you masked, actually still build (but are just useless without em8300-modules)
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On 27/07/14 22:01, Markus Meier (maekke) wrote: maekke 14/07/27 19:01:15 Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild Log: add ~arm, bug #510340 Package bumping is done by, eg.: # cp x265-.ebuild x265-1.3.ebuild And then, # grep *.ebuild x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild:KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild
[gentoo-dev] Re: don't rely on dynamic deps
Paweł Hajdan, Jr. posted on Sun, 27 Jul 2014 16:56:17 +0200 as excerpted: One thing I would question in that table is applied immediately (but can break hard when dynamic-deps stop working)). How can dynamically removing an unused dependency cause something to break, setting aside bugs in the package manager? If removing a dependency causes something to break, how can it be unused? Yeah, I was also wondering about this. I believe what is being discussed there is the following (as I understand it): 1) Foo incorrectly deps on bar, and doesn't actually use that dep for anything. Say it was a historical dep that upstream forgot to remove in the docs when they removed the dep, and the (gentoo) maintainer didn't detect it initially. 2) User installs foo with the incorrect dep, thus pulling in bar. At this point use has an unnecessary package installed but is otherwise fine, deps are wrongly pulling it in. 3) Foo maintainer detects the error (upstream removed the dep in the unreleased version and maintainer realizes it wasn't needed in the current version either) and removes the dep on bar, but since it was unused anyway and thus doesn't affect the package as installed (except in vardb), he takes advantage of dynamic-deps and no revbump is done. At this point, user has an unnecessary dep that portage has just been told about due to dynamic deps, and will unmerge it at the next depclean, but the user's dep-tree is still self-consistent and everything's fine. 4) Due to dynamic-deps, portage depcleans bar. Due to dynamic-deps, the user's dep-tree is still consistent and everything's fine. 5) Since nothing in the tree needs bar, it is removed. Due to dynamic-deps, the user's dep-tree is still consistent, because the in-/usr/portage foo.ebuild doesn't say anything about bar since #3. 6) Finally, foo is removed from tree. ** User isn't ready to get rid of foo yet, but user's dep-tree just blew up, because now portage falls back to the static vardb from original install, and that still says foo deps on bar, which is nowhere to be found! What's worse, the usual trick of digging the ebuild out of vardb and putting it in the user's overlay to shut portage up and let the user keep foo doesn't work, because the vardb ebuild has an unsatisfied dep. With the repeated caveat that this is as I understand it, if the above is clear along with the implications, you can stop reading here. The below simply expands on the above and its implications... The breaks hard bit can be applied for two reasons. First, exactly as I said above, the user's now SOL -- they had no warning things were going to break and now it's too late to do anything about it (unless they're advanced enough to figure out how to dig the last, corrected ebuild version out of a snapshot or the cvs attic, or to figure out that dep isn't actually needed on their own, and edit the ebuild they pulled out of vardb accordingly). Second, breaks hard can apply when a whole set of related packages were removed at once, all with the same bad dep. Consider for instance someone with kde-4.11 installed and how deeply dependent typical kde ebuilds tend to be on the kde eclasses. If the bad dep was in an eclass and applied to say 200+ kde packages the user may well have installed, then got corrected such that dynamic-deps killed the bad dep, then all of kde-4.11 was removed from the tree at once... A user may well find out they have 200+ broken deps at once! Breaks hard, indeed! Now we look at the same set of triggering events with static deps. There are two cases, depending on whether the foo maintainer accounted for static deps and did a revision bump at step 3 or not: With a revision bump at step #3, at step #4, before the user can do the depclean, they'll have to do the revision upgrade. The aftermath of step #6 will then be hugely different as the vardb copy will have the bad dep removed as well. If the foo maintainer didn't do a revision bump, with static deps the user will have never depcleaned bar in step #4 as the vardb deps still say it's needed. So when foo is removed in step #6, again, no big deal. Sure the user had a useless dep installed the whole time, but when foo is removed from tree, fine, the user's dep-tree remains self-consistent and no blowup. And the user remains free to dig that ebuild out of vardb and install it in the overlay again, at least temporarily, to keep portage from yelling about it until the user has time to find an alternative to the package, or to upgrade to the new version (kde 4.12 or 4.13 in my mass-breakage example). Reinstalling may or may not be possible depending on how much the ebuild depended on eclasses and what had happened to them, but keeping the same thing installed at least temporarily should be fine. And the static-deps case of the user not upgrading in a timely manner and thus skipping step #4 entirely, resolves exactly as if the
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On 28/07/14 09:41, Samuli Suominen wrote: On 27/07/14 22:01, Markus Meier (maekke) wrote: maekke 14/07/27 19:01:15 Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild Log: add ~arm, bug #510340 Package bumping is done by, eg.: # cp x265-.ebuild x265-1.3.ebuild And then, # grep *.ebuild x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild:KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild Fixed that for you.
Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a
On 28/07/14 09:38, Samuli Suominen wrote: On 27/07/14 14:33, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (27 Jul 2014) # Not buildable for a long time, bug #414903 # Removal in a month. media-plugins/vdr-dxr3 media-video/dxr3config media-video/em8300-libraries You forgot to mask em8300-modules. That's the package that's actually broken. Those you masked, actually still build (but are just useless without em8300-modules) Fixed that for you.
Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a
El lun, 28-07-2014 a las 09:38 +0300, Samuli Suominen escribió: On 27/07/14 14:33, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (27 Jul 2014) # Not buildable for a long time, bug #414903 # Removal in a month. media-plugins/vdr-dxr3 media-video/dxr3config media-video/em8300-libraries You forgot to mask em8300-modules. That's the package that's actually broken. Those you masked, actually still build (but are just useless without em8300-modules) Oops, sorry, I forgot it finally :S (I have seen you fixed it already)
[gentoo-dev] Re: don't rely on dynamic deps
Duncan 1i5t5.dun...@cox.net wrote: 1) Foo incorrectly deps on bar 2) User installs foo with the incorrect dep 3) Foo maintainer detects the error 4) Due to dynamic-deps, portage depcleans bar. 5) Since nothing in the tree needs bar, it is removed. 6) Finally, foo is removed from tree. ** User isn't ready to get rid of foo yet, but user's dep-tree just blew up This is the problem of orphaned (without maintained ebuilds) packages: Both, dynamic and static deps break on the similar situation for different reasons. The above describes one problem which you get in this case with dynamic deps; to get a similar problem with static deps, you need a slightly different situation: 1-3 as above, 4 is skipped (due to static deps). 5) bar is split into bar-base and bar-gui. 6) as above (foo is removed from the tree). Now the static deps will keep in bar forever, omitting that the packages in the tree can install bar-base or bar-gui. The user's dep-tree blows up through blockers or merge conflict which cannot be resolved. I repeat once more: For packages no longer maintained in the tree, there is no secure way to treat them always correctly; no longer maintained means exactly this. Either the user should remove them, or he should take full responsibility by maintaining them by himself in his overlay. Choosing a strategy (dynamic or static deps) should not concentrate on users who refuse to choose this only reasonable solution - as excpected, they get a solution which works sometimes, but they have to keep the pieces when it breaks, no matter which strategy is decided. What's worse, the usual trick of digging the ebuild out of vardb and putting it in the user's overlay to shut portage up and let the user keep foo doesn't work, because the vardb ebuild has an unsatisfied dep. This is not so bad: The user has to put a corrected ebuild into his overlay and must reemerge the package (currently, the latter could be skipped with dynamic deps). In fact, no matter whether you have static or dynamic deps, this is the only way to cleanly avoid the problems if you want to keep a package installed which is not maintained anymore: *You* must maintain it. There simply is no magic which can avoid this.
Re: [gentoo-dev] Re: don't rely on dynamic deps
Martin Vaeth wrote: The user has to put a corrected ebuild into his overlay and must reemerge the package (currently, the latter could be skipped with dynamic deps). In fact, no matter whether you have static or dynamic deps, this is the only way to cleanly avoid the problems if you want to keep a package installed which is not maintained anymore: *You* must maintain it. There simply is no magic which can avoid this. It could be avoided if portage tree sync applied each tree change locally rather than jump from old to new. There was a delta idea discussed a year or so ago in connection with some git discussions. The user's vardb could then automatically receive the last state of the ebuild, before it was removed. That's no small change though. //Peter
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius a...@gentoo.org napisał(a): Hey all.. So, putting aside for now how much of a mess this would be to implement in the virtuals' ebuilds themselves, what do people think of changing the virtuals so that they contain an entry in IUSE for each provider that can satisfy it? The idea here is that the package satisfying a virtual could be optionally explicitly-chosen through package.use (or USE= in make.conf, perhaps) instead of having an entry in @world, that way if nothing depends on the virtual then it and the provider can be - --depclean'ed from the system. The idea is specifically NOT to have rdeps depend on these flags, that would undermine the whole purpose of the virtual; it would just be for end-users to set if they so chose. I think I don't get this argument. If you really want to have a particular provider for the virtual for external purposes, it's fully purposeful to put it in @world or otherwise in a custom set. In this case, USE flags aren't helpful. If you only prefer a particular provider, you can tip portage easily to use it without resorting to USE flags. This also allows portage to semi-transparently switch to other provider if dependencies need it. In this case, USE flags only make this auto-switching harder. This may also help with getting portage to peg a virtual's provider to a specific package instead of constantly trying to switch from one to another, ie, how systemd kept getting pulled in, in relation to the upower virtual. Note - I haven't done any tests to determine if this actually helps with such issues tho (or even attempted to reproduce them, as i was apparently one of the lucky ones that it didn't happen to). While I agree that finding some solution is a good step forward, I'm afraid this doesn't really lead us anywhere. Even if it allows to workaround the actual portage issue, I'm afraid we will hit it again somewhere else. Shortly, Gentoo would be full of workarounds... oh wait, it already is. By the way, proper virtuals for krb5 would involve much more crazy stuff to get slot operator right. And then Ciaran would yell at us for abusing slots. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Peter Stuge pe...@stuge.se wrote: Martin Vaeth wrote: In fact, no matter whether you have static or dynamic deps, this is the only way to cleanly avoid the problems if you want to keep a package installed which is not maintained anymore: *You* must maintain it. There simply is no magic which can avoid this. It could be avoided if portage tree sync applied each tree change locally rather than jump from old to new. [...] The user's vardb could then automatically receive the last state of the ebuild, before it was removed. It doesn't help reliably, either, since the last state of the ebuild, before it was removed, will be outdated at some point, too. It *is* necessary to adapt the dependencies to the current tree, and if no maintainer is there to do this correctly for that package, all empirics to push such changes will fail in some situations.
Re: [gentoo-dev] Re: don't rely on dynamic deps
Martin Vaeth wrote: The user's vardb could then automatically receive the last state of the ebuild, before it was removed. It doesn't help reliably, either, since the last state of the ebuild, before it was removed, will be outdated at some point, too. Sorry, I don't see how. Can you give an example? Thanks! //Peter
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/07/14 10:40 AM, Manuel Rüger wrote: On 07/25/2014 08:49 PM, Ian Stakenvicius wrote: Hey all.. So, putting aside for now how much of a mess this would be to implement in the virtuals' ebuilds themselves, what do people think of changing the virtuals so that they contain an entry in IUSE for each provider that can satisfy it? The idea here is that the package satisfying a virtual could be optionally explicitly-chosen through package.use (or USE= in make.conf, perhaps) instead of having an entry in @world, that way if nothing depends on the virtual then it and the provider can be --depclean'ed from the system. The idea is specifically NOT to have rdeps depend on these flags, that would undermine the whole purpose of the virtual; it would just be for end-users to set if they so chose. This may also help with getting portage to peg a virtual's provider to a specific package instead of constantly trying to switch from one to another, ie, how systemd kept getting pulled in, in relation to the upower virtual. Note - I haven't done any tests to determine if this actually helps with such issues tho (or even attempted to reproduce them, as i was apparently one of the lucky ones that it didn't happen to). I don't know if this would aid heavy binpkg users or not. For completion, here's one of those rather messy examples: --- virtual/krb5-0.ebuild 2013-06-28 09:04:47.0 -0400 +++ virtual/krb5-0.ebuild.new 2014-07-25 14:47:48.0 -0400 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2 2013/06/27 20:42:55 aballier Exp $ -EAPI=3 +EAPI=5 DESCRIPTION=Virtual for Kerberos V implementation HOMEPAGE= @@ -11,7 +11,12 @@ LICENSE= SLOT=0 KEYWORDS=alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos -IUSE= +IUSE=heimdal mit-krb5 DEPEND= -RDEPEND=|| ( app-crypt/mit-krb5 app-crypt/heimdal ) +RDEPEND=!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5 app-crypt/heimdal ) ) ) + mit-krb5? ( app-crypt/mit-krb5 ) + heimdal? ( app-crypt/heimdal ) + +REQUIRED_USE=heimdal? ( !mit-krb5 ) + mit-krb5? ( !heimdal ) Thoughts? Thinking in another direction: Would it be possible to introduce pseudo-versioned useflags? This would solve a problem for virtual/libusb just with adding IUSE==dev-libs/libusb-1.0.18 virtual/libusb-1-r1 depends on either dev-libs/libusb or sys-freebsd/freebsd-lib. The latter one is only compatible with libusb-1.0.9, so packages depending on dev-libs/libusb-1.0.9 can't use the virtual. Assuming freebsd-lib becomes compatible with dev-libs/libusb again, packages will have to switch back to the virtual to support both. Depending on virtual/libusb[=dev-libs/libusb-1.0.18(+)] instead would just need a change in the virtual. Cheers, Manuel This sounds like something that should still be doable with two versions of the virtual/libusb package... I mean, if something *needs* a newer libusb than 1.0.9 , then it should appropriately depend on a virtual/libusb that needs it. Otherwise, it shouldn't matter which provider provides virtual/libusb-1 , right?? So we keep virtual/libusb-1 as-is, and add a virtual/libusb-1.0.10 (or whatever version is appropriate) for anything that needs a newer one. That newer one would need to have a !sys-freebsd/freebsd-lib in it, I think, to help keep it from being allowed to upgrade, but that itself might not be necessary. Or is it more complicated than that and i'm missing something? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPWXDwACgkQ2ugaI38ACPBrOAD9EXzlINqnSFQ/SvSTcvVyiMLr ZkMzt4ud98dvItB++5oBAKIg5Nc0p4jjtAj/DN1YsBw8yWkRyCLylJ6G7iKeeKT3 =U9cS -END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/07/14 11:22 AM, Ciaran McCreesh wrote:
Let's start with the easiest issue: please point us all to the
place where you proved how dynamic dependencies still work in the
face of ebuild removals. Your solution to this problem will be of
great benefit to all of us.
This is something I personally don't understand. If an ebuild for a
package installed on the system has been removed from the tree, but
newer and/or older ebuilds exist in the tree, then the installed
package can #1 only be trusted in accordance with the ebuild copy
enbedded in VDB (that i get), BUT, #2 should be forced to either
upgrade or downgrade so that it matches what *is* in the tree anyhow,
and that's done via a standard ${PV} comparison that should happen
regardless of whether static or dynamic deps methods are in place.
IMO, if currently-installed versions of packages are satisfying
dependencies after those packages have been removed from the tree, I
don't see this as being particularly valid anyhow. Sure, end-users
should be able to force this using masks or whatnot in the particular
cases they need to do this, but i don't think this should be in any
way a default behaviour, should it?? Ebuilds are removed for a reason...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPWXncACgkQ2ugaI38ACPBWLQEAp3sB8lfdZ8FYmXRsxNy6SlHE
AR40+p+/x6J5+m4D618BAK4XKG64W92WFWne2rn3cDtdKuoQ+wwN2RBw066MoPJQ
=TyGx
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
Dnia 2014-07-28, o godz. 10:20:44 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/07/14 10:40 AM, Manuel Rüger wrote: On 07/25/2014 08:49 PM, Ian Stakenvicius wrote: Hey all.. So, putting aside for now how much of a mess this would be to implement in the virtuals' ebuilds themselves, what do people think of changing the virtuals so that they contain an entry in IUSE for each provider that can satisfy it? The idea here is that the package satisfying a virtual could be optionally explicitly-chosen through package.use (or USE= in make.conf, perhaps) instead of having an entry in @world, that way if nothing depends on the virtual then it and the provider can be --depclean'ed from the system. The idea is specifically NOT to have rdeps depend on these flags, that would undermine the whole purpose of the virtual; it would just be for end-users to set if they so chose. This may also help with getting portage to peg a virtual's provider to a specific package instead of constantly trying to switch from one to another, ie, how systemd kept getting pulled in, in relation to the upower virtual. Note - I haven't done any tests to determine if this actually helps with such issues tho (or even attempted to reproduce them, as i was apparently one of the lucky ones that it didn't happen to). I don't know if this would aid heavy binpkg users or not. For completion, here's one of those rather messy examples: --- virtual/krb5-0.ebuild 2013-06-28 09:04:47.0 -0400 +++ virtual/krb5-0.ebuild.new 2014-07-25 14:47:48.0 -0400 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2 2013/06/27 20:42:55 aballier Exp $ -EAPI=3 +EAPI=5 DESCRIPTION=Virtual for Kerberos V implementation HOMEPAGE= @@ -11,7 +11,12 @@ LICENSE= SLOT=0 KEYWORDS=alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos -IUSE= +IUSE=heimdal mit-krb5 DEPEND= -RDEPEND=|| ( app-crypt/mit-krb5 app-crypt/heimdal ) +RDEPEND=!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5 app-crypt/heimdal ) ) ) + mit-krb5? ( app-crypt/mit-krb5 ) + heimdal? ( app-crypt/heimdal ) + +REQUIRED_USE=heimdal? ( !mit-krb5 ) + mit-krb5? ( !heimdal ) Thoughts? Thinking in another direction: Would it be possible to introduce pseudo-versioned useflags? This would solve a problem for virtual/libusb just with adding IUSE==dev-libs/libusb-1.0.18 virtual/libusb-1-r1 depends on either dev-libs/libusb or sys-freebsd/freebsd-lib. The latter one is only compatible with libusb-1.0.9, so packages depending on dev-libs/libusb-1.0.9 can't use the virtual. Assuming freebsd-lib becomes compatible with dev-libs/libusb again, packages will have to switch back to the virtual to support both. Depending on virtual/libusb[=dev-libs/libusb-1.0.18(+)] instead would just need a change in the virtual. This sounds like something that should still be doable with two versions of the virtual/libusb package... I mean, if something *needs* a newer libusb than 1.0.9 , then it should appropriately depend on a virtual/libusb that needs it. Otherwise, it shouldn't matter which provider provides virtual/libusb-1 , right?? So we keep virtual/libusb-1 as-is, and add a virtual/libusb-1.0.10 (or whatever version is appropriate) for anything that needs a newer one. That newer one would need to have a !sys-freebsd/freebsd-lib in it, I think, to help keep it from being allowed to upgrade, but that itself might not be necessary. Not a blocker but rather lack of this dependency. We'll probably have to mask it in bsd profiles as well but otherwise looks fine. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Mon, 28 Jul 2014 10:30:15 -0400
Ian Stakenvicius a...@gentoo.org wrote:
On 26/07/14 11:22 AM, Ciaran McCreesh wrote:
Let's start with the easiest issue: please point us all to the
place where you proved how dynamic dependencies still work in the
face of ebuild removals. Your solution to this problem will be of
great benefit to all of us.
This is something I personally don't understand. If an ebuild for a
package installed on the system has been removed from the tree, but
newer and/or older ebuilds exist in the tree, then the installed
package can #1 only be trusted in accordance with the ebuild copy
enbedded in VDB (that i get), BUT, #2 should be forced to either
upgrade or downgrade so that it matches what *is* in the tree anyhow,
and that's done via a standard ${PV} comparison that should happen
regardless of whether static or dynamic deps methods are in place.
But you can't run pkg_prerm unless a package's dependencies are
satisfied. How do you know what those dependencies are, if you don't
use VDB and if the ebuild isn't there?
(This is a real issue: see the botched ruby-config switch.)
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/07/14 10:42 AM, Michał Górny wrote: Dnia 2014-07-28, o godz. 10:20:44 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/07/14 10:40 AM, Manuel Rüger wrote: On 07/25/2014 08:49 PM, Ian Stakenvicius wrote: Hey all.. So, putting aside for now how much of a mess this would be to implement in the virtuals' ebuilds themselves, what do people think of changing the virtuals so that they contain an entry in IUSE for each provider that can satisfy it? The idea here is that the package satisfying a virtual could be optionally explicitly-chosen through package.use (or USE= in make.conf, perhaps) instead of having an entry in @world, that way if nothing depends on the virtual then it and the provider can be --depclean'ed from the system. The idea is specifically NOT to have rdeps depend on these flags, that would undermine the whole purpose of the virtual; it would just be for end-users to set if they so chose. This may also help with getting portage to peg a virtual's provider to a specific package instead of constantly trying to switch from one to another, ie, how systemd kept getting pulled in, in relation to the upower virtual. Note - I haven't done any tests to determine if this actually helps with such issues tho (or even attempted to reproduce them, as i was apparently one of the lucky ones that it didn't happen to). I don't know if this would aid heavy binpkg users or not. For completion, here's one of those rather messy examples: --- virtual/krb5-0.ebuild 2013-06-28 09:04:47.0 -0400 +++ virtual/krb5-0.ebuild.new 2014-07-25 14:47:48.0 -0400 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2 2013/06/27 20:42:55 aballier Exp $ -EAPI=3 +EAPI=5 DESCRIPTION=Virtual for Kerberos V implementation HOMEPAGE= @@ -11,7 +11,12 @@ LICENSE= SLOT=0 KEYWORDS=alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos -IUSE= +IUSE=heimdal mit-krb5 DEPEND= -RDEPEND=|| ( app-crypt/mit-krb5 app-crypt/heimdal ) +RDEPEND=!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5 app-crypt/heimdal ) ) ) + mit-krb5? ( app-crypt/mit-krb5 ) + heimdal? ( app-crypt/heimdal ) + +REQUIRED_USE=heimdal? ( !mit-krb5 ) + mit-krb5? ( !heimdal ) Thoughts? Thinking in another direction: Would it be possible to introduce pseudo-versioned useflags? This would solve a problem for virtual/libusb just with adding IUSE==dev-libs/libusb-1.0.18 virtual/libusb-1-r1 depends on either dev-libs/libusb or sys-freebsd/freebsd-lib. The latter one is only compatible with libusb-1.0.9, so packages depending on dev-libs/libusb-1.0.9 can't use the virtual. Assuming freebsd-lib becomes compatible with dev-libs/libusb again, packages will have to switch back to the virtual to support both. Depending on virtual/libusb[=dev-libs/libusb-1.0.18(+)] instead would just need a change in the virtual. This sounds like something that should still be doable with two versions of the virtual/libusb package... I mean, if something *needs* a newer libusb than 1.0.9 , then it should appropriately depend on a virtual/libusb that needs it. Otherwise, it shouldn't matter which provider provides virtual/libusb-1 , right?? So we keep virtual/libusb-1 as-is, and add a virtual/libusb-1.0.10 (or whatever version is appropriate) for anything that needs a newer one. That newer one would need to have a !sys-freebsd/freebsd-lib in it, I think, to help keep it from being allowed to upgrade, but that itself might not be necessary. Not a blocker but rather lack of this dependency. We'll probably have to mask it in bsd profiles as well but otherwise looks fine. Just not including the sys-freebsd/freebsd-lib atom in the newer virtual generally makes sense, yes, but portage in particular will try to upgrade the virtual and therefore also switch the provider from freebsd-lib to the newer libusb on -uDN, right? A mask in profiles would do the trick (especially in this case due to there being two distinct sets of profiles for each provider) but it would be easier in the general case to handle this all in-ebuild if possible, wouldn't it? Back to my use flag suggestion -- this is an example that I don't think use flags could help; indeed i think the use flags would get in the way more than anything: #1, the newer version of the virtual would need to keep the flag for the missing provider to have any effect, and this just seems wrong; #2, the only flag-based blocking that could occur would be REQUIRED_USE or pkg_pretend, and both of those would keep an emerge -uDN @world from starting until resolved, instead of just disallowing the virtual from being
Re: [gentoo-dev] Re: Avoiding rebuilds
On Mon, 28 Jul 2014 05:49:07 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
hasufell hasuf...@gentoo.org wrote:
Ulrich Mueller:
I wonder if it wouldn't be saner to leave our revision syntax
untouched.
As already mentioned, -r1.1 is only one of several possible ways
how to achieve the same aim; I am not speaking in favour for a
particular method.
The -r1.1 method has the advantage of being simple and transparent
to the user and developer. Other approaches have other advantages:
Instead, one could introduce a variable INSTALL_VERSION that would
(It would have to be a variable stored in the metadata/ cache
and thus also would only work with a new API, but these are only
technical details.)
default to ${PVR} but could be set to the version of a previous
ebuild instead. The PM could compare it against INSTALL_VERSION in
the VDB and skip build and installation if versions match.
It should be a list and have empty default (*never* including the
version itself), but these are also technical details.
This solution would have the advantage that you could specify
*full* versions and thus have even more fine-grained control when
recompilations are necessary. One could also allow specify version
ranges, slots, overlays, etc., perhaps even make the behaviour
dependent of USE-flags, as you already mentioned, all
similarl to current DEPEND syntax.
The disadvantage is that it is slightly more work than -r1.1,
less transparent, and easily overlooked to remove for a version bump,
causing issues like these:
It will probably also cause confusion for comaintainers and
collaborators, especially when INSTALL_VERSION points to a version
that has already been removed.
I haven't had the energy to read all the mails over all the dynamic
deps thread...
the -r1.1 syntax has been in use by the prefix since early in it's
existence. I haven't kept track, but they may have finally done away
with it.
There are many other problems with using that syntax, namely most other
tools are not compatible with it, so more than just portage needs to be
modified. Adding that syntax to ebuilds will cause disruptions and bugs
for years to come.
So, please, forget about this syntax as a viable solution.
--
Brian Dolbec dolsen
Re: [gentoo-dev] Re: don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/07/14 10:43 AM, Ciaran McCreesh wrote:
On Mon, 28 Jul 2014 10:30:15 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
On 26/07/14 11:22 AM, Ciaran McCreesh wrote:
Let's start with the easiest issue: please point us all to the
place where you proved how dynamic dependencies still work in
the face of ebuild removals. Your solution to this problem will
be of great benefit to all of us.
This is something I personally don't understand. If an ebuild
for a package installed on the system has been removed from the
tree, but newer and/or older ebuilds exist in the tree, then the
installed package can #1 only be trusted in accordance with the
ebuild copy enbedded in VDB (that i get), BUT, #2 should be
forced to either upgrade or downgrade so that it matches what
*is* in the tree anyhow, and that's done via a standard ${PV}
comparison that should happen regardless of whether static or
dynamic deps methods are in place.
But you can't run pkg_prerm unless a package's dependencies are
satisfied. How do you know what those dependencies are, if you
don't use VDB and if the ebuild isn't there?
(This is a real issue: see the botched ruby-config switch.)
Yes, that's an issue -- I thought the pkg-*rm case had to do with the
ebuild's phase definition itself being (or not being) updated, I
haddn't thought about it in terms of dependencies being unsatisfied.
Keeping every single dependency around and valid just so that pkg_*rm
can completely cleanly seems like so much overkill, though..
Unfortunately the only way I see around that would be to have some
form of reduced subset, which would mean yet-another-*DEPEND, and we
all know that's not going to happen..
I wonder if there would be a way to somehow add restrictions to
pkg_*rm phases s.t. either REPLACED_BY_VERSION's dependencies must be
satisfied at the time the phases are run, or REPLACED_BY_VERSION is
empty and the in-VDB ones must be satisfied. It'll be a pain for
dev's to make sure their stuff works within these restrictions, and
the likeliness of repoman being able to enforce any sort of QA on this
probably so close to zero it doesn't matter, but i'm not seeing
another way.
(outside of forcing the in-vdb deps to always remain satisfied, of
course; however i think the dependencies-get-upgraded-first approach
which is generally necessary for all but PDEPEND can still cause
breakage here too, no??)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPWbpMACgkQ2ugaI38ACPBkdwEAsPg3Gu4I3LuXfBuvrxfGJ3D6
sv/ZOROo0a0xPzQ8IZgA/icJDURR+a0mrvT2fwSzXNfd+azvaaKxjNOcRPHOcSYE
=YElO
-END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, Jul 28, 2014 at 12:29 PM, Ian Stakenvicius a...@gentoo.org wrote: As has been mentioned or alluded to before, this is fine as long as end-users --sync when the dependency change is still in the tree. However, if that doesn't happen then we still end up with the issue. Of course, if that is the case, then #2 shouldn't happen either (because the end-user system wouldn't see B as having been removed and therefore --depclean won't remove it). Agree. Things stay consistent either way if everything is done properly. Bottom line is that if you keep PVs installed which aren't in portage, you're on your own. They could contain known bugs that we fixed in a revbump that you missed, or they could contain security issues that we don't bother to check for since we don't have the PV in our repository, etc. If you keep such a PV installed then you're the maintainer, so good luck! If a more recent version is in portage, then your old ebuild will probably uninstall cleanly (or at least as cleanly as it would with static deps), and the upgrade will hopefully be in better shape. Rich
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/07/14 05:08 PM, Rich Freeman wrote: On Sun, Jul 27, 2014 at 4:24 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-07-27, o godz. 10:42:19 Consider the following: 1. A depends on B, both are installed, 2. dependency on B is removed, emerge --depclean uninstalls B thanks to dynamic-deps, 3. B is treecleaned (nothing depends on it), 4. old version of A is removed (user doesn't update it yet), therefore dependency on B is restored from vdb. So, now user has package A installed which has unsatisfied dependency on non-available package. I'd think that portage should update vdb as soon as it detects the dependency change. Then B would no longer depend on A in vdb. It shouldn't hold onto outdated information. Basically a dependency change should trigger a no-rebuild merge if it is safe to do so, and if not there should be a revbump anyway. As has been mentioned or alluded to before, this is fine as long as end-users --sync when the dependency change is still in the tree. However, if that doesn't happen then we still end up with the issue. Of course, if that is the case, then #2 shouldn't happen either (because the end-user system wouldn't see B as having been removed and therefore --depclean won't remove it). ...why do i feel like i'm getting the same headache i had in my 2nd year databases course, when i was trying to wrap my head around ACID compliance and transaction visibility -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPWelAACgkQ2ugaI38ACPCokAEAvDNcn+kJ6WTpL+hMAjexRuJX mbHoj9pGsuFQ2kqoL7YA/1n9mZ2zDpVBurXLflU2KpqNgGx3E/ujozBOveHzoII+ =0Zgq -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/07/14 07:21 AM, Michał Górny wrote: Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius a...@gentoo.org napisał(a): Hey all.. So, putting aside for now how much of a mess this would be to implement in the virtuals' ebuilds themselves, what do people think of changing the virtuals so that they contain an entry in IUSE for each provider that can satisfy it? The idea here is that the package satisfying a virtual could be optionally explicitly-chosen through package.use (or USE= in make.conf, perhaps) instead of having an entry in @world, that way if nothing depends on the virtual then it and the provider can be - --depclean'ed from the system. The idea is specifically NOT to have rdeps depend on these flags, that would undermine the whole purpose of the virtual; it would just be for end-users to set if they so chose. I think I don't get this argument. If you really want to have a particular provider for the virtual for external purposes, it's fully purposeful to put it in @world or otherwise in a custom set. In this case, USE flags aren't helpful. The argument I was trying to make is that USE flags would allow end-users to accomplish the same thing, while not having an entry in @world and therefore allowing the package to be --depclean'ed if the virtual is --depcleaned. I personally don't use sets so i've no idea if the exact same thing could be accomplished in sets; for some reason i don't think so. If you only prefer a particular provider, you can tip portage easily to use it without resorting to USE flags. This also allows portage to semi-transparently switch to other provider if dependencies need it. In this case, USE flags only make this auto-switching harder. That is the other part of this idea, to make auto-switching harder, because right now portage likes to auto-switch even when it seems like it shouldn't. I figure this idea would also help with Ciaran's wishlist item of ||() deps becoming more strictly-controlled and readily deterministic. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPWgi8ACgkQ2ugaI38ACPBfoQD/bZmCxCdLM9EyeJRrst5QmD9X NS2Y0HCNhRnCfAuplUYA/2UHibYB6YHdKOi40RkWOUA0KMTRSwXYPR6dYsmByiQL =njwB -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a
AX == Alex Xu alex_y...@yahoo.ca writes: AX Please don't crosspost followup messages, especially to the same mailing AX list twice. Ick. I didn't notice the cc details when I replied. ☹ -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] Re: don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/07/14 08:04 AM, Rich Freeman wrote: On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric kentfred...@gmail.com wrote: In a no dynamic deps, period scenario, this just strikes me as 2 flavours of the same weirdness, -r2 and -r1.1 are just equally weird choices to make if the ebuild itself doesn't change at all. You have a good point here. With this proposal we have three kinds of ebuild changes: 1. Those that do not involve any revbump. 2. Those with a minor revbump (ie -r1 - -r1.1). 3. Those with a normal revbump (ie -r1 - -r2). What is the purpose of allowing the first? Presumably that should be used in even more limited circumstances than a minor revbump, so why allow it at all? Why not just make an in-place change equivalent to a minor revbump and ditch the minor revbump entirely? Devs would still need to distinguish between what requires a revbump and what does not. Doing this would require having portage cache a hash of whatever ebuild it last parsed, and perhaps its eclasses as well if we permit revbump-less eclass changes. Then it would have to check for when these change, perhaps this might be stored in the metadata to speed things up. You could view such an approach as being equivalent to just sticking a .hash on every ebuild in the tree as a minor revision tag, so that any change triggers a minor revision. The only difference between that and the proposal that I can see is that the minor revisions would be unordered. However, if we go with the theory that defective ebuilds get removed immediately then there is no point in ordering minor revisions because there will only be one in the tree at any time for a given major revision, so the package manager couldn't take advantage of any information conveyed by ordering. This probably isn't too different from what portage is doing already, except: 1. Portage is only looking for dependency changes when it has another reason to look closely at the ebuild - it has no mechanism to detect that an ebuild changes, and this would add one. 2. We don't have any clear policies today on when ebuilds should be revbumped or not as the result of things like dependency changes, and this would cause us to make some. The fact that this isn't a big change does concern me that it may not fix all of the underlying problems. However, some of those problems might not actually have clean solutions other than never committing mistakes in the first place. For example, if a prerm dependency was missing then removing the ebuild can potentially fail whether you use dynamic deps or not until it is satisfied. The primary underlying problem I see about this is that it doesn't force devs to start doing something to the tree that will suddenly help make all of the static-deps-only PMs (ie, those that aren't going to implement this new hash-changed-so-re-evaluate-ebuild method) suddenly work in a more consistent fashion. IIRC, the very first post of this thread was a reminder to dev's to revbump so that static-deps behaviour is more correct/consistent. However, if we put something into the next EAPI about this and make it a requirement for all PMs (although I have no idea how we would roll this out; maybe make it a profile-level requirement instead of an ebuild-level one, if there is such a thing??) then it would become much less of an issue.. Mind you, we need to solve all of the problems first and make sure PMS documents all of the requirements in an appropriately complete and ambiguity-preventing manner that everyone agrees with.. Easy, right? :) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPWlfYACgkQ2ugaI38ACPApTwD9H+PX4f1XGtauwbjfXczPqAYf yBqDW9MOwIlWPCqeu6IA/ipySyWxA/J12RSuLTNyj98li9Qmeq0GLR37KSZ2Cc/p =05lZ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Mon, Jul 28, 2014 at 2:27 PM, Ian Stakenvicius a...@gentoo.org wrote: The primary underlying problem I see about this is that it doesn't force devs to start doing something to the tree that will suddenly help make all of the static-deps-only PMs (ie, those that aren't going to implement this new hash-changed-so-re-evaluate-ebuild method) suddenly work in a more consistent fashion. IIRC, the very first post of this thread was a reminder to dev's to revbump so that static-deps behaviour is more correct/consistent. I think the intent here is to define how we want the PM to behave, and what kinds of changes should require revbumps (ie those the PM can't handle otherwise). Obvious a side-effect of this will be that PMs that don't behave as we intend them to may have issues. However, if we put something into the next EAPI about this and make it a requirement for all PMs (although I have no idea how we would roll this out; maybe make it a profile-level requirement instead of an ebuild-level one, if there is such a thing??) It may make sense to do this via a new EAPI, though I think figuring out what we want to do comes first. That is, I want to ask the question if no PMs existed and we were writing our first one, how would we want it to behave? Getting from here to there is the next problem. Really the issue comes down to how we maintain ebuilds. If we aren't revbumping for dependency errors, then PMs that don't handle dynamic deps wouldn't update their dependencies. That certainly has consequences, but whether they're considered bugs/problems/etc is a bit up for debate. I'm not convinced that it makes sense to do micro-revbumps just to force PMs that don't have any concept of dynamic dependencies to treat them as full revbumps. Devs can still forget to do them, and it results in churn that doesn't seem necessary to me. On the other hand I don't want to make life even more difficult on those using alternative PMs (though it sounds like we're doing this already). It seems like we aren't getting many more new options here. Rich
[gentoo-dev] Re: don't rely on dynamic deps
Peter Stuge pe...@stuge.se wrote:
Martin Vaeth wrote:
The user's vardb could then automatically receive the last state of
the ebuild, before it was removed.
It doesn't help reliably, either, since the last state of the ebuild,
before it was removed, will be outdated at some point, too.
Sorry, I don't see how. Can you give an example? Thanks!
1. foo depends on bar
2. user installs foo
3. foo is treecleaned
4. bar ebuild is replaced by the pair bar-base and bar-gui to
allow for finer dependency. All ebuilds in the tree take
care about this new structure (possibly with revbumps).
Of course, the dependency for an already removed package
is not fixed.
5. bar{-base,gui} gets several upgrades.
6. foo on user's system still blocks bar from being removed
and thus blocks the installation of bar-base and bar-gui
forever.
Alternatively (if no conflict arises), foo depends forever on an
ancient (hence possibly full of security bugs) version of bar
which should have been upgraded ages ago.
In both cases of 6., the user is not even aware that he uses
long obsolete packages unless portage prints a big fat warning
for orphaned packages (which currently is not the case.
Well, at least eix -t will be print a message.)
Note that 4. cannot be replaced by any pushing mechanism,
since only the maintainer of the ebuild can know which is
the right dependency for the new tree structure. Such a
maintainer does not exist for treecleaned packages (which
is the purpose of treecleaning, after all...)
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Mon, Jul 28, 2014 at 2:50 PM, Martin Vaeth mar...@mvath.de wrote: In both cases of 6., the user is not even aware that he uses long obsolete packages unless portage prints a big fat warning for orphaned packages (which currently is not the case. Well, at least eix -t will be print a message.) This is really the crux of these sorts of issues. It doesn't matter if dependencies are static or dynamic - if you hang onto orphans then you're going to have cruft in your vdb which is going to lead to blockers of some kind eventually. Portage should probably generate a warning when there are orphan packages. The same is true if you keep cruft in a local overlay or such. We can have all the pretty virtuals/etc we want, but if users stick hard-coded obsolete package names in their overlays or have them in their vdb, then they're going to get blockers. Though, we could do a better job with the error messages even when that happens... Rich
[gentoo-dev] Re: don't rely on dynamic deps
Ian Stakenvicius a...@gentoo.org wrote: Keeping every single dependency around and valid just so that pkg_*rm can completely cleanly seems like so much overkill, though.. It is not only overkill, it would require a merging strategy which AFAIK portage currently does not use and which would lead to blockers: If you really want to guarantee that all := dependencies are satisfied in the moment of unmerging, you need to do the following. Assume foo depends on bar:=. Now if bar gets an upgrade, first foo must be unmerged, then bar must be upgraded, and then foo must be reemerged. If you have a circular dependency of := chains, an upgrade is impossible forever: You would manually have to break this chain by setting some useflags exactly in the same way as you did when you manages to install the chain for the first time. Otherwise, you will just miss the possibly avilable updates forever. The problems if you really want to guarantee that all dependencies are still installed when unmerging a package are hardly reasonably solvable. One should better make a rule that if an ebuild has such a special requirement that it needs a certain version for being unmerged, it must block all other versions (one could make a syntax for the := case or even disallow this case for such ebuilds) instead of letting the PM jump through hoops for the normal cases.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Mon, 28 Jul 2014 11:02:58 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 28/07/14 09:41, Samuli Suominen wrote: On 27/07/14 22:01, Markus Meier (maekke) wrote: maekke 14/07/27 19:01:15 Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild Log: add ~arm, bug #510340 Package bumping is done by, eg.: # cp x265-.ebuild x265-1.3.ebuild And then, # grep *.ebuild x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild:KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild Fixed that for you. Thanks. Regards, Markus signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild:KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild Wait, what? Live ebuilds are keyworded now? Denis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On 28/07/14 08:15 PM, Denis Dupeyron wrote: On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild:KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild Wait, what? Live ebuilds are keyworded now? Denis. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/x265/x265-.ebuild?revision=1.9view=markup#l9 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
Denis Dupeyron posted on Mon, 28 Jul 2014 18:15:20 -0600 as excerpted: On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild: KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild Wait, what? Live ebuilds are keyworded now? AFAIK, gentoo policy is that live ebuilds should always be masked so as never to be automatically pulled in without a deliberate unmasking of the live ebuild, but whether that's masked due to lack of keywords (ebuild), or due to hard-mask (package.mask) is I believe up to the maintainer. For packages like this one where normal version-bumps start with the live ebuild (which after all should have been updated as development proceeded, upstream), simply copying it to the appropriate version-number ebuild, keeping it ~arch-keyworded on all archs where the non-live version is at least ~arch-keyworded, and using package.mask to force the masking, makes the most sense since then a version bump can literally amount to no more than an ebuild copy and manifest (tho obviously the maintainer will test it too, but ideally won't have to actually touch the content of the file). -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Mon, Jul 28, 2014 at 12:02 PM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/07/14 07:21 AM, Michał Górny wrote: Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius a...@gentoo.org napisał(a): Hey all.. So, putting aside for now how much of a mess this would be to implement in the virtuals' ebuilds themselves, what do people think of changing the virtuals so that they contain an entry in IUSE for each provider that can satisfy it? The idea here is that the package satisfying a virtual could be optionally explicitly-chosen through package.use (or USE= in make.conf, perhaps) instead of having an entry in @world, that way if nothing depends on the virtual then it and the provider can be - --depclean'ed from the system. The idea is specifically NOT to have rdeps depend on these flags, that would undermine the whole purpose of the virtual; it would just be for end-users to set if they so chose. I think I don't get this argument. If you really want to have a particular provider for the virtual for external purposes, it's fully purposeful to put it in @world or otherwise in a custom set. In this case, USE flags aren't helpful. The argument I was trying to make is that USE flags would allow end-users to accomplish the same thing, while not having an entry in @world and therefore allowing the package to be --depclean'ed if the virtual is --depcleaned. I personally don't use sets so i've no idea if the exact same thing could be accomplished in sets; for some reason i don't think so. If you only prefer a particular provider, you can tip portage easily to use it without resorting to USE flags. This also allows portage to semi-transparently switch to other provider if dependencies need it. In this case, USE flags only make this auto-switching harder. That is the other part of this idea, to make auto-switching harder, because right now portage likes to auto-switch even when it seems like it shouldn't. I figure this idea would also help with Ciaran's wishlist item of ||() deps becoming more strictly-controlled and readily deterministic. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPWgi8ACgkQ2ugaI38ACPBfoQD/bZmCxCdLM9EyeJRrst5QmD9X NS2Y0HCNhRnCfAuplUYA/2UHibYB6YHdKOi40RkWOUA0KMTRSwXYPR6dYsmByiQL =njwB -END PGP SIGNATURE- Also, what about the case where multiple providers for the same virtual are installed but the first doesn't satisfy the dependency? Currently, portage only looks at the installed state of the providers, in order, and will use the first installed provider it finds even if it doesn't actually satisfy the dependency (e.g. due to use deps) and the dependency is already satisfied by a different installed provider. Paludis has an elegant solution for this situation (-F/-A), but afaik portage doesn't. Use flags in virtuals would solve this without having to hack around in portage and have it check all possible deps before choosing one. --James
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
Dnia 2014-07-28, o godz. 13:02:39 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/07/14 07:21 AM, Michał Górny wrote: Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius a...@gentoo.org napisał(a): Hey all.. So, putting aside for now how much of a mess this would be to implement in the virtuals' ebuilds themselves, what do people think of changing the virtuals so that they contain an entry in IUSE for each provider that can satisfy it? The idea here is that the package satisfying a virtual could be optionally explicitly-chosen through package.use (or USE= in make.conf, perhaps) instead of having an entry in @world, that way if nothing depends on the virtual then it and the provider can be - --depclean'ed from the system. The idea is specifically NOT to have rdeps depend on these flags, that would undermine the whole purpose of the virtual; it would just be for end-users to set if they so chose. I think I don't get this argument. If you really want to have a particular provider for the virtual for external purposes, it's fully purposeful to put it in @world or otherwise in a custom set. In this case, USE flags aren't helpful. The argument I was trying to make is that USE flags would allow end-users to accomplish the same thing, while not having an entry in @world and therefore allowing the package to be --depclean'ed if the virtual is --depcleaned. If you need it externally, you need it not depcleaned, obviously. So you have to have something in @world. If you need a specific implementation, it's more elegant to put that in @world rather than the virtual and playing with USE flags. If you only prefer a particular provider, you can tip portage easily to use it without resorting to USE flags. This also allows portage to semi-transparently switch to other provider if dependencies need it. In this case, USE flags only make this auto-switching harder. That is the other part of this idea, to make auto-switching harder, because right now portage likes to auto-switch even when it seems like it shouldn't. This is a bug in portage and should be fixed there. As I said, working it around will only fix it for one package, and it will happen again and again, possibly in cases harder to pinpoint. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Pending changes to Portage ebuild behavior
Am 28.07.2014 17:03, schrieb Michał Górny: Hello, everyone. New install --- 1. no /usr/lib/portage/pym (it's not really necessary with python_targets), We need to make that emerge -C prevents the removal of the last python version for which portage is installed then. That may already work. 2. all python modules bytecode in site-packages, 3. emerge and other tools load portage from site-packages [proper bytecode used], Other tools already do that. Emerge is a different thing. It's not a tool based on portage. emerge and portage are two large, interconnected things. (run git grep _emerge in pym/portage) 4. but python modules need to be able to locate /usr/lib/portage/bin somehow. What about hardcoding this path at install time? Looking at pkgcore might give you some hints.
