[gentoo-dev] Re: don't rely on dynamic deps
hasufell posted on Fri, 25 Jul 2014 15:44:47 + as excerpted: > Sounds like that would be an interesting gentoo project. But afais PMS > doesn't really specify how binary packages should look like, so we will > hit incompatibility problems there as well. AFAIK binpkgs are purely an individual PM feature, considered outside the domain of PMS. Unless things have changed, paludis doesn't support them at least in portage form and there's active antipathy toward adding that (altho I believe there was discussion of adding rpm support at one point). I don't know whether pkgcore supports them or not, tho if it does, I suspect its support is close to the portage-native form. But while I believe someone's working on pkgcore again now, until it gets EAPI-5 support it's pretty much out of the picture anyway. Gentoo did at one point do binpkg ISO-images, but I've not seen or heard anything of that in years, and of course while they did form a convenient quick-install foundation, they were quickly outdated, and there was no gentoo-only mechanism to continue with binpkgs -- you did your quick- install from binpkg, optionally changed any USE flags you wanted and rebuilt using --newuse, and continued with conventional gentoo build-from- source after that. Meanwhile, it's worth noting that a mostly from-sources distro such as gentoo has the luxury of bypassing many of the legal issues involved with binary distribution. Among other things there's the patent issues that don't normally apply (at least in the US) to source distribution due to freedom-of-speech-overrides, and the gpl source provision (including our patches) obligations as well. Partially for that reason, gentoo as a distribution has in the past chosen to deemphasize binaries and leave most of the binary distribution angle to the gentoo-based distros. That lets us continue focusing on what we do best, while leaving the gentoo-based distros a bit more space to work on what they can do better. While there'd certainly be some convenience to a binaries server, is it really going to be worth the cost, in legal hassle, in blurring our sources focus, and in killing that exclusive niche for our downstream distros? Meanwhile, a question for the infra and foundation folks: A quick look at the the download links and mirrors says that we're still distributing 10.1 images for at least x86 and amd64. Based on the file-dates on the mirrors, that was 2009, and I don't see corresponding links to sources, which means at least for the gplv2 binaries on those images, we're obligated to provide sources, including our patches, until 2017 (three years from now) and counting. While the ebuilds and tarballs aren't likely to be a huge issue, are we sure we have those patches archived and will until three years after we quit distributing those binaries, such that we can provide them on-demand? If not, those images need to come down. -- 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 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
[gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted: > 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. What about handling each such virtual_USE as a USE_EXPAND? VIRTUAL_* as reserved-namespace USE_EXPAND would give us full backward compatibility along with an immediately identifiable namespace and virtually (heh) no possibility of confusion with other configuration. Continuing with the earlier virtual/krb5 example, we'd have VIRTUAL_KRB5, with possible settings in make.conf of: VIRTUAL_KRB5=mit-krb5 VIRTUAL_KRB5=heimdal Virtually no possibility of confusion with normal USE flags, and the matching virtual would be immediately identifiable, so no possibility of getting confused on what it applies to, either. -- 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
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] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
El sáb, 26-07-2014 a las 08:05 +, Duncan escribió: > Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted: > > > 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. > > What about handling each such virtual_USE as a USE_EXPAND? VIRTUAL_* as > reserved-namespace USE_EXPAND would give us full backward compatibility > along with an immediately identifiable namespace and virtually (heh) no > possibility of confusion with other configuration. > > Continuing with the earlier virtual/krb5 example, we'd have VIRTUAL_KRB5, > with possible settings in make.conf of: > > VIRTUAL_KRB5=mit-krb5 > VIRTUAL_KRB5=heimdal > > Virtually no possibility of confusion with normal USE flags, and the > matching virtual would be immediately identifiable, so no possibility of > getting confused on what it applies to, either. > I would also prefer to use USE_EXPAND to not mix normal USEs with virtuals... but I would go with using the same "VIRTUAL" variable for all virtuals, otherwise people will end up having dozens of VIRTUAL_ statements in make.conf (one per virtual package)
Re: [gentoo-dev] About current ppc/ppc64 status
El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió: > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote: > > On 07/25/14 15:50, Pacho Ramos wrote: > > > El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió: > > >> On 07/25/14 15:28, Pacho Ramos wrote: > > >>> That is the reason for me thinking that maybe the way to go would be to > > >>> do the opposite -> keep only base-system and a few others stable and > > >>> drop stable for most of the rest. This big effort could be accomplished > > >>> in a week by other developers willing to help (like me) and would solve > > >>> the issue for the long term. I guess that is what HPPA team did in the > > >>> past and I think it's working pretty well for them (in summary, have a > > >>> stable tree they are able to keep stable). That will also help people in > > >>> ppc* teams to know that the remaining stabilization bugs, apart of being > > >>> much less, are important enough to deserve rapid attention, as opposed > > >>> to current situation that will have some important bugs mixed with tons > > >>> of stabilization requests of apps that got ppc stable keywords years ago > > >>> and are currently no so important. > > >>> > > >> Yes, please let's just do base system stable. I've been randomly taking > > >> care of ppc but nothing systematic. Its pretty spotty. But at the same > > >> time I don't like the idea of just loosing all the stabilization effort > > >> on the base system, so that might work best. Something to think about > > >> for mips too. > > >> > > >> > > > Nice, one think we would need to discuss is what do we consider base > > > system :/ > > > > > > I guess packages maintained by base-system, toolchain and... xorg-server > > > and co... what more > > > > > > Not sure if we could have a list of current stable tree for ppc*, once > > > do we have that list, ppc* teams can drop from that list what they want > > > and we get a new list that will be the final result. What do you think > > > about that? > > > > > > > > > > At the very least, its what's needed to build the stages with catalyst. > > I would think we should start with base/packages, but I don't want to > > limit it to just those because I at least need a more for building and > > maintaining. Where should we start to compile such a list? > > If we are going to do this, I think we should drop these arch's > to exp status in the profiles. That way, it keeps repoman from bothering > the rest of us about stabilizations, and we don't have to worry about > filing stable requests on them. > > That would let you stabilize things that you need to build the stages. > > William > But, moving ppc* to exp wouldn't lead us to likely break their tree? (because we wouldn't get any dependency issue even with "base" packages...)
Re: [gentoo-dev] About current ppc/ppc64 status
El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió: > El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió: > > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote: > > > On 07/25/14 15:50, Pacho Ramos wrote: > > > > El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió: > > > >> On 07/25/14 15:28, Pacho Ramos wrote: > > > >>> That is the reason for me thinking that maybe the way to go would be > > > >>> to > > > >>> do the opposite -> keep only base-system and a few others stable and > > > >>> drop stable for most of the rest. This big effort could be > > > >>> accomplished > > > >>> in a week by other developers willing to help (like me) and would > > > >>> solve > > > >>> the issue for the long term. I guess that is what HPPA team did in the > > > >>> past and I think it's working pretty well for them (in summary, have a > > > >>> stable tree they are able to keep stable). That will also help people > > > >>> in > > > >>> ppc* teams to know that the remaining stabilization bugs, apart of > > > >>> being > > > >>> much less, are important enough to deserve rapid attention, as opposed > > > >>> to current situation that will have some important bugs mixed with > > > >>> tons > > > >>> of stabilization requests of apps that got ppc stable keywords years > > > >>> ago > > > >>> and are currently no so important. > > > >>> > > > >> Yes, please let's just do base system stable. I've been randomly > > > >> taking > > > >> care of ppc but nothing systematic. Its pretty spotty. But at the > > > >> same > > > >> time I don't like the idea of just loosing all the stabilization effort > > > >> on the base system, so that might work best. Something to think about > > > >> for mips too. > > > >> > > > >> > > > > Nice, one think we would need to discuss is what do we consider base > > > > system :/ > > > > > > > > I guess packages maintained by base-system, toolchain and... xorg-server > > > > and co... what more > > > > > > > > Not sure if we could have a list of current stable tree for ppc*, once > > > > do we have that list, ppc* teams can drop from that list what they want > > > > and we get a new list that will be the final result. What do you think > > > > about that? > > > > > > > > > > > > > > At the very least, its what's needed to build the stages with catalyst. > > > I would think we should start with base/packages, but I don't want to > > > limit it to just those because I at least need a more for building and > > > maintaining. Where should we start to compile such a list? > > > > If we are going to do this, I think we should drop these arch's > > to exp status in the profiles. That way, it keeps repoman from bothering > > the rest of us about stabilizations, and we don't have to worry about > > filing stable requests on them. > > > > That would let you stabilize things that you need to build the stages. > > > > William > > > > But, moving ppc* to exp wouldn't lead us to likely break their tree? > (because we wouldn't get any dependency issue even with "base" > packages...) > > I was thinking in this plan: - Get a list with all packages stable on ppc - Drop from that list what ppc teams want - Run on all that packages ekeyword ~ppc* - Run repoman to the full tree to fix the dependencies, use.stable.mask some, tune the list of stable packages...
Re: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
Dnia 2014-07-26, o godz. 08:05:32 Duncan <1i5t5.dun...@cox.net> napisał(a): > Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted: > > > 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. > > What about handling each such virtual_USE as a USE_EXPAND? VIRTUAL_* as > reserved-namespace USE_EXPAND would give us full backward compatibility > along with an immediately identifiable namespace and virtually (heh) no > possibility of confusion with other configuration. USE_EXPAND are global by definition. We ought fight with the abuse of USE_EXPAND rather than make another abuse legitimate. Especially that you're going to increase a lot of new variables quickly for no really good reason. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
Duncan posted on Sat, 26 Jul 2014 08:05:32 + as excerpted: > Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted: > >> 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. > > What about handling each such virtual_USE as a USE_EXPAND? > [Example] VIRTUAL_KRB5 Hmm, thinking toward implementation, what about a virtual.eclass, inherited by virtuals? It could even have a declarative interface, such that from virtual/krb5-0.ebuild (I've left out the minversion and multilib-usedep stuff here as the example above did as well, but it could be passed too)... inherit virtual VIRTUAL_EXCLUSIVE="app-crypt/mit-krb5 app-crypt/heimdal" ... would setup most of the basics for an exclusive virtual, including the VIRTUAL_KRB5 USE_EXPAND name (based on $PN), the two providers and rdepends, the fact that they're exclusive and thus a default pkg_pretend or required_use, etc. In for instance virtual/editors, this could be used in place of its current RDEPEND: VIRTUAL_MULTI=" app-editors/nano app-editors/dav app-editors/e3 ... mail-client/alpine[-onlyalpine] sys-apps/ed " With an eclass, the default pkg_pretend for exclusive-virtuals would be standardized, standardizing the error message and explanation for it as well, giving it a chance to be a bit more informative than unstandardized one-offs might tend to be. Of course the same eclass idea could be used with simple USE flags as well, but I prefer the USE_EXPANDs. -- 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
[gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
Michał Górny posted on Sat, 26 Jul 2014 10:53:21 +0200 as excerpted: > USE_EXPAND are global by definition. We ought fight with the abuse of > USE_EXPAND rather than make another abuse legitimate. Especially that > you're going to increase a lot of new variables quickly for no really > good reason. Well, USE flags are global by definition, unless set differently in package.use, as well. And if pacho's single VIRTUAL use-expand variable idea is taken, that's only one instead of the many in my proposal. -- 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] About current ppc/ppc64 status
On 07/26/14 04:44, Pacho Ramos wrote: El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió: El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió: On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote: On 07/25/14 15:50, Pacho Ramos wrote: El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió: On 07/25/14 15:28, Pacho Ramos wrote: That is the reason for me thinking that maybe the way to go would be to do the opposite -> keep only base-system and a few others stable and drop stable for most of the rest. This big effort could be accomplished in a week by other developers willing to help (like me) and would solve the issue for the long term. I guess that is what HPPA team did in the past and I think it's working pretty well for them (in summary, have a stable tree they are able to keep stable). That will also help people in ppc* teams to know that the remaining stabilization bugs, apart of being much less, are important enough to deserve rapid attention, as opposed to current situation that will have some important bugs mixed with tons of stabilization requests of apps that got ppc stable keywords years ago and are currently no so important. Yes, please let's just do base system stable. I've been randomly taking care of ppc but nothing systematic. Its pretty spotty. But at the same time I don't like the idea of just loosing all the stabilization effort on the base system, so that might work best. Something to think about for mips too. Nice, one think we would need to discuss is what do we consider base system :/ I guess packages maintained by base-system, toolchain and... xorg-server and co... what more Not sure if we could have a list of current stable tree for ppc*, once do we have that list, ppc* teams can drop from that list what they want and we get a new list that will be the final result. What do you think about that? At the very least, its what's needed to build the stages with catalyst. I would think we should start with base/packages, but I don't want to limit it to just those because I at least need a more for building and maintaining. Where should we start to compile such a list? If we are going to do this, I think we should drop these arch's to exp status in the profiles. That way, it keeps repoman from bothering the rest of us about stabilizations, and we don't have to worry about filing stable requests on them. That would let you stabilize things that you need to build the stages. William But, moving ppc* to exp wouldn't lead us to likely break their tree? (because we wouldn't get any dependency issue even with "base" packages...) I was thinking in this plan: - Get a list with all packages stable on ppc - Drop from that list what ppc teams want - Run on all that packages ekeyword ~ppc* - Run repoman to the full tree to fix the dependencies, use.stable.mask some, tune the list of stable packages... 1) I don't think we need to drop to exp if we do this right. 2) I like this plan. Its not that we'll drop the whole arch to ~ at once but trim at our discretion. Less chance of breaking everything. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] About current ppc/ppc64 status
Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos: > El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió: > > El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió: > > > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote: > > > > On 07/25/14 15:50, Pacho Ramos wrote: > > > > > El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió: > > > > >> On 07/25/14 15:28, Pacho Ramos wrote: > > > > >>> That is the reason for me thinking that maybe the way to go would > > > > >>> be to > > > > >>> do the opposite -> keep only base-system and a few others stable > > > > >>> and > > > > >>> drop stable for most of the rest. This big effort could be > > > > >>> accomplished > > > > >>> in a week by other developers willing to help (like me) and would > > > > >>> solve > > > > >>> the issue for the long term. I guess that is what HPPA team did in > > > > >>> the > > > > >>> past and I think it's working pretty well for them (in summary, > > > > >>> have a > > > > >>> stable tree they are able to keep stable). That will also help > > > > >>> people in > > > > >>> ppc* teams to know that the remaining stabilization bugs, apart of > > > > >>> being > > > > >>> much less, are important enough to deserve rapid attention, as > > > > >>> opposed > > > > >>> to current situation that will have some important bugs mixed with > > > > >>> tons > > > > >>> of stabilization requests of apps that got ppc stable keywords > > > > >>> years ago > > > > >>> and are currently no so important. > > > > >> > > > > >> Yes, please let's just do base system stable. I've been randomly > > > > >> taking > > > > >> care of ppc but nothing systematic. Its pretty spotty. But at the > > > > >> same > > > > >> time I don't like the idea of just loosing all the stabilization > > > > >> effort > > > > >> on the base system, so that might work best. Something to think > > > > >> about > > > > >> for mips too. > > > > > > > > > > Nice, one think we would need to discuss is what do we consider base > > > > > system :/ > > > > > > > > > > I guess packages maintained by base-system, toolchain and... > > > > > xorg-server > > > > > and co... what more > > > > > > > > > > Not sure if we could have a list of current stable tree for ppc*, > > > > > once > > > > > do we have that list, ppc* teams can drop from that list what they > > > > > want > > > > > and we get a new list that will be the final result. What do you > > > > > think > > > > > about that? > > > > > > > > At the very least, its what's needed to build the stages with > > > > catalyst. > > > > I would think we should start with base/packages, but I don't want to > > > > limit it to just those because I at least need a more for building and > > > > maintaining. Where should we start to compile such a list? > > > > > > If we are going to do this, I think we should drop these arch's > > > to exp status in the profiles. That way, it keeps repoman from bothering > > > the rest of us about stabilizations, and we don't have to worry about > > > filing stable requests on them. > > > > > > That would let you stabilize things that you need to build the stages. > > > > > > William > > > > But, moving ppc* to exp wouldn't lead us to likely break their tree? > > (because we wouldn't get any dependency issue even with "base" > > packages...) > > I was thinking in this plan: > - Get a list with all packages stable on ppc > - Drop from that list what ppc teams want > - Run on all that packages ekeyword ~ppc* > - Run repoman to the full tree to fix the dependencies, use.stable.mask > some, tune the list of stable packages... ++ from Gentoo kde point of view
[gentoo-dev] Re: don't rely on dynamic deps
Ian Stakenvicius wrote: > > The only need for EAPI change that I can see is to allow non-integer > revision values A change of the version/-revision format certainly requires an EAPI change; one must also define rules how to compare these versions, etc. (despite it is obvious, here). Please be aware that on the corresponding bug there is already the request to keep minor revisions for sub-distributions of gentoo; so maybe instead of minor revisions one should think about anpther suffix (besides -r...) or another format: This would simulateneously avoid the problem of $PF discussed earlier - by definition, this additional suffix would not appear in $PF.
[gentoo-dev] Re: don't rely on dynamic deps
Rich Freeman wrote: > On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth wrote: >> ...but by introducing all the additional complications Ian >> has mentioned. More precisely: What happens if new dependencies >> are introduced which are not satisfied? >> One has to face it: Portage must not just silently "update" the >> database and thus silently produce a /var/db which does not >> satisfy its own dependencies... > > While this is problematic, I think portage actually can handle this > (but I haven't tested this recently). The problem here arises if new dependencies with automatic subslots (foo/bar:=) are added which are not yet installed: Portage cannot fill these correctly. Solving all these difficulties appears harder to me than implementing dynamic deps correctly. > I think that allowing devs to instruct portage to update VDB with > USE/dep/etc changes is potentially less problematic than having > portage trying to guess what the right thing to do is. I completely agree. The idea of minor revisions is just one of several possibilities to achieve this; there are several others (e.g. another metadata variable describing which versions can be updated by skipping the prepare/config/compile/merge phases). The implementation, however, would be rather similar: Usually you need a new EAPI (or in case of noninvasive change might discuss whether to change EAPI's retroactively), and some "reemerging without the time-consuming phases" must be implemented.
Re: [gentoo-dev] About current ppc/ppc64 status
El sáb, 26-07-2014 a las 06:22 -0400, Anthony G. Basile escribió: [...] > 1) I don't think we need to drop to exp if we do this right. > > 2) I like this plan. Its not that we'll drop the whole arch to ~ at > once but trim at our discretion. Less chance of breaking everything. > Looks like we can get the full list of packages with stable versions with: EIX_LIMIT=0 eix --stable -# But I don't find how to make eix show me the output for ppc* (I have amd64 and uses that as arch)
Re: [gentoo-dev] About current ppc/ppc64 status
On 26/07/14 13:22, Anthony G. Basile wrote: > On 07/26/14 04:44, Pacho Ramos wrote: >> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió: >>> El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió: On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote: > On 07/25/14 15:50, Pacho Ramos wrote: >> El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió: >>> On 07/25/14 15:28, Pacho Ramos wrote: That is the reason for me thinking that maybe the way to go would be to do the opposite -> keep only base-system and a few others stable and drop stable for most of the rest. This big effort could be accomplished in a week by other developers willing to help (like me) and would solve the issue for the long term. I guess that is what HPPA team did in the past and I think it's working pretty well for them (in summary, have a stable tree they are able to keep stable). That will also help people in ppc* teams to know that the remaining stabilization bugs, apart of being much less, are important enough to deserve rapid attention, as opposed to current situation that will have some important bugs mixed with tons of stabilization requests of apps that got ppc stable keywords years ago and are currently no so important. >>> Yes, please let's just do base system stable. I've been >>> randomly taking >>> care of ppc but nothing systematic. Its pretty spotty. But at >>> the same >>> time I don't like the idea of just loosing all the stabilization >>> effort >>> on the base system, so that might work best. Something to think >>> about >>> for mips too. >>> >>> >> Nice, one think we would need to discuss is what do we consider base >> system :/ >> >> I guess packages maintained by base-system, toolchain and... >> xorg-server >> and co... what more >> >> Not sure if we could have a list of current stable tree for ppc*, >> once >> do we have that list, ppc* teams can drop from that list what >> they want >> and we get a new list that will be the final result. What do you >> think >> about that? >> >> > At the very least, its what's needed to build the stages with > catalyst. > I would think we should start with base/packages, but I don't want to > limit it to just those because I at least need a more for building > and > maintaining. Where should we start to compile such a list? If we are going to do this, I think we should drop these arch's to exp status in the profiles. That way, it keeps repoman from bothering the rest of us about stabilizations, and we don't have to worry about filing stable requests on them. That would let you stabilize things that you need to build the stages. William >>> But, moving ppc* to exp wouldn't lead us to likely break their tree? >>> (because we wouldn't get any dependency issue even with "base" >>> packages...) >>> >>> >> I was thinking in this plan: >> - Get a list with all packages stable on ppc >> - Drop from that list what ppc teams want >> - Run on all that packages ekeyword ~ppc* >> - Run repoman to the full tree to fix the dependencies, use.stable.mask >> some, tune the list of stable packages... >> >> >> > > 1) I don't think we need to drop to exp if we do this right. +1. Only reason 'mips' was downgraded to 'exp' because there was absolutely nobody working on it at the time. I tend to regret that now. Also, aballier is using amd64-fbsd with 'stable' and 'dev', exactly to avoid breakage, since nobody really checks for 'exp' > > 2) I like this plan. Its not that we'll drop the whole arch to ~ at > once but trim at our discretion. Less chance of breaking everything. > +1
Re: [gentoo-dev] About current ppc/ppc64 status
On 07/26/14 07:36, Pacho Ramos wrote:
El sáb, 26-07-2014 a las 06:22 -0400, Anthony G. Basile escribió:
[...]
1) I don't think we need to drop to exp if we do this right.
2) I like this plan. Its not that we'll drop the whole arch to ~ at
once but trim at our discretion. Less chance of breaking everything.
Looks like we can get the full list of packages with stable versions
with:
EIX_LIMIT=0 eix --stable -#
But I don't find how to make eix show me the output for ppc* (I have
amd64 and uses that as arch)
The following python script will list all ebuilds and their keywords.
I'm busy as all hell right now, but I can hack it up to give us what we
need. You can in the mean time play with it. It is slow because python
is slow and the tree is big.
#!/usr/bin/env python
import portage, re
portdb = portage.db[portage.root]["porttree"].dbapi
for pkg in portdb.cpv_all():
keywords = portdb.aux_get(pkg, ["KEYWORDS"])[0]
print("%s %s" % (pkg, keywords))
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
Re: [gentoo-dev] About current ppc/ppc64 status
El sáb, 26-07-2014 a las 07:47 -0400, Anthony G. Basile escribió:
> On 07/26/14 07:36, Pacho Ramos wrote:
> > El sáb, 26-07-2014 a las 06:22 -0400, Anthony G. Basile escribió:
> > [...]
> >> 1) I don't think we need to drop to exp if we do this right.
> >>
> >> 2) I like this plan. Its not that we'll drop the whole arch to ~ at
> >> once but trim at our discretion. Less chance of breaking everything.
> >>
> > Looks like we can get the full list of packages with stable versions
> > with:
> > EIX_LIMIT=0 eix --stable -#
> >
> > But I don't find how to make eix show me the output for ppc* (I have
> > amd64 and uses that as arch)
> >
> >
>
> The following python script will list all ebuilds and their keywords.
> I'm busy as all hell right now, but I can hack it up to give us what we
> need. You can in the mean time play with it. It is slow because python
> is slow and the tree is big.
>
>
> #!/usr/bin/env python
>
> import portage, re
>
> portdb = portage.db[portage.root]["porttree"].dbapi
>
> for pkg in portdb.cpv_all():
> keywords = portdb.aux_get(pkg, ["KEYWORDS"])[0]
> print("%s %s" % (pkg, keywords))
>
>
Nice. Well, eix is really fast for this... but I need to see how to make
it think I have a ppc setup ;)
I guess we will need to wait for the next Council to officially decide
to do this as it will be a big change for ppc* users :/ (I remember
their action was needed for the move to testing of some arches and the
"package-by-package" proposal for others)
Also, I am not sure if any other arch teams (sparc, ia64?) would want to
get this policy too :| (I got ppc* because this concrete case ;))
Re: [gentoo-dev] About current ppc/ppc64 status
On 07/26/2014 11:09 AM, Johannes Huber wrote: > Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos: >> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió: >>> El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió: On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote: > On 07/25/14 15:50, Pacho Ramos wrote: >> El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió: >>> On 07/25/14 15:28, Pacho Ramos wrote: That is the reason for me thinking that maybe the way to go would be to do the opposite -> keep only base-system and a few others stable and drop stable for most of the rest. This big effort could be accomplished in a week by other developers willing to help (like me) and would solve the issue for the long term. I guess that is what HPPA team did in the past and I think it's working pretty well for them (in summary, have a stable tree they are able to keep stable). That will also help people in ppc* teams to know that the remaining stabilization bugs, apart of being much less, are important enough to deserve rapid attention, as opposed to current situation that will have some important bugs mixed with tons of stabilization requests of apps that got ppc stable keywords years ago and are currently no so important. >>> >>> Yes, please let's just do base system stable. I've been randomly >>> taking >>> care of ppc but nothing systematic. Its pretty spotty. But at the >>> same >>> time I don't like the idea of just loosing all the stabilization >>> effort >>> on the base system, so that might work best. Something to think >>> about >>> for mips too. >> >> Nice, one think we would need to discuss is what do we consider base >> system :/ >> >> I guess packages maintained by base-system, toolchain and... >> xorg-server >> and co... what more >> >> Not sure if we could have a list of current stable tree for ppc*, >> once >> do we have that list, ppc* teams can drop from that list what they >> want >> and we get a new list that will be the final result. What do you >> think >> about that? > > At the very least, its what's needed to build the stages with > catalyst. > I would think we should start with base/packages, but I don't want to > limit it to just those because I at least need a more for building and > maintaining. Where should we start to compile such a list? If we are going to do this, I think we should drop these arch's to exp status in the profiles. That way, it keeps repoman from bothering the rest of us about stabilizations, and we don't have to worry about filing stable requests on them. That would let you stabilize things that you need to build the stages. William >>> >>> But, moving ppc* to exp wouldn't lead us to likely break their tree? >>> (because we wouldn't get any dependency issue even with "base" >>> packages...) >> >> I was thinking in this plan: >> - Get a list with all packages stable on ppc >> - Drop from that list what ppc teams want >> - Run on all that packages ekeyword ~ppc* >> - Run repoman to the full tree to fix the dependencies, use.stable.mask >> some, tune the list of stable packages... > > ++ from Gentoo kde point of view > +1 from ruby. How do we solve keyword requests? https://bugs.gentoo.org/show_bug.cgi?id=477648 is ~ 12 months and hasn't seen any reply from the ppc* teams. https://bugs.gentoo.org/show_bug.cgi?id=497396 ~ 6 months https://bugs.gentoo.org/show_bug.cgi?id=487206 ~ 9 months https://bugs.gentoo.org/show_bug.cgi?id=487178 ~ 9 months We can start dropping ppc* from dev-ruby/* if that eases maintenance and gives you more time for core packages? Cheers Manuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About current ppc/ppc64 status
El sáb, 26-07-2014 a las 13:57 +0200, Manuel Rüger escribió: [...] > +1 from ruby. > > How do we solve keyword requests? > https://bugs.gentoo.org/show_bug.cgi?id=477648 is ~ 12 months and hasn't > seen any reply from the ppc* teams. > https://bugs.gentoo.org/show_bug.cgi?id=497396 ~ 6 months > https://bugs.gentoo.org/show_bug.cgi?id=487206 ~ 9 months > https://bugs.gentoo.org/show_bug.cgi?id=487178 ~ 9 months > > We can start dropping ppc* from dev-ruby/* if that eases maintenance and > gives you more time for core packages? > > Cheers > Manuel > I guess once we free ppc* teams from all the load from stabilizations they will likely fix much sooner keyword requests. What I would do is to fix the stabilizations first and, if still unable to handle keyword requests, try to resolve that one :)
[gentoo-dev] Re: don't rely on dynamic deps
Tom Wijsman wrote: > > Useless triggers are the problem; why are the rev bumps needed, why are > dependencies forgotten, ...? It is not only about *forgotten* dependencies: It is whenever something is restructured, a new project appears, etc. Some examples: 1. Package foo/bar splits into foo/bar-base and foo/bar-gui. Should all the packages depending on foo/bar be recompiled, just because the dependency must be relaxed? 2. Package foo/bar-base and foo/bar-gui merge to foo/bar. In this case the dependency needs to be strengthened, but technically a recompile should not be necessary (perhaps there are exceptions where it is necessary for newer versions, but these should be rare; in any case, the developer should know what is "correct"). 3. Package foo/bar was forked to foo/baz, both providing the same ABI. Maybe a new virtual is introduced in gentoo, or maybe the alternative dependency should be directly added in all ebuilds. Absolutely no reason to force a rebuild, but with static dependencies and without a bump, the user is not able to change to the new foo/baz. 4. Package foo/bar was forked to foo/baz, both providing the same API but not the same ABI. This is a problematic situation, but it is so with and without dynamic/static dependencies: Even if a user once reemerges a package depending on it, he may nevertheless later replace foo/bar by foo/baz and gets a broken system despite all dependencies are satisfied all of the time. Actually, 4. is an example why subslotting can *never* fully replace revdep-rebuild. Although 4. touches also a different problem, actually the triggering of a rebuild in case 4., just because a new alternative is available, is completely useless. (*If* one wants to fix 4., one must introduce an extended dependency syntax, and this would have problems with virtuals etc.) Probably there are many more examples than 1.-4, but I hope that the point becomes clear: Whenever packages split, merge, or can substitute each other, dependency changes are necessary, and rebuilds caused by these are unnecessary. Unfortunately, such things happen *very* frequently... Nobody is to blame for this; the PM just should be ready to deal with such situations without unnecessary rebuilds, be it by dynamic deps or by a mechanism to avoid recompilation.
Re: [gentoo-dev] don't rely on dynamic deps
> On Wed, 23 Jul 2014, Tom Wijsman wrote: > Using an extension like -rX.Y seems odd; at the very least, I think > an incremental variable or something along that line in the ebuild > would work better. It would also account for changes in eclasses, which any scheme bound to the ebuild's filename cannot do. > This allows for array usage like VERSION[dependencies]=1, thus > allowing other variables to be dynamic as well; you compare that > number against the one in the vdb, bingo... Taking this one step further, I wonder if one couldn't directly compare *DEPEND in the ebuild against the one in the VDB. Why would one need to introduce another variable? Ulrich pgp5oc8HAFva1.pgp Description: PGP signature
Re: [gentoo-dev] About current ppc/ppc64 status
On 07/26/14 07:59, Pacho Ramos wrote: El sáb, 26-07-2014 a las 13:57 +0200, Manuel Rüger escribió: [...] +1 from ruby. How do we solve keyword requests? https://bugs.gentoo.org/show_bug.cgi?id=477648 is ~ 12 months and hasn't seen any reply from the ppc* teams. https://bugs.gentoo.org/show_bug.cgi?id=497396 ~ 6 months https://bugs.gentoo.org/show_bug.cgi?id=487206 ~ 9 months https://bugs.gentoo.org/show_bug.cgi?id=487178 ~ 9 months We can start dropping ppc* from dev-ruby/* if that eases maintenance and gives you more time for core packages? Cheers Manuel I guess once we free ppc* teams from all the load from stabilizations they will likely fix much sooner keyword requests. What I would do is to fix the stabilizations first and, if still unable to handle keyword requests, try to resolve that one :) Yes, I've said somewhere on this list that I'm willing to help stabilizatoin on ppc/ppc64 but only for core packages. Again because I do create ppc stages3 for uclibc and soon musl and its a pain to have to do what I do for mips. Let's do this right and make it the model for all minor arches. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Re: don't rely on dynamic deps
Tom Wijsman wrote: > > Assuming dynamic dependencies don't exist, another package would still > depend on the USE flag in the vdb; the only way to force that USE flag > dependency to go away is with an unnecessarily rebuilding rev bump, as > without it it would complain that the USE flag doesn't exist. Yes, this is a typical example: After every adding or removing of a python version (I am not speaking about *installed* versions) with the new policy every package depending on some python needs to be bumped. This demonstrates very well what I said: With the new policy you would have to recompile your whole system about once a week. I rather prefer to have a system which perhaps very rarely forces me to use revdep-rebuild (which cannot be omitted anyway, as shown in my previous posting) than to have a permanently outdated system, without having any possibility to know what *really* needs to be updated or is only update because of the broken "static deps" idea.
Re: [gentoo-dev] About current ppc/ppc64 status
On Sat, Jul 26, 2014 at 7:56 AM, Pacho Ramos wrote: > > I guess we will need to wait for the next Council to officially decide > to do this as it will be a big change for ppc* users :/ (I remember > their action was needed for the move to testing of some arches and the > "package-by-package" proposal for others) > Honestly, it is best if the arch teams take the initiative on these sorts of things. They're in the best place to figure out what their users' needs are. The Council tends to get involved when the issue escalates to the point where it becomes a burden on maintainers. It is always better for the arch teams to manage their own problems. So, by all means put it on the Council agenda, but I'd strongly encourage the ppc arch team to weigh in with their opinion - if we can form a consensus on the list you don't even need the Council to vote. Not that we mind - it is just better to solve things collaboratively. Rich
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > > User installs foo-1.1-r1 > Developer makes foo-1.1-r1.1 > foo-1.1* is removed from the tree > User syncs How is this different from your suggestion (which you *claim* to be non-broken): User installs foo-1.1-r1 Developer makes foo-1.1-r2 foo-1.1* is removed from the tree User syncs In fact, the result is completely the same, no matter whether you have minor revisions or not, and no matter whether you have static or dynamic deps. What is *actually* broken here is that the user has installed a package which is not maintained anymore: *This* is what needs to be fixed. This issue is completely independent of static vs. dynamic deps. You misuse this problem as a strawman, only.
[gentoo-dev] Re: don't rely on dynamic deps
hasufell 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. What is broken is that portage does not use them consistently. It would be a rather bad idea to change policy just because of this portage bug and force users to permanently do unnecessary recompilations. At least, for me, it would mean that I have to change distribution, since I cannot afford this. > optional and not defined in PMS. Static deps are also optional and not defined in PMS. In fact, PMS makes no claim *where* to read the DEP strings from; it only specified how they are to be stored in the tree. Quite the opposite, PMS claims that one cannot rely on anything stored in /var/db
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 12:32:20 + (UTC) Martin Vaeth wrote: > Ciaran McCreesh wrote: > > User installs foo-1.1-r1 > > Developer makes foo-1.1-r1.1 > > foo-1.1* is removed from the tree > > User syncs > > How is this different from your suggestion > (which you *claim* to be non-broken): > > User installs foo-1.1-r1 > Developer makes foo-1.1-r2 > foo-1.1* is removed from the tree > User syncs > > In fact, the result is completely the same, > no matter whether you have minor revisions or not, > and no matter whether you have static or dynamic deps. > > What is *actually* broken here is that the user > has installed a package which is not maintained > anymore: *This* is what needs to be fixed. > This issue is completely independent of static > vs. dynamic deps. > You misuse this problem as a strawman, only. Uhm. That works just fine... I don't think you understand how this works: we can always use the metadata that's in VDB for dealing with the installed package. The issue is that sometimes Portage tries to guess that it's better to use the metadata from an ebuild instead of what's in VDB when dealing with an installed package. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
On Sat, 26 Jul 2014 10:53:21 +0200 Michał Górny wrote: > USE_EXPAND are global by definition. Naah. They're global by a Portage configuration file limitation. In the old days, USE flags were global too... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 12:41:16 + (UTC) Martin Vaeth wrote: > hasufell 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. > What is broken is that portage does not use them consistently. Because using them consistently is impossible by design. > It would be a rather bad idea to change policy just because of this > portage bug and force users to permanently do unnecessary > recompilations. At least, for me, it would mean that I have > to change distribution, since I cannot afford this. This is not a Portage bug. > > optional and not defined in PMS. > > Static deps are also optional and not defined in PMS. > > In fact, PMS makes no claim *where* to read the DEP strings from; > it only specified how they are to be stored in the tree. Incorrect. > Quite the opposite, PMS claims that one cannot rely on > anything stored in /var/db Incorrect. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Maxim Kammerer wrote: > On Tue, Jul 22, 2014 at 12:25 AM, Michał Górny wrote: >> The funny thing is, almost none of the Gentoo developers even know that >> slot operators disable dynamic dependencies completely in portage. > > So *that's* why I now have to change RDEPENDs in both the source > ebuild and in VDB in order to augment package's dependencies before > depclean... Yes, static deps are a completely broken idea if not every change causes a revbump: There does not exist something like a "minor" change in dependencies.
Re: [gentoo-dev] About current ppc/ppc64 status
Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos: > > But, moving ppc* to exp wouldn't lead us to likely break their tree? > > (because we wouldn't get any dependency issue even with "base" > > packages...) > > I was thinking in this plan: > - Get a list with all packages stable on ppc > - Drop from that list what ppc teams want > - Run on all that packages ekeyword ~ppc* > - Run repoman to the full tree to fix the dependencies, use.stable.mask > some, tune the list of stable packages... Much better. Moving the profile to exp is only a last resort. If you can reasonably keep a smaller stable set consistent, do it! -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > Jeroen Roovers wrote: >> On Mon, 21 Jul 2014 23:06:07 +0200 >> Pacho Ramos wrote: >> > Maybe this could be solved by having two kinds of revisions: >> > - One would rebuild all as usually (for example, -r1...) >> > - The other one would only regenerate VDB and wouldn't change the >> > installed files (for example, -r1.1) >> Or the package manager looks at changed in *DEPEND between the repo >> and vdb and resolves those. > > ...assuming that the ebuild hasn't been removed, and that it can be > associated correctly when overlays are involved, and that the change > wasn't a change where a saved pkg_prerm uses the old dependency, not > the new one, or all the other ways this breaks. > > You need to think your cunning plan the whole way through. It works, since it is completely equivalent to a revbump, only that the unnecesary recompilation is avoided: All of your problems exist (or don't exist) for usual revbumps as well.
[gentoo-dev] Re: don't rely on dynamic deps
> On Sat, 26 Jul 2014, Martin Vaeth wrote: > Quite the opposite, PMS claims that one cannot rely on > anything stored in /var/db Where does it say so? Ulrich pgpF949UyfMJV.pgp Description: PGP signature
Re: [gentoo-dev] About current ppc/ppc64 status
Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: > I guess we will need to wait for the next Council to officially decide > to do this as it will be a big change for ppc* users :/ (I remember > their action was needed for the move to testing of some arches and the > "package-by-package" proposal for others) > > Also, I am not sure if any other arch teams (sparc, ia64?) would want to > get this policy too :| (I got ppc* because this concrete case ;)) At first this is an arch team decision. No need for the council. (Given that in this case there is a responsive and addressable arch team...) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 12:54:08 + (UTC) Martin Vaeth wrote: > Ciaran McCreesh wrote: > > Jeroen Roovers wrote: > >> On Mon, 21 Jul 2014 23:06:07 +0200 > >> Pacho Ramos wrote: > >> > Maybe this could be solved by having two kinds of revisions: > >> > - One would rebuild all as usually (for example, -r1...) > >> > - The other one would only regenerate VDB and wouldn't change the > >> > installed files (for example, -r1.1) > >> Or the package manager looks at changed in *DEPEND between the repo > >> and vdb and resolves those. > > > > ...assuming that the ebuild hasn't been removed, and that it can be > > associated correctly when overlays are involved, and that the change > > wasn't a change where a saved pkg_prerm uses the old dependency, not > > the new one, or all the other ways this breaks. > > > > You need to think your cunning plan the whole way through. > > It works, since it is completely equivalent to a revbump, > only that the unnecesary recompilation is avoided: > All of your problems exist (or don't exist) for usual revbumps > as well. At this point, I think it would be most helpful towards us reaching a conclusion if you agreed to refrain from commenting further until you've understood the problem at hand. You see, the rest of us are using "broken" to mean "broken" in a technical sense, based upon our understanding of how ebuilds, the VDB and metadata work. You seem to be using it to mean "does something you superficially or ideologically don't like". This is a technical discussion, and you need to read up on how things work before you can make a meaningful contribution. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > Ian Stakenvicius wrote: >> The thing about -rX.Y is that it allows this new-dynamic-deps thing >> to act like a regular rev bump to any PM that doesn't bother to >> implement it (or dynamic deps for that matter). Instant >> backwards-compatibility is a handy feature. > > ...but it doesn't actually solve the problem. Neither do revbumps. Both, dynamic and static deps are broken. They are broken in different ways, but both are broken. So the only reason which might justify changing the policy is that current portage *implementation* of dynamic deps is broken. However, if it should actually be decided to have some hundreds reemerges every week, at least this should be implemented in a way that it is not so time-consuming.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 13:00:31 + (UTC) Martin Vaeth wrote: > Both, dynamic and static deps are broken. > They are broken in different ways, but both are broken. You keep using that word. I do not think it means what you think it means. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: >> User installs foo-1.1-r1 >> Developer makes foo-1.1-r2 >> foo-1.1* is removed from the tree >> User syncs >> >> In fact, the result is completely the same You completely ignored this essential point: The result is completely the same, and you are just arguing with a strawman. But, OK, so I will use your strawman to prove how static deps are broken: >> What is *actually* broken here is that the user >> has installed a package which is not maintained >> anymore: *This* is what needs to be fixed. > > Uhm. That works just fine... Not at all: 1. Some package depending on foo/bar is removed, but the user keeps it, since deps are stored in /var/db. 2. foo/bar is split into foo/bar-A foo/bar-B for whatever reasons. Of course, all maintained ebuilds fix the dependency, and let us assume they are even revbumped. 3. The orphaned package of course still depends on installed foo/bar, causing all sort of blockers. 4. The user has no way for fixing the issue than in modifying /var/db manually. He cannot even put an ebuild into his overlay and only modify this ebuild and the metadata, because the PM dumbly insists on using only the (broken and outdated since ages) information in /var/db > I don't think you understand how this works: Quite the opposite: I see that it fixes many issues. It has also some issues with orphaned packages, but *every* approach will have issues with orphaned packages.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 13:16:13 + (UTC) Martin Vaeth wrote: > But, OK, so I will use your strawman to prove > how static deps are broken: This is not broken. This is exactly what is supposed to happen, and it is exactly what *does* happen some of the time with dynamic dependencies too. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Rich Freeman wrote: >> >> User installs foo-1.1-r1 >> Developer makes foo-1.1-r1.1 >> foo-1.1* is removed from the tree >> User syncs > > An updates-like mechanism would help here, since the updates could > persist longer. Unfortunately, this is not an option: I assure you that you do not want to keep the updates in dependencies forever; their number is simply too large. This would mean the portage tree will keep growing in an insane manner: It "almost" means to force every user to keep the *full* CVS (or in future maybe git) repository.
Re: [gentoo-dev] About current ppc/ppc64 status
El sáb, 26-07-2014 a las 08:23 -0400, Rich Freeman escribió: > On Sat, Jul 26, 2014 at 7:56 AM, Pacho Ramos wrote: > > > > I guess we will need to wait for the next Council to officially decide > > to do this as it will be a big change for ppc* users :/ (I remember > > their action was needed for the move to testing of some arches and the > > "package-by-package" proposal for others) > > > > Honestly, it is best if the arch teams take the initiative on these > sorts of things. They're in the best place to figure out what their > users' needs are. > > The Council tends to get involved when the issue escalates to the > point where it becomes a burden on maintainers. It is always better > for the arch teams to manage their own problems. > > So, by all means put it on the Council agenda, but I'd strongly > encourage the ppc arch team to weigh in with their opinion - if we can > form a consensus on the list you don't even need the Council to vote. > Not that we mind - it is just better to solve things collaboratively. > > Rich > Sure, at least for ppc teams I guess we could get it discussed by the Council as blueness is in ppc teams per: https://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap89 Not sure about the other team members :/, I also see no one listed as lead: https://www.gentoo.org/proj/en/base/ppc/ For the other arch teams I guess I can start a new thread for them (in summary, pointing them to this thread for the idea but suggesting them to create the lists of packages to keep stable as they prefer). You are probably not seeing so much escalation because we end up relying on ago and zlogene to fix that... but that is not a long term solution. I am mostly thinking on ia64 and sparc. Alpha looks to have recently fixed lots of bugs (by klausman I think) and I am unsure about ARM as I guess his problem is different (it's due they needing to test on many different machines to get things stabilized, and that probably needs a different discussion before :/)
Re: [gentoo-dev] About current ppc/ppc64 status
El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: > Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: > > > I guess we will need to wait for the next Council to officially decide > > to do this as it will be a big change for ppc* users :/ (I remember > > their action was needed for the move to testing of some arches and the > > "package-by-package" proposal for others) > > > > Also, I am not sure if any other arch teams (sparc, ia64?) would want to > > get this policy too :| (I got ppc* because this concrete case ;)) > > At first this is an arch team decision. No need for the council. > > (Given that in this case there is a responsive and addressable arch team...) > > -- > > Andreas K. Huettel > Gentoo Linux developer > dilfri...@gentoo.org > http://www.akhuettel.de/ > The problem is that blueness looks to be the only member currently replying :/, I have checked their page and I see no team lead or similar. Then, I am not sure how to get the ok to proceed or not :| (to prevent this from getting stalled and we keep trying stabilizing all the things). I remember from older thread (one related with udev stabilization), that blueness was also the only one replying.
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > > Wrong. The reason everything is such a mess at the moment is precisely > because we've accumulated so much "good enough" and "not thinking your > cunning plan all the way through" There *is* no perfect solution. And the reason why everything is such a mess at the moment is that portage's implementation of subslot dependencies was broken (because it used a mechanism which has broken dynamic deps). *This* is what needs to be fixed but which is perhaps not easy to fix. However, changing the policy in a manner causing so many unnecessary ebuilds (and fixing not all problems either) is throwing the baby out with the bathwater. When having the choice between only non-perfect solutions, I vote for the one which keeps the distribution usable.
Re: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/07/14 04:05 AM, Duncan wrote: > Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as > excerpted: > >> 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. > > What about handling each such virtual_USE as a USE_EXPAND? > VIRTUAL_* as reserved-namespace USE_EXPAND would give us full > backward compatibility along with an immediately identifiable > namespace and virtually (heh) no possibility of confusion with > other configuration. > > Continuing with the earlier virtual/krb5 example, we'd have > VIRTUAL_KRB5, with possible settings in make.conf of: > > VIRTUAL_KRB5=mit-krb5 VIRTUAL_KRB5=heimdal > > Virtually no possibility of confusion with normal USE flags, and > the matching virtual would be immediately identifiable, so no > possibility of getting confused on what it applies to, either. > *shrug*, sure.. effectively we just start using IUSE="virtual_krb5_mit-krb5" instead of "mit-krb5" but yes this would work too. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPTrbUACgkQ2ugaI38ACPAbcAD/VapV0WR+Z7aWcyHeehHzoHSw Qi8o+EDkQpakD3bVVtAA/0WSTPsPmVWHq3Fn0iITXbprHsKWMV+mXPN23nbpUdzf =aE4s -END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
El sáb, 26-07-2014 a las 12:00 +, Martin Vaeth escribió: [...] > Probably there are many more examples than 1.-4, but I hope > that the point becomes clear: Whenever packages split, merge, > or can substitute each other, dependency changes are necessary, > and rebuilds caused by these are unnecessary. > > Unfortunately, such things happen *very* frequently... > > Nobody is to blame for this; the PM just should be ready > to deal with such situations without unnecessary rebuilds, > be it by dynamic deps or by a mechanism to avoid > recompilation. > I have also seen the need of add slots to DEPEND/RDEPEND due the inclusion of an updated package like gstreamer:1.0/gtk+:3/libpng... or needing to add forgotten USE deps (like package[introspection?] or package[X]).
[gentoo-dev] Re: don't rely on dynamic deps
Pacho Ramos wrote: > > Isn't there a way for PMs to know that they need to not rebuild full if > user has 1.1-r1 *installed* in his system and pretends to update to > -r1.1? This is exactly the idea of -r1.1, and this (at least the check) already works in the code snippet I had sent to the portage list: >From 1.1-r1 to 1.1-r1.1 no recompilation should happen, while e.g. from 1.1 to 1.1-r1.1 the bump is as usual. Package managers which do not want to implement minor revisions could just treat -r1.1 as a "usual" revbump and recompile unconditionally, that is, except for a slight extension of the allowed versions (and corresponding comparison rules) nothing would change for them (although their users would then not benefit from the possible avoidance of some recompilations offered perhaps by other package managers).
Re: [gentoo-dev] About current ppc/ppc64 status
On 07/26/14 09:28, Pacho Ramos wrote: El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: I guess we will need to wait for the next Council to officially decide to do this as it will be a big change for ppc* users :/ (I remember their action was needed for the move to testing of some arches and the "package-by-package" proposal for others) Also, I am not sure if any other arch teams (sparc, ia64?) would want to get this policy too :| (I got ppc* because this concrete case ;)) At first this is an arch team decision. No need for the council. (Given that in this case there is a responsive and addressable arch team...) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ The problem is that blueness looks to be the only member currently replying :/, I have checked their page and I see no team lead or similar. Then, I am not sure how to get the ok to proceed or not :| (to prevent this from getting stalled and we keep trying stabilizing all the things). I remember from older thread (one related with udev stabilization), that blueness was also the only one replying. Yeah, not having a clear lead is a problem. No one wants to just make a big decision on behalf of the team without making sure everyone is on board. Pacho, do you have access to timberdoodle? If so, join both teams and just take the initiative and let any other "claimants" step forward now. BTW, taking the lead doesn't mean doing all the work yourself. I want to see ppc/ppc64 in good shape. I'll be happy to write scripts to do the demoting to ~ etc etc. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Call for help: app-admin/chef
Hello, app-admin/chef and its related packages are currently maintainer-needed. So if you're using chef on Gentoo, this is your chance to step up! These packages have some restricting dependencies (e.g. https://bugs.gentoo.org/buglist.cgi?quicksearch=app-admin%2Fchef&list_id=2433248 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: don't rely on dynamic deps
Michał Górny wrote: >> Maybe this could be solved by having two kinds of revisions: >> - One would rebuild all as usually (for example, -r1...) >> - The other one would only regenerate VDB and wouldn't change the >> installed files (for example, -r1.1) > > I'm afraid it couldn't. The major problem is not knowing *when* to > migrate metadata, portage usually gets that right. The problem is in > getting the correct output which is often near to impossible. Could you explain where you see here a problem with -r1.1 which is not caused as well with -r2? The only difference should be that when revbumping -r1 to -r1.1 there is actually no recompilation done (and perhaps the PF and PR variables are treated differently) - everything else should be exactly the same as for current revbumps. And once more, this is only one of the several possibilities how to tell portage that actually no compilation is necessary: Some other metadata/variable/whatever might be used as well. The idea is to act "as usual", just to skip unnecessary phases...
Re: [gentoo-dev] About current ppc/ppc64 status
El sáb, 26-07-2014 a las 09:37 -0400, Anthony G. Basile escribió: > On 07/26/14 09:28, Pacho Ramos wrote: > > El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: > >> Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: > >> > >>> I guess we will need to wait for the next Council to officially decide > >>> to do this as it will be a big change for ppc* users :/ (I remember > >>> their action was needed for the move to testing of some arches and the > >>> "package-by-package" proposal for others) > >>> > >>> Also, I am not sure if any other arch teams (sparc, ia64?) would want to > >>> get this policy too :| (I got ppc* because this concrete case ;)) > >> At first this is an arch team decision. No need for the council. > >> > >> (Given that in this case there is a responsive and addressable arch > >> team...) > >> > >> -- > >> > >> Andreas K. Huettel > >> Gentoo Linux developer > >> dilfri...@gentoo.org > >> http://www.akhuettel.de/ > >> > > The problem is that blueness looks to be the only member currently > > replying :/, I have checked their page and I see no team lead or > > similar. Then, I am not sure how to get the ok to proceed or not :| (to > > prevent this from getting stalled and we keep trying stabilizing all the > > things). > > > > I remember from older thread (one related with udev stabilization), that > > blueness was also the only one replying. > > > > > > Yeah, not having a clear lead is a problem. No one wants to just make a > big decision on behalf of the team without making sure everyone is on > board. Pacho, do you have access to timberdoodle? If so, join both > teams and just take the initiative and let any other "claimants" step > forward now. BTW, taking the lead doesn't mean doing all the work > yourself. I want to see ppc/ppc64 in good shape. I'll be happy to > write scripts to do the demoting to ~ etc etc. > I don't even know about timberdoodle :( I forwarded the mail to both alias (as I forgot first time), then, hopefully they will review it :/ Will CC them again to this just now with this link to allow all to read the full thread: http://comments.gmane.org/gmane.linux.gentoo.devel/92151
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 13:41:34 + (UTC) Martin Vaeth wrote: > The idea is to act "as usual", just to skip unnecessary phases... So someone adds optional selinux support to a package, and then you end up with selinux being "on", despite not having it, and then another package depends upon your package with [selinux], and the dependency is mistakenly treated as met... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] binpkg (was: don't rely on dynamic deps)
Patrick Lauer wrote: > > Without binpkg support I'd feel the need to hack it up, just to get things > fast enough. binpkg support has some severe problems currently, anyway. I already described it in the bug, but since perhaps the description was not clear, I repeat it here: I regularly build binpackages for some client. This client is updated only very infrequently (once every few months). Of course, before I emerge the binpkgs, I update the portage tree on that client, and also copy my /etc/portage/package* directories. Then it turns out that I can use *less* than half of my binpkgs on the client: The binpkgs are just ignored. One reason I found: I had temporarily set ~ARCH for some package in /etc/portage/package.accept_keywords when building the package, and removed the entry again (and thus also on the client) once the package has become stable. I hope that you agree that my expectation is sane that the binpkg should be used anyway - but it isn't. For others I do not know the reason, but probably it is very similar that some variables/settings at the time of building the package were different from the current ones in the tree. So, I do not know all the details, but currently binpkg support is somewhat broken already. What we would need is *more* pushing of information of the current tree data to binpkgs, not *less*. So dynamic deps (or another update mechanism) appear to be a first step in *fixing* support for binpkgs...
[gentoo-dev] Re: don't rely on dynamic deps
Alexandre Rostovtsev wrote: > > rdepends-add is easy to implement [...] Deletion is trickier [...] > > The point is to *not* clean up these entries for months/years. So, essentially, you want the developer to do part of CVS/git's job, namely keeping a history of changes in a compressed format, keeping the history forever (or almost forever). As mentioned in another post, you highly understimate the amount of data which would have to be treated this way: For every python release and many other eclass changes, almost all packages in the tree are involved, usually several times a months.
[gentoo-dev] Re: don't rely on dynamic deps
Alexander Berntsen wrote: > > 1. Improve dynamic-deps. This is, as Michał pointed out earlier in > this thread a pipe dream. Not necessarily. Just somebody with enough knowledge in portage and python has to fix it. The problem is that in gentoo there seems to be currently nobody with these skills and free time... > PMS defines a static dependency model No. PMS does not specify which dependency information has to be taken. IIRC it does not even specify that dependency information has to be stored in /var/db at all.
[gentoo-dev] Re: don't rely on dynamic deps
Kent Fredric wrote: > > So we'll probably need a repoman check that is smart enough to know "X is > modified" and compare the DEPEND fields with the previous incarnation prior > to commit, and then at very least, warn people doing `repoman full` that > they've modified the dependencies, and that a -r1 bump is thus highly > recommended. Do not forget modification of eclasses which then require mass bumps!
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 14:09:44 + (UTC) Martin Vaeth wrote: > > PMS defines a static dependency model > > No. PMS does not specify which dependency information has > to be taken. Yes it does. Please read PMS, and do not guess as to what it says. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Tom Wijsman wrote: > Michael Palimaka wrote: > >> What a great way to kill the distro. >> >> I can already heat my house with the number of unnecessary rebuilds > > Do you upgrade @world every hour and thus have it cause excessive heat? > > If I upgrade every X weeks they become much more cool and necessary... One of the main advantages of gentoo is the flowing upgrade, especially since this can only be very poorly emulated by a binary distro. If you really suggest that the user waits one month and then recompiles the whole installation, you give up this advantage of gentoo: The user is not up-to-date for a long time, and moreover, then needs practically a full reinstall; both are things which he wants to avoid and why perhaps he has chosen gentoo in the first place. At least, for me it is the case: if I have to reinstall all packages every months - and even have delay in security updates for a month - I will certainly switch the distribution. I guess many others think similarly.
Re: [gentoo-dev] Re: don't rely on dynamic deps
Dnia 2014-07-26, o godz. 14:02:29 Martin Vaeth napisał(a): > Alexandre Rostovtsev wrote: > > > > rdepends-add is easy to implement [...] Deletion is trickier [...] > > > > The point is to *not* clean up these entries for months/years. > > So, essentially, you want the developer to do part of CVS/git's job, > namely keeping a history of changes in a compressed format, > keeping the history forever (or almost forever). > As mentioned in another post, you highly understimate the > amount of data which would have to be treated this way: > For every python release and many other eclass changes, > almost all packages in the tree are involved, usually > several times a months. Python is irrelevant here. Our dependencies are USE-conditional, so dependencies are added and removed along with USE flags. If we add new implementation, you need to rebuild the package anyway to use it, and there is no point populating extra dependencies. Revbump isn't necessary either since --changed-use will pick it up if necessary. If we remove an implementation, PM isn't supposed to remove the dependencies until the package is rebuilt with flag disabled. If it was enabled, --changed-use is supposed to clean it up. If it was not, the extra dependencies do not matter (and are not even stored in vdb). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
Dnia 2014-07-26, o godz. 14:09:44 Martin Vaeth napisał(a): > Alexander Berntsen wrote: > > > > 1. Improve dynamic-deps. This is, as Michał pointed out earlier in > > this thread a pipe dream. > > Not necessarily. Just somebody with enough knowledge in > portage and python has to fix it. > The problem is that in gentoo there seems to be currently > nobody with these skills and free time... All people with enough knowledge already know that this is technically impossible. This is not theoretical physics, ignoring the impossible won't breed anything here. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: >> No. PMS does not specify which dependency information has >> to be taken. > > Yes it does. Please read PMS, and do not guess as to what it says. Looking for /var/db/pkg gave exactly one hit: The assertion that this is *not* part of PMS. The section on dependencies is only about the ebuild format. So either it is very hidden or not in there.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 14:33:38 + (UTC) Martin Vaeth wrote: > Ciaran McCreesh wrote: > >> No. PMS does not specify which dependency information has > >> to be taken. > > > > Yes it does. Please read PMS, and do not guess as to what it says. > > Looking for /var/db/pkg gave exactly one hit: > The assertion that this is *not* part of PMS. > > The section on dependencies is only about the ebuild format. > > So either it is very hidden or not in there. I said read PMS, not grep PMS. You're making all kinds of wild claims based upon what you guess PMS says, not what it actually says. -- Ciaran McCreesh signature.asc 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] Re: don't rely on dynamic deps
Ciaran McCreesh: > On Sat, 26 Jul 2014 14:33:38 + (UTC) > Martin Vaeth wrote: >> Ciaran McCreesh wrote: No. PMS does not specify which dependency information has to be taken. >>> >>> Yes it does. Please read PMS, and do not guess as to what it says. >> >> Looking for /var/db/pkg gave exactly one hit: >> The assertion that this is *not* part of PMS. >> >> The section on dependencies is only about the ebuild format. >> >> So either it is very hidden or not in there. > > I said read PMS, not grep PMS. You're making all kinds of wild claims > based upon what you guess PMS says, not what it actually says. > This looks like a private lesson in PMS reading. Can you guys do that on IRC?
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: >> But, OK, so I will use your strawman to prove >> how static deps are broken: > > This is not broken. This is exactly what is supposed to happen "It's not a bug it's a feature" Of course, one can always close the eyes when faced with problems. > and it > is exactly what *does* happen some of the time with dynamic > dependencies too. Yes, both concepts have problems. Since neither solution is perfect, why choose the one with unnecessary rebuilds?
Re: [gentoo-dev] Re: don't rely on dynamic deps
Martin Vaeth: > Ciaran McCreesh wrote: >>> But, OK, so I will use your strawman to prove >>> how static deps are broken: >> >> This is not broken. This is exactly what is supposed to happen > > "It's not a bug it's a feature" > Of course, one can always close the eyes when faced > with problems. > >> and it >> is exactly what *does* happen some of the time with dynamic >> dependencies too. > > Yes, both concepts have problems. > Since neither solution is perfect, why choose the one > with unnecessary rebuilds? > > You are not contributing anything useful to the thread currently. Read the whole thread. Read up on dynamic deps. Read up on PMS.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 14:46:42 + (UTC) Martin Vaeth wrote: > Yes, both concepts have problems. The problems are of a different kind. Static dependencies don't do something that you want them to do. Dynamic dependencies are outright broken. > Since neither solution is perfect, why choose the one > with unnecessary rebuilds? We are picking the *correct* solution, not the one that sometimes hides an occasional inconvenience (but unreliably) at the expense of being utterly broken. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > > At this point, I think it would be most helpful towards us reaching a > conclusion if you agreed to refrain from commenting further until > you've understood the problem at hand. In other words: After I disproved all your wrong arguments, you try repeatedly to ignore my technical points and instead prefer to attack me personally of not understanding what I am saying. Fortunately, this is a developer's mailing list which will not get fooled by your strategy. > You see, the rest of us are using "broken" to mean "broken" in a > technical sense, based upon our understanding of how ebuilds, the VDB > and metadata work. It seems by "the rest of use" you mean me: That's why I pointed out repeatedly *what* is broken and why (namely the concept of having orphaned packages, and I wlil not repeat the example). > You seem to be using it to mean "does something you > superficially or ideologically don't like". You seem to be using it this way: That's what you call dynamic deps broken but static not, although both face the same problems. > This is a technical discussion Exactly. So instead of writing such pointless personal attacks, you should give technical arguments.
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > Martin Vaeth wrote: >> hasufell 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. Could you please stop your childish behaviour? >> What is broken is that portage does not use them consistently. > > Because using them consistently is impossible by design. It seems that *you* should take some reading before you continue with discussion.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 14:57:20 + (UTC) Martin Vaeth wrote: > > This is a technical discussion > > Exactly. So instead of writing such pointless personal attacks, > you should give technical arguments. The technical reasons that dynamic dependencies can never work have already been explained. However, you continue to ignore them, and you continue to refuse to read what PMS actually says on the matter. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > Martin Vaeth wrote: >> The idea is to act "as usual", just to skip unnecessary phases... > > So someone adds optional selinux support to a package, and then you end > up with selinux being "on", despite not having it, and then another > package depends upon your package with [selinux], and the dependency is > mistakenly treated as met... If the developer has added IUSE=selinux and bumps from -r1 to -r1.1, he has of course verified that this USE-change does not require recompilation either way, since otherwise he would not have been allowed to explicitly say the package manager that recompilation is unnecessary. So the dependency is *correctly* treated as met.
Re: [gentoo-dev] Re: don't rely on dynamic deps
Dnia 2014-07-26, o godz. 15:01:46 Martin Vaeth napisał(a): > Ciaran McCreesh wrote: > > Martin Vaeth wrote: > >> The idea is to act "as usual", just to skip unnecessary phases... > > > > So someone adds optional selinux support to a package, and then you end > > up with selinux being "on", despite not having it, and then another > > package depends upon your package with [selinux], and the dependency is > > mistakenly treated as met... > > If the developer has added IUSE=selinux and bumps from -r1 to -r1.1, > he has of course verified that this USE-change does not require > recompilation either way, since otherwise he would not have been > allowed to explicitly say the package manager that recompilation > is unnecessary. > So the dependency is *correctly* treated as met. Excuse me but are we talking about updating *DEPEND or IUSE? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
Martin Vaeth: > Ciaran McCreesh wrote: >> Martin Vaeth wrote: >>> hasufell 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. > > Could you please stop your childish behaviour? > >>> What is broken is that portage does not use them consistently. >> >> Because using them consistently is impossible by design. > > It seems that *you* should take some reading before you > continue with discussion. > > I think no one cares about this part of the thread anymore. Can you take it elsewhere?
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > Martin Vaeth wrote: > > The problems are of a different kind. Static dependencies don't do > something that you want them to do. Dynamic dependencies are outright > broken. Please, stop your childish behaviour. You prove nothing be repeating claims which had just been disproved.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 15:04:31 + (UTC) Martin Vaeth wrote: > It seems that *you* should take some reading before you > continue with discussion. I wrote PMS, the dev manual and a package manager... I understand the issues involved. If you want to contribute, you should at least read the spec. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Michał Górny wrote: > >> Ciaran McCreesh wrote: >> > Martin Vaeth wrote: >> >> The idea is to act "as usual", just to skip unnecessary phases... >> > >> > So someone adds optional selinux support to a package, and then you end >> > up with selinux being "on", despite not having it, and then another >> > package depends upon your package with [selinux], and the dependency is >> > mistakenly treated as met... >> If the developer has added IUSE=3Dselinux and bumps from -r1 to -r1.1, >> he has of course verified that this USE-change does not require >> recompilation either way, since otherwise he would not have been >> allowed to explicitly say the package manager that recompilation >> is unnecessary. >> So the dependency is *correctly* treated as met. > > Excuse me but are we talking about updating *DEPEND or IUSE? You are right, according to my original suggestion, the developer should not even have been allowed to bump only a minor revision. This is already discussing some possible extension/misuse of the feature.
[gentoo-dev] Re: don't rely on dynamic deps
Michał Górny wrote: > > Python is irrelevant here. Our dependencies are USE-conditional You are right, I overlooked this.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 15:11:36 + (UTC) Martin Vaeth wrote: > Ciaran McCreesh wrote: > > Martin Vaeth wrote: > > The problems are of a different kind. Static dependencies don't do > > something that you want them to do. Dynamic dependencies are > > outright broken. > > Please, stop your childish behaviour. > You prove nothing be repeating claims which had just been disproved. 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. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Michał Górny wrote: > > All people with enough knowledge already know that this is technically > impossible. We already discussed in the bug how it *would* be possible, just nobody implements it: Portage would have to use dynamic deps throughout, using the data stored in /var/db only to find out the correct information for := dependencies. This would fix the behaviour except for some corner cases concerning orphaned packages which can lead to broken situations with any approach. > This is not theoretical physics Indeed, it just would just need a little programming.
Re: [gentoo-dev] Re: don't rely on dynamic deps
Martin Vaeth: > > Indeed, it just would just need a little programming. > would you like to implement it?
Re: [gentoo-dev] Re: don't rely on dynamic deps
Dnia 2014-07-26, o godz. 15:27:51 Martin Vaeth napisał(a): > Michał Górny wrote: > > > > All people with enough knowledge already know that this is technically > > impossible. > > We already discussed in the bug how it *would* be possible, > just nobody implements it: > > Portage would have to use dynamic deps throughout, > using the data stored in /var/db only to find out > the correct information for := dependencies. This is only one of the issue. And what if the match for := is incompatible with new dependency atom? Like when you replace 'dev-foo/bar:=' with '>=dev-foo/bar-2:=' but bar-1 is installed. What if a new := dependency is added? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About current ppc/ppc64 status
On Sat, Jul 26, 2014 at 10:44:26AM +0200, Pacho Ramos wrote: > El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió: > > El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió: > > > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote: > > > > On 07/25/14 15:50, Pacho Ramos wrote: > > > > > El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió: > > > > >> On 07/25/14 15:28, Pacho Ramos wrote: > > > > >>> That is the reason for me thinking that maybe the way to go would > > > > >>> be to > > > > >>> do the opposite -> keep only base-system and a few others stable and > > > > >>> drop stable for most of the rest. This big effort could be > > > > >>> accomplished > > > > >>> in a week by other developers willing to help (like me) and would > > > > >>> solve > > > > >>> the issue for the long term. I guess that is what HPPA team did in > > > > >>> the > > > > >>> past and I think it's working pretty well for them (in summary, > > > > >>> have a > > > > >>> stable tree they are able to keep stable). That will also help > > > > >>> people in > > > > >>> ppc* teams to know that the remaining stabilization bugs, apart of > > > > >>> being > > > > >>> much less, are important enough to deserve rapid attention, as > > > > >>> opposed > > > > >>> to current situation that will have some important bugs mixed with > > > > >>> tons > > > > >>> of stabilization requests of apps that got ppc stable keywords > > > > >>> years ago > > > > >>> and are currently no so important. > > > > >>> > > > > >> Yes, please let's just do base system stable. I've been randomly > > > > >> taking > > > > >> care of ppc but nothing systematic. Its pretty spotty. But at the > > > > >> same > > > > >> time I don't like the idea of just loosing all the stabilization > > > > >> effort > > > > >> on the base system, so that might work best. Something to think about > > > > >> for mips too. > > > > >> > > > > >> > > > > > Nice, one think we would need to discuss is what do we consider base > > > > > system :/ > > > > > > > > > > I guess packages maintained by base-system, toolchain and... > > > > > xorg-server > > > > > and co... what more > > > > > > > > > > Not sure if we could have a list of current stable tree for ppc*, once > > > > > do we have that list, ppc* teams can drop from that list what they > > > > > want > > > > > and we get a new list that will be the final result. What do you think > > > > > about that? > > > > > > > > > > > > > > > > > > At the very least, its what's needed to build the stages with catalyst. > > > > > > > > I would think we should start with base/packages, but I don't want to > > > > limit it to just those because I at least need a more for building and > > > > maintaining. Where should we start to compile such a list? > > > > > > If we are going to do this, I think we should drop these arch's > > > to exp status in the profiles. That way, it keeps repoman from bothering > > > the rest of us about stabilizations, and we don't have to worry about > > > filing stable requests on them. > > > > > > That would let you stabilize things that you need to build the stages. > > > > > > William > > > > > > > But, moving ppc* to exp wouldn't lead us to likely break their tree? > > (because we wouldn't get any dependency issue even with "base" > > packages...) > > > > > > I was thinking in this plan: > - Get a list with all packages stable on ppc > - Drop from that list what ppc teams want > - Run on all that packages ekeyword ~ppc* > - Run repoman to the full tree to fix the dependencies, use.stable.mask > some, tune the list of stable packages... That sounds reasonable, but, my point still stands. It would be up to you to maintain that list and stabilize new versions of those packages. I'm sure that's what the other architectures are doing that are marked exp. To answer Pacho's question about breaking their tree, well, if they know which packages they want stable, and we move the arch to exp, it is up to them to make sure their tree stays valid. I'm sure the other exp architectures do the same. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 15:27:51 + (UTC) Martin Vaeth wrote: > Michał Górny wrote: > > All people with enough knowledge already know that this is > > technically impossible. > > We already discussed in the bug how it *would* be possible, > just nobody implements it: > > Portage would have to use dynamic deps throughout, > using the data stored in /var/db only to find out > the correct information for := dependencies. > > This would fix the behaviour except for some > corner cases concerning orphaned packages which > can lead to broken situations with any approach. Your solution fails spectacularly in the following ways: * Ebuild removal * Overlays * Introduction of := dependencies * pkg_*rm Which brings us back to the "all people with enough knowledge already know that this is technically impossible" thing... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > Martin Vaeth wrote: >> Ciaran McCreesh wrote: >> > Martin Vaeth wrote: >> > The problems are of a different kind. Static dependencies don't do >> > something that you want them to do. Dynamic dependencies are >> > outright broken. >> Please, stop your childish behaviour. >> You prove nothing be repeating claims which had just been disproved. > > 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. *Neither* dynamic deps nor static deps solve this problem satisfactory (How often did I repeat this now?). Probably there does not exist *any* satisfactory solution to orphaned packages at all. So this case is not a valid argument to prefer one method over another.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 15:40:40 + (UTC) Martin Vaeth 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. > > *Neither* dynamic deps nor static deps solve this problem satisfactory > (How often did I repeat this now?). With static dependencies, you have correct dependency information, and the worst that can happen is occasionally you might have to rebuild a package where nothing substantial has changed. However, this is a general issue with bumps (recompiling the whole thing for an init script or language file change, recompiling the whole thing for a change to only one of the binaries provided by a package, and so on), so it is not a "static dependencies" problem. With dynamic dependencies, you have incorrect dependency information, your system randomly breaks on a sync, you sometimes can't uninstall packages due to pkg_* breakage, uninstalling a package sometimes looks safe but isn't, overlays don't work, subslots don't work, binaries don't work, and dependencies can appear to be met when they aren't. So in summary, dynamic dependencies are broken, and static dependencies are correct, and the only issue you think you have with static dependencies isn't a problem specific to static dependencies and isn't reliably solved by dynamic dependencies. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Michał Górny wrote: > > This is only one of the issue. Not all cases need to be solved: If a developer decides that no revbump is not necessary, he should not have a too problematic change... > And what if the match for :=3D is > incompatible with new dependency atom? Like when you replace > 'dev-foo/bar:=3D' with '>=3Ddev-foo/bar-2:=3D' but bar-1 is installed. This is simple: The dependency is not satisfied. > What if a new :=3D dependency is added? If it is *added* in an || ( ... ), it can safely be ignored. Adding such a dependency unconditionally should probably require a revbump.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 15:59:58 + (UTC) Martin Vaeth wrote: > > And what if the match for :=3D is > > incompatible with new dependency atom? Like when you replace > > 'dev-foo/bar:=3D' with '>=3Ddev-foo/bar-2:=3D' but bar-1 is > > installed. > > This is simple: The dependency is not satisfied. That isn't simple at all... It means you can't uninstall or upgrade the package... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Ciaran McCreesh wrote: > Your solution fails spectacularly in the following ways: > > * Ebuild removal Already discussed as to fail with static deps, too. > * Overlays Not an issue: Exactly the information of that ebuild which *would* be used if you reemerge contains the relevant data. > * Introduction of :=3D dependencies This is not a "minor update" in dependencies and thus requires a revbump. > * pkg_*rm Not related. > Which brings us back to the ... previous childish behaviour
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 16:05:58 + (UTC) Martin Vaeth wrote: > Ciaran McCreesh wrote: > > Your solution fails spectacularly in the following ways: > > > > * Ebuild removal > > Already discussed as to fail with static deps, too. Uh, static dependencies don't behave any differently when an ebuild is removed. I don't think you understand how that works. > > * Overlays > > Not an issue: Exactly the information of that ebuild > which *would* be used if you reemerge contains > the relevant data. The association between an installed package and "the ebuild it came from" doesn't work correctly when overlays around. Again, you don't understand the issue. > > * Introduction of :=3D dependencies > > This is not a "minor update" in dependencies > and thus requires a revbump. So what is a "minor update", and what are you planning to do to prevent what you call "useless rebuilds" when := dependencies are introduced? > > * pkg_*rm > > Not related. Yes it is. Read and understand the previous discussion about the ruby-config issue. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
hasufell wrote: > Martin Vaeth: > >> Indeed, it just would just need a little programming. > > would you like to implement it? I thought about it, but unfortunately, I am currently (and for a long period) so busy with my job that this is not realistic - I did not even find the time to implement minor revisions completely (also, since it would cost me too much time to get sufficient familiar with python and the portage implementation).
Re: [gentoo-dev] About current ppc/ppc64 status
I know I'm replying to my own message, but I do have a concern about this that I want to ask about. When a stable request is filed for a package, it is filed for all architectures which have the ~arch keyword for the package and are marked stable or dev in profiles.desc. If an arch wants to stay marked stable or dev but only stabilize a subset of packages, I think it is reasonable to drop that arch's keywords from packages they decide not to stabilize rather than move the keywords to ~arch. That makes it obvious that we shouldn't file stable requests on that package for that arch. What does everyone else think? William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, Jul 26, 2014 at 12:14 PM, Ciaran McCreesh wrote: > On Sat, 26 Jul 2014 16:05:58 + (UTC) > Martin Vaeth wrote: >> Ciaran McCreesh wrote: >> > Your solution fails spectacularly in the following ways: > >> > * Introduction of :=3D dependencies >> >> This is not a "minor update" in dependencies >> and thus requires a revbump. > > So what is a "minor update", and what are you planning to do to prevent > what you call "useless rebuilds" when := dependencies are introduced? > Picking this to illustrate my point, not to endorse a particular implementation here... This is what I'm getting at when I argue that we don't need a solution to every possible problem. If we only accept solutions that handle conditional dependencies, IUSE changes, new eclass inherits, dep additions, dep removals, etc, then it does seem likely to me that we'll never find a good solution. On the other hand, if we can come up with something that RELIABLY fixes things for 3/4ths of these, then that is probably good enough. I'm not certain at this point that even such a partial solution doesn't exist, but the fact that any particular solution doesn't handle every possible case isn't automatically a reason to reject it. Preventing unnecessary rebuilds is a worthwhile goal, even if we can't get 100% of the way there. If you don't care whatsoever about unnecessary rebuilds then we can simplify things tremendously - just have the package manager default to --emptytree on all operations. Sure, it might cause a "few" unnecessary ebuilds but whether your package manager attempts to support dynamic deps or not you'll certainly have an up-to-date dependency cache. Rich
Re: [gentoo-dev] About current ppc/ppc64 status
Am Samstag, 26. Juli 2014, 18:20:11 schrieb William Hubbs: > I know I'm replying to my own message, but I do have a concern about > this that I want to ask about. > > When a stable request is filed for a package, it is filed for all > architectures which have the ~arch keyword for the package and are > marked stable or dev in profiles.desc. > > If an arch wants to stay marked stable or dev but only stabilize a > subset of packages, I think it is reasonable to drop that arch's > keywords from packages they decide not to stabilize rather than move the > keywords to ~arch. That makes it obvious that we shouldn't file stable > requests on that package for that arch. I'd say the decision should be made by the arch team, not by the package maintainer. Means, arch teams can drop keywors in packages, but normally stabilization goes ahead as usual and requests are filed. Whether they are then honoured is another question. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 12:28:27 -0400 Rich Freeman wrote: > Sure, it might cause a "few" unnecessary ebuilds but whether your > package manager attempts to support dynamic deps or not you'll > certainly have an up-to-date dependency cache. VDB is not a cache. This is important. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, Jul 26, 2014 at 12:02 PM, Ciaran McCreesh wrote: > On Sat, 26 Jul 2014 15:59:58 + (UTC) > Martin Vaeth wrote: >> > And what if the match for :=3D is >> > incompatible with new dependency atom? Like when you replace >> > 'dev-foo/bar:=3D' with '>=3Ddev-foo/bar-2:=3D' but bar-1 is >> > installed. >> >> This is simple: The dependency is not satisfied. > > That isn't simple at all... It means you can't uninstall or upgrade the > package... Why not? How is this any different from unmerging bar-1 back when bar-1 satisfied the dependency (using --unmerge which breaks reverse dependencies)? If you want to upgrade or re-install the package I would expect portage to pull in the missing dependency. I'd expect the next emerge -u world to do that as well, which it already does if you --unmerge a dependency). If there would be some unintended side-effect from doing things this way I'm all ears, but as long as you don't get into @system circular dependencies issues I'd expect portage to be able to install any packages that are missing after such a dependency change. Sure, until the missing dep is installed I'd expect a risk of breakage, but that is no different than what I'd expect if the package were modified without a bump and the package manager didn't attempt to support dynamic dependencies. Rich
[gentoo-dev] Re: About current ppc/ppc64 status
On 07/27/2014 02:20 AM, William Hubbs wrote: > I know I'm replying to my own message, but I do have a concern about > this that I want to ask about. > > When a stable request is filed for a package, it is filed for all > architectures which have the ~arch keyword for the package and are > marked stable or dev in profiles.desc. I normally only target archs that are already stable for that package. There's a lot of packages in the tree stable for eg. amd64/x86 and testing for all others.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Sat, 26 Jul 2014 12:36:45 -0400 Rich Freeman wrote: > On Sat, Jul 26, 2014 at 12:02 PM, Ciaran McCreesh > wrote: > > On Sat, 26 Jul 2014 15:59:58 + (UTC) > > Martin Vaeth wrote: > >> > And what if the match for :=3D is > >> > incompatible with new dependency atom? Like when you replace > >> > 'dev-foo/bar:=3D' with '>=3Ddev-foo/bar-2:=3D' but bar-1 is > >> > installed. > >> > >> This is simple: The dependency is not satisfied. > > > > That isn't simple at all... It means you can't uninstall or upgrade > > the package... > > Why not? pkg_prerm. See the discussion about the ruby-config problem. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
On 07/26/2014 07:59 AM, Tom Wijsman wrote: > On Wed, 23 Jul 2014 22:14:41 +1000 > Michael Palimaka wrote: > >> On 07/23/2014 09:36 AM, Tom Wijsman wrote: >>> On Tue, 22 Jul 2014 18:21:00 +1000 >>> Michael Palimaka wrote: >>> What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds >>> >>> Do you upgrade @world every hour and thus have it cause excessive >>> heat? >>> >>> If I upgrade every X weeks they become much more cool and >>> necessary... >>> >> >> Shouldn't we strive to avoid the unnecessary rebuilds in the first >> place? Doing updates on your schedule only avoids the symptom, not the >> problem. > > We should strive to do both; cause less rebuilds, update less often. > > It is comparable to flooding on IRC channels; if you send much more > messages, you are much more likely to experience a kick and/or a ban. > > It is easier not to flood than to convince people there is no problem > with you flooding the channel; out of all the IRC channels I know of, > I've only come across one where they don't mind pasted long code blocks > but that's mostly because of the lack of active moderation and people. > > (With "flooding" as "updating" and "kick/ban" as "rebuilds") > Each person should update at a frequency that suits them. Recommending to update every $period is not a valid solution to unnecessary rebuilds.
Re: [gentoo-dev] About current ppc/ppc64 status
On Sat, Jul 26, 2014 at 06:31:50PM +0200, Andreas K. Huettel wrote: > Am Samstag, 26. Juli 2014, 18:20:11 schrieb William Hubbs: > > I know I'm replying to my own message, but I do have a concern about > > this that I want to ask about. > > > > When a stable request is filed for a package, it is filed for all > > architectures which have the ~arch keyword for the package and are > > marked stable or dev in profiles.desc. > > > > If an arch wants to stay marked stable or dev but only stabilize a > > subset of packages, I think it is reasonable to drop that arch's > > keywords from packages they decide not to stabilize rather than move the > > keywords to ~arch. That makes it obvious that we shouldn't file stable > > requests on that package for that arch. > > I'd say the decision should be made by the arch team, not by the package > maintainer. > > Means, arch teams can drop keywors in packages, but normally stabilization > goes ahead as usual and requests are filed. Whether they are then honoured is > another question. If an arch team isn't going to honor a stable request, shouldn't they remove themselves from it and say so? Also, if an arch team does that, does that mean we don't have to file stable requests for that arch on future versions of the package? William signature.asc Description: Digital signature
[gentoo-dev] Re: About current ppc/ppc64 status
On 07/27/2014 03:19 AM, William Hubbs wrote: > If an arch team isn't going to honor a stable request, shouldn't they > remove themselves from it and say so? > > Also, if an arch team does that, does that mean we don't have to file > stable requests for that arch on future versions of the package? When armin did stabilisation for minor archs in the past, he took the opportunity to evaluate whether it was still useful to have the package stable. In many cases for small random packages, stable keywords were dropped to reduce future workload. I always thought it was a pretty good strategy.
