[gentoo-dev] Re: don't rely on dynamic deps
Tom Wijsman posted on Sat, 26 Jul 2014 00:09:58 +0200 as excerpted: > EAPI specifies what PMs need to conform to, not the other way around; > EAPI-0 may very well be derived from Portage, that doesn't make such > side features that have not been specified in EAPI-0 a part of EAPI-0. Not being around at the time, you may not know some of the history, but feel free to ask Ciaranm if you need a more authoritative source. The thing is, EAPI-0 was not originally completely specified, and to my knowledge, remains that way, because that would have been real-world essentially impossible to do. Instead, a convenient shortcut was taken. EAPI-0 was defined as what portage did at the time, with EAPI-1 for sure and I believe EAPI-2 at least, being defined as the the previous EAPI, with specifically defined changes, but with the base EAPI still only fuzzily defined as, basically, what portage did at the time. And since the beginning, while there have been other unapproved EAPIs not allowed in the main gentoo tree, because portage was and remains the official default PM, no EAPI has been approved for main-tree deployment until portage had a working implementation. So while portage can and certainly does have bugs where it doesn't meet EAPI requirements, particularly for behavior there since EAPI-0 and not specifically defined to be different in a specific EAPI since then, to the extent that PMS applies at all, the interpretation of PMS must still be read in the context of what portage did all those years ago with the original EAPI-0 spec, since EAPI-0 was /defined/ based on portage behavior at the time. Which then begs the question[1] I asked, how old /is/ this dynamic-deps behavior? Does it extend back to EAPI-0? My gut sense from memory as a user back then and now is that it does, but that's simply a gut sense I'm ill equipped to go back and verify. --- [1] Begs the question: Yes, I'm aware of the legal and philosophical "circular logic" usage, now generally legacy in terms of real-world use except in the philosophic and legal areas. I deliberately choose to use the phrase in the newer and now much more common sense, rhetorically personifying the question such that it can "beg to be asked". -- 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] don't rely on dynamic deps
On Wednesday 23 July 2014 01:06:15 Tom Wijsman wrote: > On Tue, 22 Jul 2014 08:10:20 +0300 > > Samuli Suominen wrote: > > On 22/07/14 04:05, Rick "Zero_Chaos" Farina wrote: > > > And just for fun, since no one has mentioned it yet, dynamic deps > > > don't work at all on binpkgs since the Packages file contains the > > > deps (like vardb) and it doesn't get updated (just like vardb). > > > > Known long standing pitfall. It's managable. > > It is one of the reasons I see binpkgs as breaking progress instead of > being part of the progress; it is manageable, but it could be better. > So you'd rather have people not using Gentoo because you can't agilely pivot your strategy mixin? Without binpkg support I'd feel the need to hack it up, just to get things fast enough. It's one of the features that haven't been made popular enough (eh, we could easily provide binpkg-updates for @system for all profiles and the most common arches (amd64, x86, maybe arm) - I've been running a cronjob doing that for x86+amd64 for about a year now) This perspective of "I don't need it, thus it shouldn't exist" is quite ... amusing.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Fri, 25 Jul 2014 05:44:34 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > How long have dynamic-deps been around? Since EAPI-0? Because if > so, that interpretation must be incorrect, since EAPI-0 was defined > as portage behavior at the time, and AFAIK, no EAPI since then has > been approved without a working portage implementation. Good question, probably needs a dig in the old Portage history; it is something long the search terms of dynamic dependencies in FakeVarTree, given that the parameter[1] has been added later on. EAPI specifies what PMs need to conform to, not the other way around; EAPI-0 may very well be derived from Portage, that doesn't make such side features that have not been specified in EAPI-0 a part of EAPI-0. [1]: Add emerge --dynamic-deps option. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f8e0c75e > In the context of dynamic-deps I'd interpret the above to mean within > a single portage session. What happens some sessions later when an > ebuild's deps are dynamic-updated after a tree sync is an entirely > new session, and unless I'm missing something, the above PMS > requirements can be met within a single session with dynamic-deps. Apart from the words "merge" and "batch", which are in the piece of text that I've quoted; I'm not sure how for the rest of the piece a session can be deduced or interpreted from what is specified. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
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") -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 16:46:07 -0500 William Hubbs wrote: > On Fri, Jul 25, 2014 at 10:25:57PM +0100, Ciaran McCreesh wrote: > > On Fri, 25 Jul 2014 16:23:23 -0500 > > William Hubbs wrote: > > > I think this could get complicated really quick though. > > > For example, if I have an ebuild with three use flags, > > > flag1/flag2/flag3 with the requirement that one and only one of > > > them must be set, unless bash has an xor operator I don't know > > > about, that is going to need a lot of nesting etc to get right. > > > > You don't want xor. You want addition. > > Can you show an example? Well, if the use flag is on, you count it as 1, and if it's off, you count it as 0. Then "need at least one" is just "the sum of these values is at least 1", and "need exactly one" is "the sum of these values is exactly 1". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, Jul 25, 2014 at 10:25:57PM +0100, Ciaran McCreesh wrote: > On Fri, 25 Jul 2014 16:23:23 -0500 > William Hubbs wrote: > > I think this could get complicated really quick though. > > For example, if I have an ebuild with three use flags, > > flag1/flag2/flag3 with the requirement that one and only one of them > > must be set, unless bash has an xor operator I don't know about, that > > is going to need a lot of nesting etc to get right. > > You don't want xor. You want addition. Can you show an example? Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 16:23:23 -0500 William Hubbs wrote: > I think this could get complicated really quick though. > For example, if I have an ebuild with three use flags, > flag1/flag2/flag3 with the requirement that one and only one of them > must be set, unless bash has an xor operator I don't know about, that > is going to need a lot of nesting etc to get right. You don't want xor. You want addition. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 17:13:18 -0400 Ian Stakenvicius wrote: > REQUIRED_USE came first, pkg_pretend came later, iirc. In theory, > REQUIRED_USE could have made a nice interactive way to resolve use > conflicts, it just never did. Nope. pkg_pretend came first, and had an implemented and user-tested prototype. REQUIRED_USE was shoehorned in at the last minute without an implementation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, Jul 25, 2014 at 03:54:53PM -0400, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 25/07/14 03:51 PM, Pacho Ramos wrote:
> > El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
> >> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
> >> wrote:
> >>> Okay, I didn't think of that. I'm not sure if the blocker deps
> >>> or the REQUIRED_USE would be more helpful for Portage, but
> >>> generally I think that the REQUIRED_USE error message is quite
> >>> hard to understand for unexperienced users -- much more so than
> >>> the error generated by a blocker dep.
> >>
> >> ...and the fix for that is to scrap REQUIRED_USE and use
> >> pkg_pretend instead.
> >>
> >
> > Could you give an example to let us see how pkg_pretend could be
> > used to achieve the same as REQUIRED_USE?
> >
> > Thanks
> >
> >
>
> pkg_pretend() {
> if use heimdal && use mit-krb5; then
> eerror "Please set only one of the use following flags:"
> eerror "heimdal, mit-krb5"
> die "conflicting use flags set"
> fi
> }
I think this could get complicated really quick though.
For example, if I have an ebuild with three use flags,
flag1/flag2/flag3 with the requirement that one and only one of them
must be set, unless bash has an xor operator I don't know about, that
is going to need a lot of nesting etc to get right.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/07/14 04:12 PM, Pacho Ramos wrote:
> El vie, 25-07-2014 a las 15:54 -0400, Ian Stakenvicius escribió:
>> On 25/07/14 03:51 PM, Pacho Ramos wrote:
>>> El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh
>>> escribió:
On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
wrote:
> Okay, I didn't think of that. I'm not sure if the blocker
> deps or the REQUIRED_USE would be more helpful for Portage,
> but generally I think that the REQUIRED_USE error message
> is quite hard to understand for unexperienced users -- much
> more so than the error generated by a blocker dep.
...and the fix for that is to scrap REQUIRED_USE and use
pkg_pretend instead.
>>>
>>> Could you give an example to let us see how pkg_pretend could
>>> be used to achieve the same as REQUIRED_USE?
>>>
>>> Thanks
>>>
>>>
>>
>> pkg_pretend() { if use heimdal && use mit-krb5; then eerror
>> "Please set only one of the use following flags:" eerror
>> "heimdal, mit-krb5" die "conflicting use flags set" fi }
>
> Ah, ok, I was wondering why REQUIRED_USE was implemented then :/,
> I guess it was for simplifying ebuilds?
>
>
REQUIRED_USE came first, pkg_pretend came later, iirc. In theory,
REQUIRED_USE could have made a nice interactive way to resolve use
conflicts, it just never did.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPSyG4ACgkQ2ugaI38ACPC07wD/VnEG/w0nvYlNsVJszyPXgK0l
Z9YZ3zWOeMffAJiM7NQBAI8x5G5+EXgCrd8gGAA20ENZ5RIuN6qJoE1INRY6x84+
=6L9c
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/07/14 04:41 PM, Michał Górny wrote: > Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius > napisał(a): > >> +REQUIRED_USE="heimdal? ( !mit-krb5 ) + mit-krb5? ( >> !heimdal )" > > Did you mean: > > REQUIRED_USE="^^ ( heimdal mit-krb5 )" > > ? > Nope, that requires one or the other to be set. If users don't care, they shouldn't have to set one at all. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPSx5cACgkQ2ugaI38ACPCJQgD/TxYSU4AUzGWqEmG/Y+rM50Jr 4m25kOPR+DCp17Gr4SIA/1lu1gBm4fL/ZwDXe5lpy0N+FZmJjhdB0guhJGGieH7S =pMB6 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius napisał(a): > +REQUIRED_USE="heimdal? ( !mit-krb5 ) > + mit-krb5? ( !heimdal )" Did you mean: REQUIRED_USE="^^ ( heimdal mit-krb5 )" ? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 22:12:53 +0200 Pacho Ramos wrote: > Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I > guess it was for simplifying ebuilds? It was a historical mistake: originally we were going to use pkg_pretend for this. But claims were made that this would break some mythical auto-building systems, and that something machine-readable was needed. Unfortunately the Council bought this, and put through REQUIRED_USE without a reference implementation. Needless to say, the end result is something that isn't human-readable, and isn't used by any mythical auto-building systems. (Incidentally, Exherbo has a both human- and machine-readable implementation, which *is* used by an auto-building system, but the syntax won't meet Gentoo approval...) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
El vie, 25-07-2014 a las 15:54 -0400, Ian Stakenvicius escribió:
> On 25/07/14 03:51 PM, Pacho Ramos wrote:
> > El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
> >> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
> >> wrote:
> >>> Okay, I didn't think of that. I'm not sure if the blocker deps
> >>> or the REQUIRED_USE would be more helpful for Portage, but
> >>> generally I think that the REQUIRED_USE error message is quite
> >>> hard to understand for unexperienced users -- much more so than
> >>> the error generated by a blocker dep.
> >>
> >> ...and the fix for that is to scrap REQUIRED_USE and use
> >> pkg_pretend instead.
> >>
> >
> > Could you give an example to let us see how pkg_pretend could be
> > used to achieve the same as REQUIRED_USE?
> >
> > Thanks
> >
> >
>
> pkg_pretend() {
> if use heimdal && use mit-krb5; then
> eerror "Please set only one of the use following flags:"
> eerror "heimdal, mit-krb5"
> die "conflicting use flags set"
> fi
> }
Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I
guess it was for simplifying ebuilds?
Re: [gentoo-dev] About current ppc/ppc64 status
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 signature.asc Description: Digital signature
Re: [gentoo-dev] About current ppc/ppc64 status
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? -- 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] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/07/14 03:51 PM, Pacho Ramos wrote:
> El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
>> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
>> wrote:
>>> Okay, I didn't think of that. I'm not sure if the blocker deps
>>> or the REQUIRED_USE would be more helpful for Portage, but
>>> generally I think that the REQUIRED_USE error message is quite
>>> hard to understand for unexperienced users -- much more so than
>>> the error generated by a blocker dep.
>>
>> ...and the fix for that is to scrap REQUIRED_USE and use
>> pkg_pretend instead.
>>
>
> Could you give an example to let us see how pkg_pretend could be
> used to achieve the same as REQUIRED_USE?
>
> Thanks
>
>
pkg_pretend() {
if use heimdal && use mit-krb5; then
eerror "Please set only one of the use following flags:"
eerror "heimdal, mit-krb5"
die "conflicting use flags set"
fi
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPStg0ACgkQ2ugaI38ACPDSMQD/UfMayFMJPP3VqzEvR5IwbBjX
w3/JiWDgm6NcYnU+ZTUBAIACTI52ZJn+TUvxWHHwggEv1+ThwIAp5rOIUUl68fce
=MX30
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió: > On Fri, 25 Jul 2014 21:44:02 +0200 > Luis Ressel wrote: > > Okay, I didn't think of that. I'm not sure if the blocker deps or the > > REQUIRED_USE would be more helpful for Portage, but generally I think > > that the REQUIRED_USE error message is quite hard to understand for > > unexperienced users -- much more so than the error generated by a > > blocker dep. > > ...and the fix for that is to scrap REQUIRED_USE and use pkg_pretend > instead. > Could you give an example to let us see how pkg_pretend could be used to achieve the same as REQUIRED_USE? Thanks
Re: [gentoo-dev] About current ppc/ppc64 status
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?
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/07/14 03:46 PM, Ciaran McCreesh wrote: > On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel > wrote: >> Okay, I didn't think of that. I'm not sure if the blocker deps or >> the REQUIRED_USE would be more helpful for Portage, but generally >> I think that the REQUIRED_USE error message is quite hard to >> understand for unexperienced users -- much more so than the error >> generated by a blocker dep. > > ...and the fix for that is to scrap REQUIRED_USE and use > pkg_pretend instead. > Yep, could do it that way instead. I'm not tied to any particular implementation. Back to the concept, though -- thoughts? Is it worth the work? Should it be avoided for whatever reason? Will it just confuse end-users? Am I suggesting a fix for a problem we don't really have? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPStOIACgkQ2ugaI38ACPCZrwD+J7qqH5a1YVsFoIt+UmT9rOLq TSkd6ai7Eum0MEo6CKsA/3Gsuu9O16rua/LZxeW3i3+qBFufIBDQPqU9YwAyU5lJ =VMCu -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel wrote: > Okay, I didn't think of that. I'm not sure if the blocker deps or the > REQUIRED_USE would be more helpful for Portage, but generally I think > that the REQUIRED_USE error message is quite hard to understand for > unexperienced users -- much more so than the error generated by a > blocker dep. ...and the fix for that is to scrap REQUIRED_USE and use pkg_pretend instead. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 15:23:47 -0400 Ian Stakenvicius wrote: > This is something that should only be done on a case-by-case basis, as > needed -- for instance, with virtual/krb5 only one provider can be > installed at a time as they block eachother. > > We could leave it up to portage to error on mit-krb5 and heimdal being > forced into the installation despite blocking eachother, but i think > portage would have a better chance telling end-users about the > conflict (and maybe helping to resolve it better via --autounmask?) if > there was a REQUIRED_USE. Okay, I didn't think of that. I'm not sure if the blocker deps or the REQUIRED_USE would be more helpful for Portage, but generally I think that the REQUIRED_USE error message is quite hard to understand for unexperienced users -- much more so than the error generated by a blocker dep. " The following REQUIRED_USE flag constraints are unsatisfied: heimdal? ( !mit-krb5 ) mit-krb5? ( !heimdal )" " might be a bit confusing to some people, and remember that constraint string would grow much longer if there were more providers, as grows quadratically. Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] About current ppc/ppc64 status
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. -- 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] About current ppc/ppc64 status
Hello With last gnome maintained packages stabilization round I noticed some pending stabilizations/keywordings for really a long time waiting for ppc* teams. For example: https://bugs.gentoo.org/show_bug.cgi?id=470768 -> it's waiting for more than a year and it's blocking from dropping old versions for so long https://bugs.gentoo.org/show_bug.cgi?id=508006 -> the same case, and we cannot drop that stable keywords because looks like ppc team still wants to keep kde in stable Then, I finally needed to ask Agostino for help because of that and I wondered if there are some kind of issue in this teams, if they are still able to keep ppc* as stable arches or... :/ I see two options: - Move ppc* to testing only -> I guess some people will disagree as this architecture is not so old and probably it's still used by enough people - Clarify what packages do they really want in stable. The problem of all this is that, as it is shown in this concrete example, if they want to keep, for example, KDE in stable, they will need to also be fast enough for other dependencies. If not, we could go with the "package-per-package" proposal that was approved one year ago by the Council for alpha/ia64. But the problem of "package-per-package" proposal is shown in: https://bugs.gentoo.org/show_bug.cgi?id=470768#c9 Once we start dropping stable keyword in one package, we need to do the same in reverse-deps, that will also have other reverse-deps... and that it ends up being a lot of work arch teams cannot accomplish (as they are the same teams that are so overloaded that cannot keep stabilizing fast enough) and things get blocked forever :( 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. Thanks a lot
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/07/14 03:04 PM, Luis Ressel wrote: > I guess that would solve some of the issues we've had with virtuals > in the past. I support the idea, however, I'm not sure of the > technical consequences it might have. > > I would leave the REQUIRED_USE out. It's a hassle to write, and if > an user decides to set multiple use flags on such a virtual, why > not just let him do it? > This is something that should only be done on a case-by-case basis, as needed -- for instance, with virtual/krb5 only one provider can be installed at a time as they block eachother. We could leave it up to portage to error on mit-krb5 and heimdal being forced into the installation despite blocking eachother, but i think portage would have a better chance telling end-users about the conflict (and maybe helping to resolve it better via --autounmask?) if there was a REQUIRED_USE. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPSrsMACgkQ2ugaI38ACPB6NgD+NK2m8iM46YMi9kITUFEIQ/ih J67PjULbQ5ZHDRQDUs4A/ik+XNbsjNQwFd08jMD1dVG0DLr7VRVvUGz1VpmQB7so =Myry -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
I guess that would solve some of the issues we've had with virtuals in the past. I support the idea, however, I'm not sure of the technical consequences it might have. I would leave the REQUIRED_USE out. It's a hassle to write, and if an user decides to set multiple use flags on such a virtual, why not just let him do it? Regards, Luis Ressel signature.asc Description: PGP signature
[gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey all.. So, putting aside for now how much of a mess this would be to implement in the virtuals' ebuilds themselves, what do people think of changing the virtuals so that they contain an entry in IUSE for each provider that can satisfy it? The idea here is that the package satisfying a virtual could be optionally explicitly-chosen through package.use (or USE= in make.conf, perhaps) instead of having an entry in @world, that way if nothing depends on the virtual then it and the provider can be - --depclean'ed from the system. The idea is specifically NOT to have rdeps depend on these flags, that would undermine the whole purpose of the virtual; it would just be for end-users to set if they so chose. This may also help with getting portage to peg a virtual's provider to a specific package instead of constantly trying to switch from one to another, ie, how systemd kept getting pulled in, in relation to the upower virtual. Note - I haven't done any tests to determine if this actually helps with such issues tho (or even attempted to reproduce them, as i was apparently one of the lucky ones that it didn't happen to). I don't know if this would aid heavy binpkg users or not. For completion, here's one of those rather messy examples: - --- virtual/krb5-0.ebuild 2013-06-28 09:04:47.0 -0400 +++ virtual/krb5-0.ebuild.new 2014-07-25 14:47:48.0 -0400 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2 2013/06/27 20:42:55 aballier Exp $ - -EAPI=3 +EAPI=5 DESCRIPTION="Virtual for Kerberos V implementation" HOMEPAGE="" @@ -11,7 +11,12 @@ LICENSE="" SLOT="0" KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos" - -IUSE="" +IUSE="heimdal mit-krb5" DEPEND="" - -RDEPEND="|| ( app-crypt/mit-krb5 app-crypt/heimdal )" +RDEPEND="!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5 app-crypt/heimdal ) ) ) + mit-krb5? ( app-crypt/mit-krb5 ) + heimdal? ( app-crypt/heimdal )" + +REQUIRED_USE="heimdal? ( !mit-krb5 ) + mit-krb5? ( !heimdal )" Thoughts? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPSpsgACgkQ2ugaI38ACPCBGwD6A7Dlras5l/L9Fc1SA8K8oR3K LQKY5g/vbdvYFKtooDoBAKdLiFySl24mHKA0O2YScxmr4g5tvusVAd3dxWTIjnat =gSFT -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
On Fri, Jul 25, 2014 at 11:01 AM, Ciaran McCreesh wrote: > On Thu, 24 Jul 2014 21:45:58 -0400 > Rich Freeman wrote: >> Just a general comment not aimed at this particular part of the thread >> - a solution doesn't have to be perfect to be useful. > > 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" that nothing is actually correct any > more. I think we might be saying the same thing in different ways. I wasn't suggesting that we should implement solutions that fail in random ways, but rather that if necessary we should focus more on simpler solutions that we can get right, but which perhaps don't cover all of our problems. That is, I'm more for a perfect solution for a small problem rather than a good-enough solution (which isn't) for a big problem. For example, perhaps there is a way to safely add an unconditional dependency to an installed package. That won't solve every dependency problem, but it could be helpful. Another way to go about things would be to try to find ways to reduce the chance of commiting a package that has an incorrect dependency in the first place, so that we don't have to fix so many mistakes. Then perhaps the extra rebuilds when there is a rare mistake might be more forgivable. Rich
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/07/14 01:36 PM, Ian Stakenvicius wrote: > On 25/07/14 01:15 PM, Andreas K. Huettel 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) But I am not sure if it could be viable from a "technical" point of view :( >>> >>> 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. > >> I think we'd appreciate some more information here: > >> * What exactly is the metadata that we're talking about? * How >> much of it can be generated by sourcing the ebuild, without >> running phases? * When does that exactly break? Example? > > > It may help this overall discussion to step back even further > here: > > * What do we want to accomplish, exactly? > > - allow portage to emerge updated packages without rebuilding them > (ie running src_* and pkg_*inst phases), when it can be determined > from metadata changes (or for -rX.Y method perhaps it is assumed > -just- on filename changes) that this is not necessary. > > * What are all of the cases that would validly trigger this > dont-bother-to-run-phases shortcut? > > - addition of missing dependency [1] - new useflag not enabled by > default - removed useflag that was not previously enabled - > changing of dependency atom(s) -- ie swapping a specific atom to > virtual one - EAPI bump (maybe??) - <-- add more please! > > > * For each of the above, in what cases is a full rebuild probably > necessary anyhow?? > > - dependency atom minimum version is increased, and the in-VDB > version of this dep is too old (??) - new dependency atom is > missing from VDB (??) - EAPI bump adds new entries to VDB that need > to be calculated from say, merge phase - > > > > ..i think from there we can perhaps determine what metadata could > be updated and/or needs to be updated to maintain consistency in > the dont-rebuild cases we want. > I forgot: [1] since the package has merged prior to this anyhow, whatever dependency it was must have been installed already when this package was emerged. So if it can still be found in vdb then we should be safe to add the dependency to vdb of this package, otherwise we may need to trigger a rebuild. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPSllcACgkQ2ugaI38ACPCL3QD+ITe3bzJrJIORniniY9rzTEd5 W5nmL5zB+HiZuMZKdZQA/jrn88lx8bfn/f6DetPdrYiFjjShcXoeMbh5nCNmtcz9 =LEAi -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/07/14 01:15 PM, Andreas K. Huettel 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) >>> >>> But I am not sure if it could be viable from a "technical" >>> point of view :( >> >> 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. > > I think we'd appreciate some more information here: > > * What exactly is the metadata that we're talking about? * How much > of it can be generated by sourcing the ebuild, without running > phases? * When does that exactly break? Example? > It may help this overall discussion to step back even further here: * What do we want to accomplish, exactly? - allow portage to emerge updated packages without rebuilding them (ie running src_* and pkg_*inst phases), when it can be determined from metadata changes (or for -rX.Y method perhaps it is assumed - -just- on filename changes) that this is not necessary. * What are all of the cases that would validly trigger this dont-bother-to-run-phases shortcut? - - addition of missing dependency [1] - - new useflag not enabled by default - - removed useflag that was not previously enabled - - changing of dependency atom(s) -- ie swapping a specific atom to virtual one - - EAPI bump (maybe??) - - <-- add more please! * For each of the above, in what cases is a full rebuild probably necessary anyhow?? - - dependency atom minimum version is increased, and the in-VDB version of this dep is too old (??) - - new dependency atom is missing from VDB (??) - - EAPI bump adds new entries to VDB that need to be calculated from say, merge phase - - ..i think from there we can perhaps determine what metadata could be updated and/or needs to be updated to maintain consistency in the dont-rebuild cases we want. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPSlY0ACgkQ2ugaI38ACPBDHAD+POgCJlbPv9HHwhK4wxd8b2ir ywM71Aemu6SPfCTE2MIBAKATag94jCHLlqwkYN2jrW23tYqTi5ajOwLzoZ/EqHx0 =qUpY -END PGP SIGNATURE-
Re: Re: [gentoo-dev] don't rely on dynamic deps
> > 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) > > > > But I am not sure if it could be viable from a "technical" point of > > view :( > > 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. I think we'd appreciate some more information here: * What exactly is the metadata that we're talking about? * How much of it can be generated by sourcing the ebuild, without running phases? * When does that exactly break? Example? Thanks!!! -- Andreas K. Huettel Gentoo Linux developer kde, council
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/07/14 17:01, Ciaran McCreesh wrote: > 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" that nothing is actually > correct any more. It's one thing to get away with this > occasionally, but quite another to build an entire system upon it. > We can't afford more mistakes, and we have to actively fix existing > ones. This is my position as well. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPSfWkACgkQRtClrXBQc7XOcwD/Vmzd/B4IysGbczDAxI/X6CLw miOuIePVOSwIWRSMvx4A/0Kdy6SCxx2JCko9xMTcnAagqaoleWJeoPIwb1bUkE74 =2rq+ -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
Ciaran McCreesh: > On Fri, 25 Jul 2014 15:23:58 + > hasufell wrote: >>> That's not really helpful advice: dynamic dependencies can't be >>> fixed. Instead, you should say that anyone who thinks they have an >>> idea on how to fix dynamic deps should think about it until they >>> understand why it's wrong... >> >> I was rather talking about the "fix useless rebuilds" issue. It's a >> valid point. > > It's like saying "OK, the house is on fire, but I really like the > wallpaper, so we should just stay in the building"... > >> What would you suggest? Can the VDB be fixed in another way to avoid >> such rebuilds? > > There are ways of doing it, if you're prepared to make ebuild authors > put in an awful lot of work for very little gain. But it shouldn't be a > priority, and we need to fix existing breakages before doing something > ambitious like that. > I agree. After all, we have *-bin packages for stuff like libreoffice, pypy, firefox etc anyway if rebuilding is really a problem for someone. That said, it might maybe even make more sense to provide an official binhost, although that is probably not less ambitious as fixing VDB on the fly. 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.
Re: [gentoo-dev] don't rely on dynamic deps
On Fri, 25 Jul 2014 15:23:58 + hasufell wrote: > > That's not really helpful advice: dynamic dependencies can't be > > fixed. Instead, you should say that anyone who thinks they have an > > idea on how to fix dynamic deps should think about it until they > > understand why it's wrong... > > I was rather talking about the "fix useless rebuilds" issue. It's a > valid point. It's like saying "OK, the house is on fire, but I really like the wallpaper, so we should just stay in the building"... > What would you suggest? Can the VDB be fixed in another way to avoid > such rebuilds? There are ways of doing it, if you're prepared to make ebuild authors put in an awful lot of work for very little gain. But it shouldn't be a priority, and we need to fix existing breakages before doing something ambitious like that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
Ciaran McCreesh: > On Fri, 25 Jul 2014 15:09:55 + > hasufell wrote: >> Everyone else who thinks got an idea on how to fix dynamic deps >> support (or similar) should: >> * write a PMS patch and get it merged >> * join the portage team and volunteer to implement it instead of >> yelling at them > > That's not really helpful advice: dynamic dependencies can't be fixed. > Instead, you should say that anyone who thinks they have an idea on how > to fix dynamic deps should think about it until they understand why > it's wrong... > I was rather talking about the "fix useless rebuilds" issue. It's a valid point. What would you suggest? Can the VDB be fixed in another way to avoid such rebuilds?
Re: [gentoo-dev] don't rely on dynamic deps
On Fri, 25 Jul 2014 15:09:55 + hasufell wrote: > Everyone else who thinks got an idea on how to fix dynamic deps > support (or similar) should: > * write a PMS patch and get it merged > * join the portage team and volunteer to implement it instead of > yelling at them That's not really helpful advice: dynamic dependencies can't be fixed. Instead, you should say that anyone who thinks they have an idea on how to fix dynamic deps should think about it until they understand why it's wrong... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
Ian Stakenvicius:
> Dynamic deps are the best solution outside of the (rather limited)
> profiles/updates functions we have right now to allow us to make
> whatever non-files-on-${ROOT} changes we need to make to the vdb. So
> realistically what we should be doing is either trying to work out a
> better solution to dynamic deps (something that will failover nicely
> for PMs that don't support dynamic deps) or perhaps adding more
> functions to support VDB updating via profiles/updates/
>
> Am I off-base here? Thoughts?
>
>
Yes, as was already explained. Those are currently just dreams or
abstract thoughts.
Dynamics deps are already broken, not consistently enabled (e.g. when
subslots are in use), optional and not defined in PMS.
People really don't seem to understand what is going on here. We rely on
behavior that depends not only on a portage specific feature, but also
on the context and can pretty much be considered undefined.
I guess I have to repost
https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies
Dynamic deps don't work for you, even if you think that. Coming up with
an alternative approach will probably take a lot of effort and shouldn't
be considered a blocker to fix a fundamental bug in dependency
calculation, which is already broken in portage in many ways.
If we already bikeshed about one of the simplest ways to improve
dependency calculation, I wonder what will happen if someone wants to
actually fix it.
Everyone else who thinks got an idea on how to fix dynamic deps support
(or similar) should:
* write a PMS patch and get it merged
* join the portage team and volunteer to implement it instead of yelling
at them
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/07/14 10:44 AM, Ian Stakenvicius wrote:
> On 22/07/14 06:44 PM, Tom Wijsman wrote:
>> On Tue, 22 Jul 2014 09:53:49 -0400 Ian Stakenvicius
>> wrote:
>
>>> Using ${PVR} to detect how portage should update things would
>>> be asking for trouble, imo.
>
>> This entire sub thread reads like a dynamic dependencies
>> alternative in disguise, the difference lies in an increase of
>> the level of control and in the place where this then gets
>> reimplemented.
>
>
> It is.
>
> Here's the situation as I see it -- the portage tree needs to be
> consistent at snapshot time. But things can change all over the
> place, deps are moved, virtuals replace single or groups of atoms,
> packages get split, etc. etc. etc.
>
> Dynamic deps are the best solution outside of the (rather limited)
> profiles/updates functions we have right now to allow us to make
> whatever non-files-on-${ROOT} changes we need to make to the vdb.
> So realistically what we should be doing is either trying to work
> out a better solution to dynamic deps (something that will failover
> nicely for PMs that don't support dynamic deps) or perhaps adding
> more functions to support VDB updating via profiles/updates/
>
> Am I off-base here? Thoughts?
>
Ignore this, i should've read the rest of the thread first before posting.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPScN4ACgkQ2ugaI38ACPBS5gD+MXU3VUvwhp1u/0wIDHeXEQdX
TmJXhvDhuhuE+7ehee0A/1HGASXipYsejfJxPesQFO4Egs1Yzj20PXlVmil9H8FY
=WwNJ
-END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
On Thu, 24 Jul 2014 21:45:58 -0400 Rich Freeman wrote: > Just a general comment not aimed at this particular part of the thread > - a solution doesn't have to be perfect to be useful. 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" that nothing is actually correct any more. It's one thing to get away with this occasionally, but quite another to build an entire system upon it. We can't afford more mistakes, and we have to actively fix existing ones. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] USE="gudev introspection" removal from virtual/udev tomorrow'ish
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/07/14 05:38 AM, Samuli Suominen wrote:
>
> On 25/07/14 11:07, Daniel Campbell wrote:
>> On 07/24/2014 02:22 PM, Samuli Suominen wrote:
>>> gentoo-x86 has been converted to use virtual/libgudev. big
>>> thanks to _AxS_ who helped me to get it finally done.
>>>
>>> that means we will be removing compability USE flags "gudev
>>> introspection" from virtual/udev tomorrow'ish (only waiting for
>>> gnome-overlay folks)
>>>
>>> run this in your overlay:
>>>
>>> $ grep virtual.*udev.*gudev */*/*.ebuild
>>>
>>> and convert them to EAPI=5 syntax virtual/libgudev:= but don't
>>> do it without making sure you don't need virtual/libudev:= or
>>> virtual/udev (like for udevd, udev.pc for udevdir value) as
>>> well
>>>
>>> the Tracker is:
>>> http://bugs.gentoo.org/showdependencytree.cgi?id=506034&hide_resolved=1
>>>
>>
>>>
What does this mean for users of, say, eudev that needed those flags for
>> certain things (but don't have GNOME installed)? Will it just be
>> a removed entry from package.use and a rebuild? I'm on stable so
>> it'll take a little bit to reach me, but I figured I'd ask on
>> behalf of any other concerned users.
>>
>
> Short answer:
>
> No impact.
>
To make this a little more verbose, sys-fs/{udev,systemd,eudev}
themselves still have those flags in their ebuilds. It's just the way
dependency atoms on virtuals that have changed, in terms of how they
map say, a need for a USE="introspection"-enabled libgudev to
sys-fs/eudev[gudev,introspection].
The functionality isn't gone, it's just referenced differently now.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPScL0ACgkQ2ugaI38ACPCq2wD+Mjtjsm9VPUyHzue1BhBNKYj9
zLmbq48LKfmkjjfBb6cBAJXhvs6EqydtH70hYwRDx7KwWFgHhPY0ibDRK8LxWcrx
=6ySf
-END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/07/14 06:44 PM, Tom Wijsman wrote:
> On Tue, 22 Jul 2014 09:53:49 -0400 Ian Stakenvicius
> wrote:
>
>> Using ${PVR} to detect how portage should update things would be
>> asking for trouble, imo.
>
> This entire sub thread reads like a dynamic dependencies
> alternative in disguise, the difference lies in an increase of the
> level of control and in the place where this then gets
> reimplemented.
It is.
Here's the situation as I see it -- the portage tree needs to be
consistent at snapshot time. But things can change all over the
place, deps are moved, virtuals replace single or groups of atoms,
packages get split, etc. etc. etc.
Dynamic deps are the best solution outside of the (rather limited)
profiles/updates functions we have right now to allow us to make
whatever non-files-on-${ROOT} changes we need to make to the vdb. So
realistically what we should be doing is either trying to work out a
better solution to dynamic deps (something that will failover nicely
for PMs that don't support dynamic deps) or perhaps adding more
functions to support VDB updating via profiles/updates/
Am I off-base here? Thoughts?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPSbVgACgkQ2ugaI38ACPBDpAEAnqx8hBGkmmiVGE6Pz7Rh+BE9
ed5KuWwihJdjPGjXdjoA/ifwGD8oUO8epWIq4rahW+egUFhklKtPu57jIYSjY90y
=cZb0
-END PGP SIGNATURE-
Re: [gentoo-dev] USE="gudev introspection" removal from virtual/udev tomorrow'ish
On 25/07/14 11:07, Daniel Campbell wrote: > On 07/24/2014 02:22 PM, Samuli Suominen wrote: >> gentoo-x86 has been converted to use virtual/libgudev. big thanks to >> _AxS_ who helped me to >> get it finally done. >> >> that means we will be removing compability USE flags "gudev >> introspection" from virtual/udev >> tomorrow'ish (only waiting for gnome-overlay folks) >> >> run this in your overlay: >> >> $ grep virtual.*udev.*gudev */*/*.ebuild >> >> and convert them to EAPI=5 syntax virtual/libgudev:= but don't do it >> without making sure you don't >> need virtual/libudev:= or virtual/udev (like for udevd, udev.pc for >> udevdir value) as well >> >> the Tracker is: >> http://bugs.gentoo.org/showdependencytree.cgi?id=506034&hide_resolved=1 >> > What does this mean for users of, say, eudev that needed those flags for > certain things (but don't have GNOME installed)? Will it just be a > removed entry from package.use and a rebuild? I'm on stable so it'll > take a little bit to reach me, but I figured I'd ask on behalf of any > other concerned users. > Short answer: No impact. In case of problems: If some package (installed from Portage) is complaining about missing USE flags "gudev" or "introspection" for virtual/udev, it means you need to recompile the package complaining, so the Portage's VDB will get the updated ebuild with the new virtual/libgudev dependency from actual Portage tree OR If some package (installed from overlay) is complaining about missing USE flags "gudev" or "introspection", you should propably try updating the overlay, if that doesn't help, contact the overlay maintainer, possible uninstall the overlay or fix it yourself I hope that answered your question - Samuli
Re: [gentoo-dev] don't rely on dynamic deps
El mié, 23-07-2014 a las 14:33 +0100, Ciaran McCreesh escribió: > 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) > > > > But I am not sure if it could be viable from a "technical" point of > > view :( > > This in no way solves the problem. Consider the following course of > events: > > User installs foo-1.1-r1 > Developer makes foo-1.1-r1.1 > foo-1.1* is removed from the tree > User syncs > 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?
Re: [gentoo-dev] don't rely on dynamic deps
El vie, 25-07-2014 a las 00:06 +0200, Michał Górny escribió: [...] > > 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) > > > > But I am not sure if it could be viable from a "technical" point of > > view :( > > 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. > But, isn't it something up to developer in that case? I mean, we should have a list of things that deserve that VDB regeneration and, then, make the -r1.1 revbump instead of the major one.
[gentoo-dev] Re: don't rely on dynamic deps
Rich Freeman posted on Tue, 22 Jul 2014 21:15:01 -0400 as excerpted: > 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). Portage already allows you to clean a > package without its reverse deps leading to a system in exactly the > state you describe. I believe portage will just try to bring the > package back at the next emerge @world (or any other set containing the > reverse dep). FWIW I tested this with a number of packages just the other day while doing an initial test-build of qt:5 and kde:5 from the relevant overlays. Various kde-workspace5/plasma5 packages can't coexist with the kde:4 versions, but I didn't want to remove the kde:4 revdeps or set- elements from my installed sets until I was sure the kde:5 versions worked fine. Apparently the kwin:5 version I was testing doesn't like my radeon turks (hd6670 IIRC) hardware their current v3.16-pre kernel drm drivers as once I had the whole setup installed and tried to startx with it, kwin ended up in a segfault/respawn cycle, so my surgical unmerge of specific kde:4 packages was just as well, making it relatively easy to simply emerge -k @world and get back to a working system from the binpkgs, automatically unmerging the kde:5 blockers on the way since I hadn't actually let portage put them in @world just yet. Yes, a simple emerge --deep @world pulls everything missing but needed back in, so that bit of portage at least seems to be working just fine. -- 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] don't rely on dynamic deps
El mar, 22-07-2014 a las 23:56 +0200, Tom Wijsman escribió: [...] > Useless triggers are the problem; why are the rev bumps needed, why are > dependencies forgotten, ...? Sounds like a developer work flow issue... > > https://bugs.gentoo.org/show_bug.cgi?id=499852 > There are lots of cases of upstream forgetting to update configure checks and changing without noticing the real requirements. For example, moving from gtk+-2.90.0 to gtk+-3.3. Since we don't such old setups, we don't notice a newer gtk+ is needed. Sometimes, a user with a really old stable setup tries to update, find the problem and we need to update the dependency
Re: [gentoo-dev] USE="gudev introspection" removal from virtual/udev tomorrow'ish
On 07/24/2014 02:22 PM, Samuli Suominen wrote: > gentoo-x86 has been converted to use virtual/libgudev. big thanks to > _AxS_ who helped me to > get it finally done. > > that means we will be removing compability USE flags "gudev > introspection" from virtual/udev > tomorrow'ish (only waiting for gnome-overlay folks) > > run this in your overlay: > > $ grep virtual.*udev.*gudev */*/*.ebuild > > and convert them to EAPI=5 syntax virtual/libgudev:= but don't do it > without making sure you don't > need virtual/libudev:= or virtual/udev (like for udevd, udev.pc for > udevdir value) as well > > the Tracker is: > http://bugs.gentoo.org/showdependencytree.cgi?id=506034&hide_resolved=1 > What does this mean for users of, say, eudev that needed those flags for certain things (but don't have GNOME installed)? Will it just be a removed entry from package.use and a rebuild? I'm on stable so it'll take a little bit to reach me, but I figured I'd ask on behalf of any other concerned users. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] don't rely on dynamic deps
Dnia 2014-07-21, o godz. 21:34:10 Alexandre Rostovtsev napisał(a): > On Mon, 2014-07-21 at 22:56 +0200, Michał Górny wrote: > > Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps > > are a pipe dream. You can't implement them properly, so we're using > > half-working implementation as an excuse to be lazy. > > Why not adapt the updates mechanism for modifying rdepends? Perhaps > something like > > rdepends-add foo-bar/blah-3.14 "wombat? ( >=dev-libs/wombat-1.0 )" > > This would give the package manager all the benefits of static dep > resolution while allowing us to dynamically make simple changes (like > adding a missing dependency to an ebuild) without forcing users to > rebuild the package. At the moment updates are stateless. In other words, PM has no idea if the update has been applied or not, and the update should be defined so that it can't be applied multiple times. IOW, if you do a pkgmove via updates, the originating package ebuild must no longer exist so that the update can be only applied once. If you do a slotmove, the originating slot must no longer be used in affected ebuilds. Now, with dependency updates you lack this guarantee. Package manager can add the dependency... and then add it again... and again... and again. It could supposedly try to match dependencies and find out whether a particular dependency has been added already but that sounds like something that could easily cause issues in the future. -- Best regards, Michał Górny signature.asc Description: PGP signature
