Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Mon, 28 Jul 2014 23:23:04 -0500 James Potts wrote: > Paludis has an elegant solution for this situation (-F/-A), but afaik > portage doesn't. I'd not call -F / -A elegant... It's a nasty trick that we only added because || dependencies are such a pain. They shouldn't be necessary. -- Ciaran McCreesh signature.asc Description: PGP signature
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 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 > > 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-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 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 >> 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
-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 > 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] 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 > 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
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 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] 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] RFC: USE flags in virtuals, to allow a specific provider to be determined
Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius 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
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
Manuel Rüger wrote: > 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, You should know that it's the other way around. freebsd-lib isn't to blame, but >=dev-libs/libusb-1.0.18 is. //Peter pgpDwzxkEwu11.pgp Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
El vie, 25-07-2014 a las 21:18 +0100, Ciaran McCreesh escribió: > On Fri, 25 Jul 2014 22:12:53 +0200 > Pacho Ramos wrote: > > Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I > > guess it was for simplifying ebuilds? > > It was a historical mistake: originally we were going to use > pkg_pretend for this. But claims were made that this would break some > mythical auto-building systems, and that something machine-readable was > needed. Unfortunately the Council bought this, and put through > REQUIRED_USE without a reference implementation. > > Needless to say, the end result is something that isn't human-readable, > and isn't used by any mythical auto-building systems. > > (Incidentally, Exherbo has a both human- and machine-readable > implementation, which *is* used by an auto-building system, but the > syntax won't meet Gentoo approval...) > Maybe REQUIRED_USE could allow us to set an error message for each line to allow us to instruct PMs about what message should they who to the users :/ (it would show our message that should be more clear, a bit like we are able to do with "die 'message'")
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On 25/07/14 23:09, Ian Stakenvicius wrote: > On 25/07/14 04:41 PM, Michał Górny wrote: >> Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius >> napisał(a): > >>> +REQUIRED_USE="heimdal? ( !mit-krb5 ) + mit-krb5? ( >>> !heimdal )" > >> Did you mean: > >> REQUIRED_USE="^^ ( heimdal mit-krb5 )" > >> ? > > > > Nope, that requires one or the other to be set. If users don't care, > they shouldn't have to set one at all. > > REQUIRED_USE="?? ( heimdal mit-krb5 )" from EAPI=5 would do that. """ REQUIRED_USE supports new at-most-one-of operator The new at-most-one-of operator consists of the string '??', and is satisfied if zero or one (but no more) of its child elements is matched. """ Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 16:46:07 -0500 William Hubbs wrote: > On Fri, Jul 25, 2014 at 10:25:57PM +0100, Ciaran McCreesh wrote: > > On Fri, 25 Jul 2014 16:23:23 -0500 > > William Hubbs wrote: > > > I think this could get complicated really quick though. > > > For example, if I have an ebuild with three use flags, > > > flag1/flag2/flag3 with the requirement that one and only one of > > > them must be set, unless bash has an xor operator I don't know > > > about, that is going to need a lot of nesting etc to get right. > > > > You don't want xor. You want addition. > > Can you show an example? Well, if the use flag is on, you count it as 1, and if it's off, you count it as 0. Then "need at least one" is just "the sum of these values is at least 1", and "need exactly one" is "the sum of these values is exactly 1". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, Jul 25, 2014 at 10:25:57PM +0100, Ciaran McCreesh wrote: > On Fri, 25 Jul 2014 16:23:23 -0500 > William Hubbs wrote: > > I think this could get complicated really quick though. > > For example, if I have an ebuild with three use flags, > > flag1/flag2/flag3 with the requirement that one and only one of them > > must be set, unless bash has an xor operator I don't know about, that > > is going to need a lot of nesting etc to get right. > > You don't want xor. You want addition. Can you show an example? Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 16:23:23 -0500 William Hubbs wrote: > I think this could get complicated really quick though. > For example, if I have an ebuild with three use flags, > flag1/flag2/flag3 with the requirement that one and only one of them > must be set, unless bash has an xor operator I don't know about, that > is going to need a lot of nesting etc to get right. You don't want xor. You want addition. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 17:13:18 -0400 Ian Stakenvicius wrote: > REQUIRED_USE came first, pkg_pretend came later, iirc. In theory, > REQUIRED_USE could have made a nice interactive way to resolve use > conflicts, it just never did. Nope. pkg_pretend came first, and had an implemented and user-tested prototype. REQUIRED_USE was shoehorned in at the last minute without an implementation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, Jul 25, 2014 at 03:54:53PM -0400, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 25/07/14 03:51 PM, Pacho Ramos wrote:
> > El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
> >> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
> >> wrote:
> >>> Okay, I didn't think of that. I'm not sure if the blocker deps
> >>> or the REQUIRED_USE would be more helpful for Portage, but
> >>> generally I think that the REQUIRED_USE error message is quite
> >>> hard to understand for unexperienced users -- much more so than
> >>> the error generated by a blocker dep.
> >>
> >> ...and the fix for that is to scrap REQUIRED_USE and use
> >> pkg_pretend instead.
> >>
> >
> > Could you give an example to let us see how pkg_pretend could be
> > used to achieve the same as REQUIRED_USE?
> >
> > Thanks
> >
> >
>
> pkg_pretend() {
> if use heimdal && use mit-krb5; then
> eerror "Please set only one of the use following flags:"
> eerror "heimdal, mit-krb5"
> die "conflicting use flags set"
> fi
> }
I think this could get complicated really quick though.
For example, if I have an ebuild with three use flags,
flag1/flag2/flag3 with the requirement that one and only one of them
must be set, unless bash has an xor operator I don't know about, that
is going to need a lot of nesting etc to get right.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/07/14 04:12 PM, Pacho Ramos wrote:
> El vie, 25-07-2014 a las 15:54 -0400, Ian Stakenvicius escribió:
>> On 25/07/14 03:51 PM, Pacho Ramos wrote:
>>> El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh
>>> escribió:
On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
wrote:
> Okay, I didn't think of that. I'm not sure if the blocker
> deps or the REQUIRED_USE would be more helpful for Portage,
> but generally I think that the REQUIRED_USE error message
> is quite hard to understand for unexperienced users -- much
> more so than the error generated by a blocker dep.
...and the fix for that is to scrap REQUIRED_USE and use
pkg_pretend instead.
>>>
>>> Could you give an example to let us see how pkg_pretend could
>>> be used to achieve the same as REQUIRED_USE?
>>>
>>> Thanks
>>>
>>>
>>
>> pkg_pretend() { if use heimdal && use mit-krb5; then eerror
>> "Please set only one of the use following flags:" eerror
>> "heimdal, mit-krb5" die "conflicting use flags set" fi }
>
> Ah, ok, I was wondering why REQUIRED_USE was implemented then :/,
> I guess it was for simplifying ebuilds?
>
>
REQUIRED_USE came first, pkg_pretend came later, iirc. In theory,
REQUIRED_USE could have made a nice interactive way to resolve use
conflicts, it just never did.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPSyG4ACgkQ2ugaI38ACPC07wD/VnEG/w0nvYlNsVJszyPXgK0l
Z9YZ3zWOeMffAJiM7NQBAI8x5G5+EXgCrd8gGAA20ENZ5RIuN6qJoE1INRY6x84+
=6L9c
-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 25/07/14 04:41 PM, Michał Górny wrote: > Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius > napisał(a): > >> +REQUIRED_USE="heimdal? ( !mit-krb5 ) + mit-krb5? ( >> !heimdal )" > > Did you mean: > > REQUIRED_USE="^^ ( heimdal mit-krb5 )" > > ? > Nope, that requires one or the other to be set. If users don't care, they shouldn't have to set one at all. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPSx5cACgkQ2ugaI38ACPCJQgD/TxYSU4AUzGWqEmG/Y+rM50Jr 4m25kOPR+DCp17Gr4SIA/1lu1gBm4fL/ZwDXe5lpy0N+FZmJjhdB0guhJGGieH7S =pMB6 -END PGP SIGNATURE-
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 napisał(a): > +REQUIRED_USE="heimdal? ( !mit-krb5 ) > + mit-krb5? ( !heimdal )" Did you mean: REQUIRED_USE="^^ ( heimdal mit-krb5 )" ? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 22:12:53 +0200 Pacho Ramos wrote: > Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I > guess it was for simplifying ebuilds? It was a historical mistake: originally we were going to use pkg_pretend for this. But claims were made that this would break some mythical auto-building systems, and that something machine-readable was needed. Unfortunately the Council bought this, and put through REQUIRED_USE without a reference implementation. Needless to say, the end result is something that isn't human-readable, and isn't used by any mythical auto-building systems. (Incidentally, Exherbo has a both human- and machine-readable implementation, which *is* used by an auto-building system, but the syntax won't meet Gentoo approval...) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
El vie, 25-07-2014 a las 15:54 -0400, Ian Stakenvicius escribió:
> On 25/07/14 03:51 PM, Pacho Ramos wrote:
> > El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
> >> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
> >> wrote:
> >>> Okay, I didn't think of that. I'm not sure if the blocker deps
> >>> or the REQUIRED_USE would be more helpful for Portage, but
> >>> generally I think that the REQUIRED_USE error message is quite
> >>> hard to understand for unexperienced users -- much more so than
> >>> the error generated by a blocker dep.
> >>
> >> ...and the fix for that is to scrap REQUIRED_USE and use
> >> pkg_pretend instead.
> >>
> >
> > Could you give an example to let us see how pkg_pretend could be
> > used to achieve the same as REQUIRED_USE?
> >
> > Thanks
> >
> >
>
> pkg_pretend() {
> if use heimdal && use mit-krb5; then
> eerror "Please set only one of the use following flags:"
> eerror "heimdal, mit-krb5"
> die "conflicting use flags set"
> fi
> }
Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I
guess it was for simplifying ebuilds?
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/07/14 03:51 PM, Pacho Ramos wrote:
> El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
>> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
>> wrote:
>>> Okay, I didn't think of that. I'm not sure if the blocker deps
>>> or the REQUIRED_USE would be more helpful for Portage, but
>>> generally I think that the REQUIRED_USE error message is quite
>>> hard to understand for unexperienced users -- much more so than
>>> the error generated by a blocker dep.
>>
>> ...and the fix for that is to scrap REQUIRED_USE and use
>> pkg_pretend instead.
>>
>
> Could you give an example to let us see how pkg_pretend could be
> used to achieve the same as REQUIRED_USE?
>
> Thanks
>
>
pkg_pretend() {
if use heimdal && use mit-krb5; then
eerror "Please set only one of the use following flags:"
eerror "heimdal, mit-krb5"
die "conflicting use flags set"
fi
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPStg0ACgkQ2ugaI38ACPDSMQD/UfMayFMJPP3VqzEvR5IwbBjX
w3/JiWDgm6NcYnU+ZTUBAIACTI52ZJn+TUvxWHHwggEv1+ThwIAp5rOIUUl68fce
=MX30
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió: > On Fri, 25 Jul 2014 21:44:02 +0200 > Luis Ressel wrote: > > Okay, I didn't think of that. I'm not sure if the blocker deps or the > > REQUIRED_USE would be more helpful for Portage, but generally I think > > that the REQUIRED_USE error message is quite hard to understand for > > unexperienced users -- much more so than the error generated by a > > blocker dep. > > ...and the fix for that is to scrap REQUIRED_USE and use pkg_pretend > instead. > Could you give an example to let us see how pkg_pretend could be used to achieve the same as REQUIRED_USE? Thanks
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/07/14 03:46 PM, Ciaran McCreesh wrote: > On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel > wrote: >> Okay, I didn't think of that. I'm not sure if the blocker deps or >> the REQUIRED_USE would be more helpful for Portage, but generally >> I think that the REQUIRED_USE error message is quite hard to >> understand for unexperienced users -- much more so than the error >> generated by a blocker dep. > > ...and the fix for that is to scrap REQUIRED_USE and use > pkg_pretend instead. > Yep, could do it that way instead. I'm not tied to any particular implementation. Back to the concept, though -- thoughts? Is it worth the work? Should it be avoided for whatever reason? Will it just confuse end-users? Am I suggesting a fix for a problem we don't really have? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPStOIACgkQ2ugaI38ACPCZrwD+J7qqH5a1YVsFoIt+UmT9rOLq TSkd6ai7Eum0MEo6CKsA/3Gsuu9O16rua/LZxeW3i3+qBFufIBDQPqU9YwAyU5lJ =VMCu -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel wrote: > Okay, I didn't think of that. I'm not sure if the blocker deps or the > REQUIRED_USE would be more helpful for Portage, but generally I think > that the REQUIRED_USE error message is quite hard to understand for > unexperienced users -- much more so than the error generated by a > blocker dep. ...and the fix for that is to scrap REQUIRED_USE and use pkg_pretend instead. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 15:23:47 -0400 Ian Stakenvicius wrote: > This is something that should only be done on a case-by-case basis, as > needed -- for instance, with virtual/krb5 only one provider can be > installed at a time as they block eachother. > > We could leave it up to portage to error on mit-krb5 and heimdal being > forced into the installation despite blocking eachother, but i think > portage would have a better chance telling end-users about the > conflict (and maybe helping to resolve it better via --autounmask?) if > there was a REQUIRED_USE. Okay, I didn't think of that. I'm not sure if the blocker deps or the REQUIRED_USE would be more helpful for Portage, but generally I think that the REQUIRED_USE error message is quite hard to understand for unexperienced users -- much more so than the error generated by a blocker dep. " The following REQUIRED_USE flag constraints are unsatisfied: heimdal? ( !mit-krb5 ) mit-krb5? ( !heimdal )" " might be a bit confusing to some people, and remember that constraint string would grow much longer if there were more providers, as grows quadratically. Regards, Luis Ressel 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 25/07/14 03:04 PM, Luis Ressel wrote: > I guess that would solve some of the issues we've had with virtuals > in the past. I support the idea, however, I'm not sure of the > technical consequences it might have. > > I would leave the REQUIRED_USE out. It's a hassle to write, and if > an user decides to set multiple use flags on such a virtual, why > not just let him do it? > This is something that should only be done on a case-by-case basis, as needed -- for instance, with virtual/krb5 only one provider can be installed at a time as they block eachother. We could leave it up to portage to error on mit-krb5 and heimdal being forced into the installation despite blocking eachother, but i think portage would have a better chance telling end-users about the conflict (and maybe helping to resolve it better via --autounmask?) if there was a REQUIRED_USE. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPSrsMACgkQ2ugaI38ACPB6NgD+NK2m8iM46YMi9kITUFEIQ/ih J67PjULbQ5ZHDRQDUs4A/ik+XNbsjNQwFd08jMD1dVG0DLr7VRVvUGz1VpmQB7so =Myry -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
I guess that would solve some of the issues we've had with virtuals in the past. I support the idea, however, I'm not sure of the technical consequences it might have. I would leave the REQUIRED_USE out. It's a hassle to write, and if an user decides to set multiple use flags on such a virtual, why not just let him do it? Regards, Luis Ressel signature.asc Description: PGP signature
[gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPSpsgACgkQ2ugaI38ACPCBGwD6A7Dlras5l/L9Fc1SA8K8oR3K LQKY5g/vbdvYFKtooDoBAKdLiFySl24mHKA0O2YScxmr4g5tvusVAd3dxWTIjnat =gSFT -END PGP SIGNATURE-
