Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
On Thu, 13 Sep 2012, Mike Frysinger wrote:
Maybe it's better to add a --{save,restore} option pair:
addwrite --save /foo/bar
# some commands writing to /foo/bar here
addwrite --restore # restore last saved state
or --{push,pop} to allow for nested calls, but maybe that would be
overkill.
not sure how your --save/--restore isn't a --push/--pop already
--save/--restore would keep one saved state (which would be
overwritten with the next --save), whereas --push/--pop would maintain
a stack.
Ulrich
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
On Thu, Sep 13, 2012 at 2:22 AM, Ulrich Mueller wrote:
On Thu, 13 Sep 2012, Mike Frysinger wrote:
Maybe it's better to add a --{save,restore} option pair:
addwrite --save /foo/bar
# some commands writing to /foo/bar here
addwrite --restore # restore last saved state
or --{push,pop} to allow for nested calls, but maybe that would be
overkill.
not sure how your --save/--restore isn't a --push/--pop already
--save/--restore would keep one saved state (which would be
overwritten with the next --save), whereas --push/--pop would maintain
a stack.
that wouldn't really be any different than if you implement the -r
option like so:
- `addwrite /foo` would always append the path regardless of
existence already in the variable
- `addwrite -r /foo` would remove exactly 1 occurence
so if you don't want to do push/pop, let's stick with just adding a -r
flag and implementing things as described above as it makes dev's
lives simpler.
-mike
Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed
El mié, 12-09-2012 a las 18:30 -0400, Sean Amoss escribió: On 09/12/2012 02:54 PM, Pacho Ramos wrote: El jue, 13-09-2012 a las 04:30 +1000, Michael Palimaka escribió: On 2012-09-13 03:59, Pacho Ramos wrote: Hello Currently, package maintainers are CCed to security bugs when their are needed. The problem is that, once maintainers add a fixed version and tell security team they are ok to get it stabilized, maintainers are kept CCed until bug is closed by security team. This usually means getting a lot of mail after some time when security team discuss if a GLSA should be filled or not, if security bot adds some comment... some of that comments are applied to really old bugs that need no action from maintainers. Our discussion is very minimal. There will typically never be any more than 3 comments discussing whether to have a GLSA or not -- in the event that 2 security team members disagree and a 3rd has to break the tie. Some bugs have been receiving more spam than usual (lately, from GLSAMaker/CVETool bot) as we have been trying to clean-up old CVE entries in the tool and old bugs. It would be nice if maintainers would follow-up on security bugs in [upstream], [ebuild], [stable], and [cleanup] to get those bugs closed as soon as possible. You are welcome to join the security team to help us keep bugs up-to-date and work on the backlog of GLSAs. :D Maybe would be interesting to change the policy to unCC maintainers again when their action is no longer required. What do you think? Thanks for your thoughts Hello, Is the policy you describe officially documented, or just current behaviour? I don't know, at least it's the current behavior, but I don't know if it's a policy :/ Yes, this is part of the Vulnerability Treatment Policy [1], listed under the Security Bug Wrangler role in Chapter 3. In KDE and Qt herds for example, we usually just unCC ourselves when we've taken the required action. Best regards, Michael The security bug process [2] involves removing the vulnerable versions from the tree after all arches are finished stabilizing. This is to ensure that users do not accidentally install vulnerable software. Many maintainers do not do this and I think that all of us on the security team are guilty of not always following up to ensure the vulnerable versions are dropped. As Jeroen mentioned, how will maintainers know when to remove the vulnerable versions if they are not current on the bug? If stabilization is complete and the maintainers have removed vulnerable versions from the tree, there is typically no issue with unCC'ing themselves like KDE/Qt herds do. Arches sometimes run into minor issues that don't warrant opening a new bug - they should be able to get help from maintainers without re-CC'ing them. If a decision were made to unCC maintainers, there would probably be some maintainers/herds that want to be left on the CC list and the security team does not have the capacity right now to keep up with exceptions. (Strictly my opinions, not that of the whole security team) [1] http://www.gentoo.org/security/en/vulnerability-policy.xml#doc_chap3 [2] http://www.gentoo.org/security/en/coordinator_guide.xml#doc_chap3 OK, then, looks like the policy could be that, once all arches are done, maintainers cleanup ebuilds and unCC themselves, that way, if they are still getting mails from bug report is because they forgot to remove vulnerable versions and, if not, is because all their work was finished. Are you ok with this policy? Thanks :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed
El mié, 12-09-2012 a las 18:30 -0400, Sean Amoss escribió: On 09/12/2012 02:54 PM, Pacho Ramos wrote: El jue, 13-09-2012 a las 04:30 +1000, Michael Palimaka escribió: On 2012-09-13 03:59, Pacho Ramos wrote: Hello Currently, package maintainers are CCed to security bugs when their are needed. The problem is that, once maintainers add a fixed version and tell security team they are ok to get it stabilized, maintainers are kept CCed until bug is closed by security team. This usually means getting a lot of mail after some time when security team discuss if a GLSA should be filled or not, if security bot adds some comment... some of that comments are applied to really old bugs that need no action from maintainers. Our discussion is very minimal. There will typically never be any more than 3 comments discussing whether to have a GLSA or not -- in the event that 2 security team members disagree and a 3rd has to break the tie. Some bugs have been receiving more spam than usual (lately, from GLSAMaker/CVETool bot) as we have been trying to clean-up old CVE entries in the tool and old bugs. It would be nice if maintainers would follow-up on security bugs in [upstream], [ebuild], [stable], and [cleanup] to get those bugs closed as soon as possible. You are welcome to join the security team to help us keep bugs up-to-date and work on the backlog of GLSAs. :D Maybe would be interesting to change the policy to unCC maintainers again when their action is no longer required. What do you think? Thanks for your thoughts Hello, Is the policy you describe officially documented, or just current behaviour? I don't know, at least it's the current behavior, but I don't know if it's a policy :/ Yes, this is part of the Vulnerability Treatment Policy [1], listed under the Security Bug Wrangler role in Chapter 3. In KDE and Qt herds for example, we usually just unCC ourselves when we've taken the required action. Best regards, Michael The security bug process [2] involves removing the vulnerable versions from the tree after all arches are finished stabilizing. This is to ensure that users do not accidentally install vulnerable software. Many maintainers do not do this and I think that all of us on the security team are guilty of not always following up to ensure the vulnerable versions are dropped. As Jeroen mentioned, how will maintainers know when to remove the vulnerable versions if they are not current on the bug? If stabilization is complete and the maintainers have removed vulnerable versions from the tree, there is typically no issue with unCC'ing themselves like KDE/Qt herds do. Arches sometimes run into minor issues that don't warrant opening a new bug - they should be able to get help from maintainers without re-CC'ing them. If a decision were made to unCC maintainers, there would probably be some maintainers/herds that want to be left on the CC list and the security team does not have the capacity right now to keep up with exceptions. (Strictly my opinions, not that of the whole security team) [1] http://www.gentoo.org/security/en/vulnerability-policy.xml#doc_chap3 [2] http://www.gentoo.org/security/en/coordinator_guide.xml#doc_chap3 Regarding joining to security team, I have considered a lot of time that option... but I clearly don't have enough time this days :|, sorry signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed
El jue, 13-09-2012 a las 03:43 +0200, Jeroen Roovers escribió: On Wed, 12 Sep 2012 20:53:20 +0200 Pacho Ramos pa...@gentoo.org wrote: You can un-CC yourself. I don't see why security@ should be doing the legwork. It shouldn't be so hard to do, they can do it just when they CC arches, instead of relaying some random team member to do it himself once a useless message is received It does become a chore when you have to check a list to match various CC'd people's preferences and decide whether to un-CC them based on that, the way they were CC'd (did they do it themselves, were they CC'd by security, and so on) and perhaps some other factors someone will no doubt soon propose in this thread. Basically you are saying, why doesn't anyone else do my volunteer work for me. jer I am not saying that, you can see who CCed them in history and most of times was security team who CCed them... anyway, per my just replied mail to Sean, I think we could reach a good compromise. What I don't understand is why you think I am trying to say that thing when I ever wasn't sure if maintainers were allowed to unCC themselves when they think signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] app-emulation/qemu app-emulation/qemu-kvm folding into one package
10.09.2012 05:55, Doug Goldstein wrote: Hey all, Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to app-emulation/qemu at some point this week. The app-emulation/qemu ebuilds will effectively die and be replaced by the app-emulation/qemu-kvm ebuilds. I've brought this up before and there was a bunch of rabble about keep our pristine qemu ebuilds!!!. The fact of the matter is that the app-emulation/qemu just isn't getting the same maintenance care that app-emulation/qemu-kvm is. I've really only got the bandwidth to handle one at a time. Additionally this will bring us inline with a few other distros use of qemu as they're really building their binaries from qemu-kvm. For those that want pure qemu builds, I recommend creating an overlay and replacing the URL. The ebuilds will otherwise aim to be 100% compatible. It seems that qemu-kvm will be merged into main qemu source tree(i have heard that fact... do not really remember where :-D), so your decision maybe concerned as preparations for this merge. I am strongly agreed with it.
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
On 13 September 2012 06:48, Ulrich Mueller u...@gentoo.org wrote:
On Thu, 13 Sep 2012, Brian Harring wrote:
For SANDBOX_*, while that's a PM internal, that's a bit of a grey
zone; regardless, we can actually address that via extending the
sandbox functions a bit:
addwrite [-r|--remove] pathway # for example, to do a removal.
It's nice to be able to do
local SANDBOX_WRITE=${SANDBOX_WRITE}
and then allow bash to restore the old value at the end of the
function, regardless of how it exits. It's not the end of the world
to lose this, but it would be a bit of a shame IMHO - having to do it
manually seems a little error-prone.
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless the command and args
To start the bikeshedding: For some reason I associate less (the
pager) in a sandbox with this. ;-) Maybe nosandbox or sandboxoff?
sansbox? *flees*
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
On Thu, 13 Sep 2012, David Leverton wrote:
It's nice to be able to do
local SANDBOX_WRITE=${SANDBOX_WRITE}
and then allow bash to restore the old value at the end of the
function, regardless of how it exits. It's not the end of the world
to lose this, but it would be a bit of a shame IMHO - having to do it
manually seems a little error-prone.
Maybe we should just document the SANDBOX_* variables? Looks like the
easiest solution to me.
The problem with adding an option to addwrite is that eclasses would
have to stick with the existing solution, or add a pointless case
distinction. Otherwise it won't work for all EAPIs.
Ulrich
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
On Thu, Sep 13, 2012 at 01:53:21AM -0400, Mike Frysinger wrote:
On Wed, Sep 12, 2012 at 4:36 PM, Brian Harring wrote:
Currently, there is a minor amount of ebuild/eclass usage of things
named __*; ~90% of it is 'import once' eclass code like the following:
if [[ ${___ECLASS_ONCE_LIBTOOL} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_LIBTOOL=recur -_+^+_- spank
Converting that is easy enough, and I'll be doing that work for
gentoo-x86 if folks don't have an issue.
pick a funner prefix and i approve
_LIBTOOL_ECLASS_GOT_SPANKED_ALREADY
Either that or one could just inject futurama quotes:
_LIBTOOL_ECLASS_DOESNT_WANT_TO_LIVE_ON_THIS_PLANET_ANYMORE
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless the command and args
fine idea
withoutsandbox. ;)
Joke aside, 'nosandbox' is more consistent; also, there's basically
one usage in the tree (virtualx) that would need it, although the
level of ebuild usage for that, I do not know- donnie might, that was
his code originally iirc.
~harring
[gentoo-dev] USE_EXPAND / USE 'configuration space' refactoring.
Hola.
CC'ing pms since obviously they should comment, although the
discussion should be on -dev (aka, public, not an alias).
Sorry, this is a long email; condensing it down into a glep is viable,
just my time is limited (it's telling I started the gentoo stuff at
2am, wrapping up likely at 4am).
The length of this email basically relates to the subtlety of this
proposal; at first glance it may appear as if I'm proposing a syntax
shuffle just for aesthetic reasons, but as elaborated in the tail end,
that subtle syntax change opens up a lot of possibilities.
Either way, what I propose, is pretty simple. Currently USE_EXPAND'd
groups are pushed into USE in the form ${use_group}_${setting}.
Thus VIDEO_CARDS=intel nvidia becomes video_cards_intel
video_cards_nvidia. This should be reasonably well known and
understood from the dev standpoint; from the PM side of things, this
actually seriously sucks ass; if we see video_cards_intel in an IUSE
somewhere, we don't know if it's a USE flag, or a use_expanded group;
to figure that out, we basically have to do a longest prefix matching
(or suffix tree).
There in is one of the subtle design flaws of it; two USE_EXPAND'd
targets, VIDEO_CARDS and VIDEO, can intersect in their namespace.
While we (devs) intentionally avoid this potential via careful name
choice, the fact the possibility exists is a bit of a sign that
USE_EXPAND was a bit of a hack.
What I propose is simple enough, and is for =EAPI5:
1) We disallow '@' in USE flags (yes, a use flag can actually have
'@' in it's name according to PMS; someone was hitting the crack
pipe pretty damn hard when they allowed that one). This doesn't
impact anything in gentoo-x86, nor any tree I've ever seen.
2) If EAPI5, we continue exporting video_cards_nvidia
(${use_group}_${setting}).
3) If =EAPI5, we export ${use_group}_${setting}, *and*
${use_group}@${setting}. While there may be complaints about having
it exported in two fashions, the reason for this is simple- it makaes
transition way the fuck easier, meaning we don't make devs wrie pain
in the ass if eapi x, else blah code. Basically, for eclass code,
the dev would do thus:
3.a) If the eclass supports EAPI5, they check for the old form;
${use_group}_${setting}.
3.b) If however that eclass is =EAPI5, they should check for the new
form; ${use_group}@{setting}.
4) At some point in the future, when either code involved has migrated
all to EAPI5, or we do something in a later EAPI that renders
supporting ${use_group}_${setting} untenuable, we stop exporting
${use_group}_${setting} for those EAPIs. Preferably with one EAPI
cycle w/ deprecation warnings.
Basically, this approach is zero impact for devs for the most part;
you don't have to do multiple paths for checking use wise if
supporting EAPI5 in parallel to others. Once your code is EAPI5 (and
above), you use the new syntax- or worst case, someone interested goes
and converts your =EAPI5 ebuild/eclass to use the new syntax on your
behalf.
Thus far, I've not particularly sold this notion in this email- I
focused on making damn clear this cleanup is basically no cost for
everyone but PM authors (and it's easy enough for us to handle).
Aside from the cleanup/sanity improvements to our algos for
backmatching USE_EXPAND groups, this syntax gets us actually some
rathre nifty shit; it basically allows us to introduce a generation
configuration space.
So... onto examples of why we should do this beyond the basic it's a
cleaner syntax/design argument:
--Per phase RESTRICT usage--
Exactly as it sounds. Consider userpriv- most of the time that's
turned off, that's purely because one phase- literally just one
phase- needs to do something via root. Thus we weaken the entirety
of the protection. Now, we could do some bastardly shit w/ existing
use_expand for this (which has some conflict potentials for the PM),
or via this syntax, we could do:
RESTRICT=phase@src_install? ( userpriv )
Now, not all restricts are phase level- fetch, strip, installsources,
etc, operate on a global level. userpriv, usersandbox, sandbox
(latter two aren't used in gentoo-x86, although PM's support it still)
are phase specific. That may seem like a small list, but consider
that
1) pkgcore has fakeroot code; it's had it for a while, I'm intending
on resurrecting that; this requires a RESTRICT='fakeroot' however.
2) I intend to start abusing the 'unshare' utility (man 1 unshare) to
contain ebuilds build process; basically gives us a way to level some
protections for the build host. I'd be very surprised if other PM's
don't follow suit (or do it before I do even); it's a simple
protection that's worth doing.
3) There's been repeated talk of using containers/overlays to
constrain the build process; sooner or later someones going to do it,
and you can be damn sure a restrict will be necessary.
Etc, you get the idea; the point of the new syntax is general
flexibility and
Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed
On 12.09.2012 19:59, Pacho Ramos wrote: Hello Currently, package maintainers are CCed to security bugs when their are needed. The problem is that, once maintainers add a fixed version and tell security team they are ok to get it stabilized, maintainers are kept CCed until bug is closed by security team. This usually means getting a lot of mail after some time when security team discuss if a GLSA should be filled or not, if security bot adds some comment... some of that comments are applied to really old bugs that need no action from maintainers. Maybe would be interesting to change the policy to unCC maintainers again when their action is no longer required. What do you think? Sorta OT but a general thing: I think you should CC teams you want to talk to and not only use the gentoo-systemd-flamewars^W^W-dev mailing list where these teams might only find your post by chance. Thanks for your thoughts -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE_EXPAND / USE 'configuration space' refactoring.
On Thu, 2012-09-13 at 03:39 -0700, Brian Harring wrote:
Hola.
CC'ing pms since obviously they should comment, although the
discussion should be on -dev (aka, public, not an alias).
Sorry, this is a long email; condensing it down into a glep is viable,
just my time is limited (it's telling I started the gentoo stuff at
2am, wrapping up likely at 4am).
The length of this email basically relates to the subtlety of this
proposal; at first glance it may appear as if I'm proposing a syntax
shuffle just for aesthetic reasons, but as elaborated in the tail end,
that subtle syntax change opens up a lot of possibilities.
Either way, what I propose, is pretty simple. Currently USE_EXPAND'd
groups are pushed into USE in the form ${use_group}_${setting}.
Thus VIDEO_CARDS=intel nvidia becomes video_cards_intel
video_cards_nvidia. This should be reasonably well known and
understood from the dev standpoint; from the PM side of things, this
actually seriously sucks ass; if we see video_cards_intel in an IUSE
somewhere, we don't know if it's a USE flag, or a use_expanded group;
to figure that out, we basically have to do a longest prefix matching
(or suffix tree).
There in is one of the subtle design flaws of it; two USE_EXPAND'd
targets, VIDEO_CARDS and VIDEO, can intersect in their namespace.
While we (devs) intentionally avoid this potential via careful name
choice, the fact the possibility exists is a bit of a sign that
USE_EXPAND was a bit of a hack.
What I propose is simple enough, and is for =EAPI5:
1) We disallow '@' in USE flags (yes, a use flag can actually have
'@' in it's name according to PMS; someone was hitting the crack
pipe pretty damn hard when they allowed that one). This doesn't
impact anything in gentoo-x86, nor any tree I've ever seen.
2) If EAPI5, we continue exporting video_cards_nvidia
(${use_group}_${setting}).
3) If =EAPI5, we export ${use_group}_${setting}, *and*
${use_group}@${setting}. While there may be complaints about having
it exported in two fashions, the reason for this is simple- it makaes
transition way the fuck easier, meaning we don't make devs wrie pain
in the ass if eapi x, else blah code. Basically, for eclass code,
the dev would do thus:
3.a) If the eclass supports EAPI5, they check for the old form;
${use_group}_${setting}.
3.b) If however that eclass is =EAPI5, they should check for the new
form; ${use_group}@{setting}.
4) At some point in the future, when either code involved has migrated
all to EAPI5, or we do something in a later EAPI that renders
supporting ${use_group}_${setting} untenuable, we stop exporting
${use_group}_${setting} for those EAPIs. Preferably with one EAPI
cycle w/ deprecation warnings.
...
~harring
+1
This would make things easier for PM consumer apps to process use flags
without specialized code to figure out if the flag was use_expanded or
just had an _ in it's name...
--
Brian Dolbec dol...@gentoo.org
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] USE_EXPAND / USE 'configuration space' refactoring: bikeshedding the separator
On Thu, 13 Sep 2012 03:39:19 -0700 Brian Harring ferri...@gmail.com wrote: 1) We disallow '@' in USE flags (yes, a use flag can actually have '@' in it's name according to PMS; someone was hitting the crack pipe pretty damn hard when they allowed that one). This doesn't impact anything in gentoo-x86, nor any tree I've ever seen. No crack pipe was involved in that decision! It's because of LINGUAS. (Incidentally, we used : rather than @ for separation for exheres-0 for that reason.) -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Lastrites for qt4.eclass
Since the last ebuild using the old qt4.eclass has now been removed from the tree, the Qt team wishes to lastrite this eclass. It will be removed in 30 days. All ebuilds should be using qt4-r2.eclass instead. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
On Thu, Sep 13, 2012 at 4:32 AM, Ulrich Mueller wrote:
On Thu, 13 Sep 2012, David Leverton wrote:
It's nice to be able to do
local SANDBOX_WRITE=${SANDBOX_WRITE}
and then allow bash to restore the old value at the end of the
function, regardless of how it exits. It's not the end of the world
to lose this, but it would be a bit of a shame IMHO - having to do it
manually seems a little error-prone.
Maybe we should just document the SANDBOX_* variables? Looks like the
easiest solution to me.
The problem with adding an option to addwrite is that eclasses would
have to stick with the existing solution, or add a pointless case
distinction. Otherwise it won't work for all EAPIs.
well, if you want to focus on the $now, then you're mostly correct.
however, as we've done in the past, it's generally pretty easy to
implement functionality in say eutils.eclass so that other places
don't have to worry about different EAPI code paths. then in the
$future, there is only the code provided by EAPI.
-mike
Re: [gentoo-dev] USE_EXPAND / USE 'configuration space' refactoring: bikeshedding the separator
On Thu, Sep 13, 2012 at 04:24:27PM +0100, Ciaran McCreesh wrote:
On Thu, 13 Sep 2012 03:39:19 -0700
Brian Harring ferri...@gmail.com wrote:
1) We disallow '@' in USE flags (yes, a use flag can actually have
'@' in it's name according to PMS; someone was hitting the crack
pipe pretty damn hard when they allowed that one). This doesn't
impact anything in gentoo-x86, nor any tree I've ever seen.
No crack pipe was involved in that decision! It's because of LINGUAS.
(Incidentally, we used : rather than @ for separation for exheres-0 for
that reason.)
Who says Linguas definition didn't involve a bit 'o crack? ;) On that
subject, not entirely sure how the hell a grepp'ing of profiles on my
part missed that file; worse, I distinctly recall this coming up in
the past. Suspect it's time we add a footnote to that section of
names since it's non-obvious. Sigh...
Two angles;
1) Mind you, the woken up/caffeine ratio currently blows so this
could be quite off kilter- but at first glance the '@' linguas usage
actually seems to map to sub use groups (both in intent and
grouping), at least for the quick scan I did of what we use. Might
not actually be an issue, iow if we allow that, although that's
assuming the '@' subgroup approach translates reasonably cleanly.
The potential failure I'd see with that approach is it's a bit reliant
on the assumption that the rules:
`language[_territory[.codeset]][@modifier]`
have been abided by- that the modifier is just that, a modifier.
Were we to do this, which, at least at first sight, seems like a nifty
solution that addresses it, we'd *likely* want sub groups to have a
rule such that if you try to expand the subgroup of a setting, and
that setting isn't a subgroup, it is considered 'on'. Basically, for
the linguas case, it kind of sucks if we get into the situation where
the consuming ebuilds/eclasses has to be sensitive to which modifiers
were exposed. Essentially:
linguas@de_DE@, if not a subgroup to expand to, is treated as scalar,
rather than list. Impliciations of that I've not yet fully thought
out- note that tweak isn't necessary for the basic notion of #1 to be
usable also.
2) bikeshedding potentials: just spitballing a couple of potentials
if '@' subgroups there doesn't fly for folks reading (mean it nicely,
we shouldn't diverge arbitarily, but in the same instant we shouldn't
import syntax/notions from exherbo unless they explicitly make sense
in the gentoo/PMS context; the formats diverge enough the reuse for
compatibility argument doesn't hold much water):
ruby_targets@ruby_18
ruby_targets:ruby_18
ruby_targets|ruby_18
ruby_targets(ruby_18)
Potentially fun thought, although the syntax is kind of ugly;
basically we treat 'ruby_target' as a matching target (restriction in
pkgcore vernacular, something that matches something else); the nice
thing about this is it naturally plugins into the notion of multiple
settings:
ruby_targets[ruby18]
ruby_targets[ruby18,ruby19]
In the same angle, while it's partially valid bash (and not in the
single setting case):
ruby_targets{ruby_18}
ruby_targets{ruby_18,ruby_19}
That said, I consider the [] and {} syntax absolutely freaking ugly to
the eye. I mention it should others think it's not butt-fugly.
If approach #1 doesn't fly, using ':' as the delimiter gets my vote.
~harring
Re: [gentoo-dev] Unified DEPENDENCIES concept
On 11 September 2012 14:16, Brian Harring ferri...@gmail.com wrote: On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote: Is there anything in particular in the spec/proposal for DEPENDENCIES that would exclude the addition of individual build: app-cat/myatom run: app-cat/myatom deps by an eclass or eclasses? I know the goal here is to make things atom-centric, but I can't see an implementation ever working of this that wouldn't permit the pile-on of additional entries of different (or even the same) roles on identical or near-identical atoms. They could be piled on; it would require each eclass to reset the label for safety reasons though; same goes for ebuilds frankly (or the PM would have to reset the context to build+run: each time through). Pardon if addressed elsewhere; this thread is a fucking mess... ~harring Correct me if I'm wrong, but couldn't the entire proposition could be implemented in an eclass, not needing the EAPI development cycle to be tied up with it. All you need is something in bash that can parse DEPENDENCIES and populate *DEPEND , and the underlying guts could be done in practically any language without requiring PM specific implementations. [[[ inherit polydep; DEPENDENCIES= Stuff Here. ; ]]] The only thing I know of that is limiting the above from being implemented that way is the lack of post-source eclass hooks, that is: currently you'd have to do either [[[ DEPENDENCIES=... inherit polydep; ]]] or use a callback [[[ inherit polydep; DEPENDENCIES= ... polydeps; ]]] -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed
El jue, 13-09-2012 a las 15:48 +0200, Alex Legler escribió: On 12.09.2012 19:59, Pacho Ramos wrote: Hello Currently, package maintainers are CCed to security bugs when their are needed. The problem is that, once maintainers add a fixed version and tell security team they are ok to get it stabilized, maintainers are kept CCed until bug is closed by security team. This usually means getting a lot of mail after some time when security team discuss if a GLSA should be filled or not, if security bot adds some comment... some of that comments are applied to really old bugs that need no action from maintainers. Maybe would be interesting to change the policy to unCC maintainers again when their action is no longer required. What do you think? Sorta OT but a general thing: I think you should CC teams you want to talk to and not only use the gentoo-systemd-flamewars^W^W-dev mailing list where these teams might only find your post by chance. Thanks for your thoughts I thought all developers were subscribed to gentoo-dev and would read it :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed
On Thu, Sep 13, 2012 at 3:57 PM, Pacho Ramos pa...@gentoo.org wrote: El jue, 13-09-2012 a las 15:48 +0200, Alex Legler escribió: Sorta OT but a general thing: I think you should CC teams you want to talk to and not only use the gentoo-systemd-flamewars^W^W-dev mailing list where these teams might only find your post by chance. I thought all developers were subscribed to gentoo-dev and would read it :| Maybe, maybe not, but this seems like the appropriate place to discuss it. Maybe -project instead. However, I don't think you need to CC 14 teams on an email just in case they don't read -dev. Debate it on -dev, and then announce the outcome on -announce if it is important enough. Rich
Re: [gentoo-dev] Unified DEPENDENCIES concept
On Fri, Sep 14, 2012 at 07:18:54AM +1200, Kent Fredric wrote:
On 11 September 2012 14:16, Brian Harring ferri...@gmail.com wrote:
On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote:
Is there anything in particular in the spec/proposal for DEPENDENCIES
that would exclude the addition of individual build: app-cat/myatom
run: app-cat/myatom deps by an eclass or eclasses? I know the
goal here is to make things atom-centric, but I can't see an
implementation ever working of this that wouldn't permit the pile-on
of additional entries of different (or even the same) roles on
identical or near-identical atoms.
They could be piled on; it would require each eclass to reset the
label for safety reasons though; same goes for ebuilds frankly (or the
PM would have to reset the context to build+run: each time through).
Pardon if addressed elsewhere; this thread is a fucking mess...
~harring
Correct me if I'm wrong, but couldn't the entire proposition could be
implemented in an eclass, not needing the EAPI development cycle to be
tied up with it.
All you need is something in bash that can parse DEPENDENCIES and
populate *DEPEND , and the underlying guts could be done in
practically any language without requiring PM specific
implementations.
You've got it inverted; if any autopopulation is occuring, *DEPEND -
DEPENDENCIES is the sane form.
While it definitely *is* possible to render DEPENDENCIES down into
depend/rdepend (after all, the PM has to do exactly this for
resolution), that does /not/ mean doing it in bash is a good idea.
I'd really not want to try that using labels; using use conditionals
('dep:run,build? ( targets )') is frankly a bit easier imo, but still;
why do so unless one likes pain? It doesn't actually gain us
anything via missing the point of DEPENDENCIES.
The point of unified DEPENDENCIES var (regardless of the form) is
thus:
1) ability to specify common deps once, w/out having to use
intermediate vars/copy-pasting/etc. Think COMMON_DEPEND, and this
should make sense.
2) To shift to a form where adding new dependency targets is easy-
whether it be sdepend, fdepend, tdepend, or hdepend (or
ONE-RING-DEPEND to rule them all). This actually is rather important;
for the average 95% case, devs won't actually have to pay much
attention to those vars; but for those of us a bit further out (cross
compilation, heavy parallelization, etc) those depend forms are
becoming increasingly painful in their absense.
Basically, having devs specify DEPENDENCIES in ebuilds, which then an
eclass chunks out into DEPEND/RDEPEND misses the point of this; it's
doable, it's just not particularly sane imo.
The other way around, having *DEPEND automatically be collapsed into
DEPENDENCIES, however is very sane- it makes transition/compatibilty
for devs bloody simple, while structuring it so we can do further
enhancements.
~harring
