Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On 16 September 2012 09:20, Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 12:03:36AM +0200, Micha?? G??rny wrote: On Sat, 15 Sep 2012 13:33:18 -0700 Brian Harring ferri...@gmail.com wrote: To demonstrate the gain of this, we basically take the existing tree's deps, and re-render it into a unified DEPENDENCIES form. But in order to do this, we first have to decide exactly what kind of dependencies do we want to have. Then convert the tree to a separate-variable form with new dependencies. Then we can compare it with the DEPENDENCIES form and decide which one is better. Funny you mentioned that, I just finished tweaking pquery to generate real world example unified dependencies; these *are* accurate, just to be clear. Dumps are at http://dev.gentoo.org/~ferringb/unified-dependencies-example/ . Herds, if you want to see what your pkgs would look like, look at http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ . If you'd like to see an *example effect* it has on what gets displayed to the user (aka, after all major use conditionals are stripped), look at http://dev.gentoo.org/~ferringb/unified-dependencies-example/user-visible.txt ; warning, that's a 55MB file. The syntax in use there isn't great, but as said, it's an example. Total cache savings from doing this for a full tree conversion, for our existing md5-cache format is 2.73MB (90 byes per cache entry). Calculating the savings from the ebuild/eclass standpoint is dependent on how the deps are built up, so I skipped that. The algorithim used is fairly stupid, but reasonably effectively; essentially it intersects the top level of each individual type of dep, breaking out common groupings. In other words, it won't pick up this: DEPEND=x? ( dev-util/diffball dev-util/bsdiff ) RDEPEND=x? ( dev-util/diffball ) and convert it into thus DEPENDENCIES= dep:build,run? ( x? ( dev-util/diffball dep:run? ( dev-util/diffball ) ) ) Additionally, the form used here makes *no assumption about default context*; in any final solution we use, a default context would be wise- say build,run. Again, an example of what I mean. If we said in the absense of a context, the default is dep:build,run the following: DEPEND=dev-util/diffball dev-util/bsdiff RDEPEND=dev-util/diffball de-vutil/bsdiff x? ( sys-apps/pkgcore ) PDEPEND=dev-python/snakeoil would be: DEPENDENCIES= dev-util/diffball dev-util/bsdiff dep:run? ( x? ( sys-apps/pkgcore ) ) dep:post? ( dev-python/snakeoil ) The quicky algo I used assumes no default context, thus it writes this: DEPENDENCIES= dep:build,run? ( dev-util/diffball dev-util/bsdiff ) dep:run? ( x? ( sys-apps/pkgcore ) ) dep:post? ( dev-python/snakeoil ) Etc. ~harring Thanks. I have given it a quick overview for the qt herd. I still don't see what using DEPENDENCIES adds to what we do now with separate *DEPEND variables. I see no convincing reason to change what we do. As I've said before on IRC, we need a good costs/benefits overview. Right now I only see costs (migrating ebuilds and eclasses) and no benefits. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] [PATCH] eutils: Warn on built_with_use usage
At this point, the functionality built_with_use provides should
be covered near or more likely, in full, but USE deps in EAPI2 and
EAPI4; thus warn on usage.
While this may be a bit annoying, this is the only major consumer
left at this point that knows about /var/db/pkg layout; once that's
gone, alternative VDB formats can occur (meaning faster package
manager operations, or at least the potential if implemented sanely).
This patch is a rough first stab at the wording (english isn't
exactly my forte) to use for warning; better/clearer warning text
would be appreciated.
---
eutils.eclass | 13 +
1 file changed, 13 insertions(+)
diff --git a/eutils.eclass b/eutils.eclass
index 8bfc2bc..7f5a616 100644
--- a/eutils.eclass
+++ b/eutils.eclass
@@ -1196,7 +1196,9 @@ built_with_use() {
fi
local missing_action=die
+ local missing_was_set=false
if [[ $1 == --missing ]] ; then
+ missing_was_set=true
missing_action=$2
shift ; shift
case ${missing_action} in
@@ -1205,6 +1207,17 @@ built_with_use() {
esac
fi
+ if ! has $EAPI 0 1 2 3; then
+ eqawarn built_with_use should not be used in $EAPI; use USE
deps.
+ elif has $EAPI 2 3; then
+ if [[ $hidden == yes ]] || $missing_was_set; then
+ eqawarn built_with_use in EAPI=$EAPI without --missing
or --hidden usage, should use USE deps instead.
+ else
+ eqawarn built_with_use should not be used; upgrade to
EAPI=4 instead
+ fi
+ fi
+
+
local opt=$1
[[ ${opt:0:1} = - ]] shift || opt=-a
--
1.7.12
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sat, 15 Sep 2012 18:20:26 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 12:03:36AM +0200, Micha?? G??rny wrote: On Sat, 15 Sep 2012 13:33:18 -0700 Brian Harring ferri...@gmail.com wrote: To demonstrate the gain of this, we basically take the existing tree's deps, and re-render it into a unified DEPENDENCIES form. But in order to do this, we first have to decide exactly what kind of dependencies do we want to have. Then convert the tree to a separate-variable form with new dependencies. Then we can compare it with the DEPENDENCIES form and decide which one is better. Funny you mentioned that, I just finished tweaking pquery to generate real world example unified dependencies; these *are* accurate, just to be clear. But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. Total cache savings from doing this for a full tree conversion, for our existing md5-cache format is 2.73MB (90 byes per cache entry). Calculating the savings from the ebuild/eclass standpoint is dependent on how the deps are built up, so I skipped that. You're storing the cache in a tarball? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] a libtool + multilib gentoo host + 64-32 cross-prefix problem: a request for eyeballs
Gregory M. Turner wrote: Please see https://bugs.gentoo.org/show_bug.cgi?id=430722, especially the final two posts. I think the problem is that upstream isn't multilib-aware. I also think that it would be awesome if Gentoo could handle such situations for us. The brute force method would be to do things in every ebuild for multilib-challenged packages, but something smarter would be nice.. //Peter
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. What I suspect they were intending on doing is letting the resolver work on RDEPENDS of a pkg in parallel to that pkg being built; this is a parallelization scheduling optimization, still requires accurate deps. I'm trying to be nice here, but you're very confused on this matter. Total cache savings from doing this for a full tree conversion, for our existing md5-cache format is 2.73MB (90 byes per cache entry). Calculating the savings from the ebuild/eclass standpoint is dependent on how the deps are built up, so I skipped that. You're storing the cache in a tarball? Going to assume you're not trolling, and instead use this as a way to point out that this actually *does* matter, although it's admittedly not obvious if you don't know much about the guts of package managers, or don't spend your saturday nights doing fun things like optimizing ebuild package manager performance. First, the figure is 3.204MB if default context is used; ~9.5% of the content footprint for md5-cache specifically. Little known fact; rsync transfers for gentoo are required to be --whole-file; meaning no intra-file delta compression, it transfers the whole file itself. This is done to keep cpu load on rsync nodes low (else they'd be calculating minimally 97k md4's for every sync, not counting the rolling adl32 chksum for all content dependent on the window cut off threshold- sounds minor, but it's death by a thousand cuts). For obvious reasons, the cache is the hottest part of the tree due to cascading updates due to eclass changes. In other words, that ~9.5% reduction targest the core data actually transferered in a sync. In terms of the total tree footprint, it's a 1% reduction; mostly lost in blocksize overhead unless you're using squashfs (which a decent number of folks do for speed reasons), or use tail packing FS for the tree (again, more than you'd think- known primarily due to reiserfs corruption bugs causing some hell on PM caches). There's also the fact doing this means best case, 2 less inodes per VDB entry (more once we start adding dependency types). For my vdb, I have 15523 across 798 pkgs. 1331 of that is *DEPEND, converted to DEPENDENCIES the file count is 748. Note that's preserving DEPEND, although it's worthless at this stage of the vdb. So 5% reduction in files in there. Whoopy-de-doo, right? This one I can't test as well since the only rotational media I've got these days is a hardware raid w/ a beefy cache; the closest I can manage is local network nfs to an ssd FS, so it'll have to serve as a stand in for cold cache/hot cache, and for a demonstration of why having a backend that is a 101 small individual files is bad. Best of 5 is displayed below: Iterating over the vdb, and parsing and rendering all depends for our current layout, w/ the vdb stored on nfs: cold cache: real0m30.405s user0m1.046s sys 0m0.390s hot cache: real0m16.483s user0m0.883s sys 0m0.168s non-optimized, hacked to work (known slower for parsing in comparison to the non quicky hack), iterating over the vdb, parsing all depends and rendering said depends when it's stored as DEPENDENCIES; literally, rendering DEPEND from it, RDEPEND, PDEPEND. cold cache: real0m18.329s user0m0.908s sys 0m0.280s hot cache real0m12.185s user0m0.860s sys 0m0.128s You get the idea. See the various infamous cold cache/hot cache performance tests in doubt; I can tell you that a similar trick, done in '07, literally just skipping loading USE till it was needed for provides parsing was enough to bring a 5400RPM drive's run time down from 15s to 12s for cold cache- for parsing provides *alone*, nothing else. Either way, do your own investigation, it's a good education on performance. Hopefully for the others listening, that last section was a random but useful tidbit of info; if not, pardon, just being through to make sure this point is not raised again. ~harring
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, 16 Sep 2012 04:10:01 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. I don't think we have made up our mind what *exactly* we want from deps. Just because we have something semi-correct right now, doesn't mean that we don't want to change that. But I guess with the whole amount of noise in here I won't ever get any definitive answer. There's also the fact doing this means best case, 2 less inodes per VDB entry (more once we start adding dependency types). For my vdb, I have 15523 across 798 pkgs. 1331 of that is *DEPEND, converted to DEPENDENCIES the file count is 748. Note that's preserving DEPEND, although it's worthless at this stage of the vdb. So 5% reduction in files in there. Whoopy-de-doo, right? So we can modify vdb now? What about all those applications which obviously are broken due to that? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 01:21:26PM +0200, Micha?? G??rny wrote: On Sun, 16 Sep 2012 04:10:01 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. I don't think we have made up our mind what *exactly* we want from deps. Are we now expecting deps to give us ponies or something? We know *exactly* what we want from deps, and their current definition- the problem isn't the definition, it's that we don't have the forms we need. Just because we have something semi-correct right now, doesn't mean that we don't want to change that. This is a no-op argument against the proposal: we can't change the deps because we might want to change the deps. It's also irrelevant due to the core basis of it being broken as fuck (described above). There's also the fact doing this means best case, 2 less inodes per VDB entry (more once we start adding dependency types). For my vdb, I have 15523 across 798 pkgs. 1331 of that is *DEPEND, converted to DEPENDENCIES the file count is 748. Note that's preserving DEPEND, although it's worthless at this stage of the vdb. So 5% reduction in files in there. Whoopy-de-doo, right? So we can modify vdb now? What about all those applications which obviously are broken due to that? You're misunderstanding the problem of the VDB. We cannot change the core structure of it- certain ebuilds currently expect to be able to find USE/IUSE at specific pathways. That's where we're blocked. Adding a new metadata key can, and has been done (defined_phases, properties, required_use, etc). Removing keys can be done. For efficiency, not writing a key if it's empty, can be and is being done. Basically, your retort again, is wildly off mark and misunderstanding the problem. I strongly suggest you go do some real research into the existing PMs, and the problems being discussed. Go read some code; you've minimally got 3 different codebases to work from, and that's not counting ML archives, tools, PMS, or the devmanul. If per you're statements, you're actually serious about writing your own PM, you're going to need to know this sort of shit /anyways/ to actually do the basic legwork of a PM, so please go do the necessary legwork if you want to persist in arguing about internals. ~harring
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, 16 Sep 2012 04:49:21 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 01:21:26PM +0200, Micha?? G??rny wrote: On Sun, 16 Sep 2012 04:10:01 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. I don't think we have made up our mind what *exactly* we want from deps. Are we now expecting deps to give us ponies or something? We know *exactly* what we want from deps, and their current definition- the problem isn't the definition, it's that we don't have the forms we need. No, the problem is that we think we need more than we have now. Unless you're considering the whole point of this thread is cosmetics... then please leave that to Fedora or other people who are paid to change stuff just because they can. Just because we have something semi-correct right now, doesn't mean that we don't want to change that. This is a no-op argument against the proposal: we can't change the deps because we might want to change the deps. It's also irrelevant due to the core basis of it being broken as fuck (described above). What I'm trying to say is that you're making a lot of noise about cosmetics while we haven't even agreed on what's supposed to be inside. So, are we introducing this obtuse syntax for three DEPEND variables, of which the third is almost never used? -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Lastrites: media-libs/gmyth, media-plugins/gst-plugins-mythtv, net-libs/libmonetra, dev-php/pecl-mcve, dev-vcs/svk, net-im/jabberd, net-p2p/sancho-bin, media-sound/xfi-drivers, app-misc/r
# Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Dead upstream, fails tests (#315565), wasn't updated # for recent MythTV versions. Removal in a month. media-libs/gmyth media-plugins/gst-plugins-mythtv # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Fails old-elibtoolize sanity check (#341721), has security # issues. Removal in a month. net-libs/libmonetra dev-php/pecl-mcve # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Current version in tree has multiple bugs, perl team recommends # to use CPAN version instead, bug #420515. Removal in a month. dev-vcs/svk # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Upstream keeps inactive for ages and, then, it has broke again # now with gnutls-3 (#421385). Removal in a month. net-im/jabberd # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Has insecure rpaths (#421971), current version in tree doesn't # start and upstream ceased development long time ago. # Removal in a month. net-p2p/sancho-bin # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Fails with kernel-3.4, its included alsa version should # support affected hardware (#422641). Removal in a month. media-sound/xfi-drivers # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Has overflows (#423619), upstream dead and only useful for MP3 # players released in 1998. Removal in a month. app-misc/rio # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Upstream looks dead and is not fully compatible with current # audacious (#424103). Removal in a month. media-sound/audtty # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Diego Elio Pettenò flamee...@gentoo.org (08 Jul 2012) # Dead upstream (domain is gone as well), very bad code. # If possible use net-ftp/tftp-hpa; if that is not possible, let us # know by filing a bug and blocking against bug #425362. # Removal in a month. net-ftp/netkit-tftp # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Fails to build with boost-1.50 (#425602), upstream dead for ages. # Removal in a month. gnome-extra/wp_tray # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Old version, you need to use sci-geosciences/qlandkartegt instead. # Removal in a month. sci-geosciences/qlandkarte # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Fails to build with latest binutils (#430362), dead upstream and # nothing needs it in the tree. Removal in a month. dev-libs/mpatrol # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # It ignores CFLAGS (#431298), nothing in the tree needs it, # upstream is dead and people can use hfsutils and netatalk # as replacements. Removal in a month. app-arch/macutil signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 03:39:22PM +0800, Ben de Groot wrote:
On 16 September 2012 09:20, Brian Harring ferri...@gmail.com wrote:
Dumps are at
http://dev.gentoo.org/~ferringb/unified-dependencies-example/ .
Herds, if you want to see what your pkgs would look like, look at
http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ .
If you'd like to see an *example effect* it has on what gets displayed
to the user (aka, after all major use conditionals are stripped), look
at
http://dev.gentoo.org/~ferringb/unified-dependencies-example/user-visible.txt
; warning, that's a 55MB file. The syntax in use there isn't great,
but as said, it's an example.
...
Additionally, the form used here makes *no assumption about default
context*; in any final solution we use, a default context would be
wise- say build,run. Again, an example of what I mean.
The dumps were regenerated; a default context of 'build,run' was
added. Basically in the absense of an explicit dep: targetting,
dep:build,run is assumed.
Essentially it makes the deps cleaner to read for the common case,
while also reducing the footprint at the cache, and vdb level; see
http://dev.gentoo.org/~ferringb/unified-dependencies-example/vdb-effect.txt
Thanks. I have given it a quick overview for the qt herd. I still
don't see what using DEPENDENCIES adds to what we do now with separate
*DEPEND variables. I see no convincing reason to change what we do.
Ok, so here's some stats: in the tree, we have 31360 ebuilds, and 194
eclasses; grand total of 31554 sources of metadata content (I say
metadata since vapier has eblits in use which are just phase
functions- I'm not scanning those intentionally).
Doing some simple scans of the tree, here's some stats; note these
stats are duplicated in the glep (they're nice selling points, thus
might as well):
1) 746 hits in the tree for COMMON_DEPEND; that's 2%, and the usages
I'm aware of have been for literally, what it sounds like- depends
that are both DEPEND and RDEPEND.
2) scanning for assignments of RDEPEND=.*|$\{?DEPEND\}? gets a hit on
5343 unique sources. Searching for the inverse gets a hit on 10008
unique sources. Meaning that right there, ~48.6% of the tree is
duplicating deps between the two forms. This puts us to 16083 unique
sources in the tree that would benefit in some form (~51%).
3) What's interesting about that 51% is the eapi groupings; in EAPI4,
the autosetting of RDEPEND=${RDEPEND:-${DEPEND}} was discontinued.
Roughly 50% of the initial 51% match is EAPI4; the rest are eapi0-3.
4) Again, keep in mind that the grep's in use above are single line
matches- I'm definitely missing some ebuilds, and for complex
dependencies that are appended/set by the eclass, likely missing a lot
of that too.
So... basically, people are already doing this manually with their own
intermediate vars.
Just a rough but mildly entertaining stat there's basically 8.38MB
worth of normalized, literal fricking dependency; using a crappy algo
(rather than a human doing the deps who can do it better), 37.4%
(3.1MB) of that is removed via going to dependencies. It goes
without saying that this would be a helluva lot less torturous on a
proper PM implementation that parses the tree once, and renders- let
alone repoman being able to avoid repeat scans of things it already
has examined.
Mind you, portage doesn't do that, but this would be good incentive to
do a proper tree. :)
As I've said before on IRC, we need a good costs/benefits overview.
Right now I only see costs (migrating ebuilds and eclasses) and no
benefits.
Offhand... I wouldn't be pushing for this if I didn't think this would
be a boon over all- both for devs, and PMs.
I think the actual 'cost' probably got lost in the noise of the
various flames; what I'm proposing is basically zero cost for devs, it
shoves the work to the PM, leaving the option for devs to do a more
fine grained form if they can.
I'm starting a seperate thread w/ a glep for this; I think you should
take a look at the exact details of the specification including how
DEPEND/RDEPEND/PDEPEND are handled in parallel to DEPENDENCIES (short
version: if existent, they're automatically folded into DEPENDENCIES
in my proposal); the end result is basically zero pain transition,
while enabling us to start getting gains.
Cheers-
~brian
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 02:02:24PM +0200, Micha?? G??rny wrote: On Sun, 16 Sep 2012 04:49:21 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 01:21:26PM +0200, Micha?? G??rny wrote: On Sun, 16 Sep 2012 04:10:01 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. I don't think we have made up our mind what *exactly* we want from deps. Are we now expecting deps to give us ponies or something? We know *exactly* what we want from deps, and their current definition- the problem isn't the definition, it's that we don't have the forms we need. No, the problem is that we think we need more than we have now. Read what I wrote. we don't have the forms we need; a more proper statement is we don't have all of the forms we need. Please read what I write, rather than just responding blindly. You may have time to waste, but I don't, nor do the people on this ml need to see you respond 13 minutes after I send an email when you can't even be bothered to read the fucking content properly. Unless you're considering the whole point of this thread is cosmetics... then please leave that to Fedora or other people who are paid to change stuff just because they can. This isn't productive; frankly it's childish. Take it to the forums if you want to continue on tangents like this. Just because we have something semi-correct right now, doesn't mean that we don't want to change that. This is a no-op argument against the proposal: we can't change the deps because we might want to change the deps. It's also irrelevant due to the core basis of it being broken as fuck (described above). What I'm trying to say is that you're making a lot of noise about cosmetics while we haven't even agreed on what's supposed to be inside. So, are we introducing this obtuse syntax for three DEPEND variables, of which the third is almost never used? Reiterating the points again, and for the final time for you since you seem intent on riding the short bus for this particular subject: 1) This unifies the existing syntax down into a collapsed form. In doing so, there are measurable gains across the board for PM efficiency and rsync alone. 2) In unifying the syntax via reusing our /existing fucking syntax/, we formalize the adhoc common dependency assignments devs already are doing in the tree. 3) In moving to a unified syntax, it positions us to easily introduce new dependency types without introducing more redundancy. Easier to add new dep types, faster to add new dep types, more efficient in doing so in comparison to existing approaches, and done in a fashion that devs can reuse existing conditionals. 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. Meaning you do not need to knee-jerk attack it because of some notion it's ciaran based/related. Honestly, stop wasting my (and others time) and please read this email full and through, including the /full thread you're blindly responding to/ before responding again. There is no prive for having the fastest turn around time in responding to an email; not unless you consider a permenant /ignore and killfile addition to be a prize. ~harring
[gentoo-dev] GLEP: gentoo sync based unified deps proposal
Folks- Keeping it short and quick, a basic glep has been written for what I'm proposing for DEPENDENCIES enhancement. The live version of the doc is available at http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html Wording fixes will occur, but the core concept shouldn't change (and if it does, per PEP standards, the changes will be noted/tracked). Please have a read through; it should be clear/concise as to why PM authors are pushing for a unified dependencies to be done, what we can get from it now, what it enables moving forward, and the direct cost to devs should this idea be implemented. Just to be absolutely clear, what I'm proposing is basically zero cost for devs- they can (and should when it's in their benefit) switch to the new syntax when it makes their job easier; it can be used in parallel to existing DEPEND/RDEPEND/PDEPEND both to ease transition/compatibility. In addition, a prototype portage patch has been cut for dependencies support (needs work/full validation), and a matching pkgcore one has been cut. I realize it's a complex subject; if you have questions, please feel to ask. Thanks, and pardon the ancillary/daft noise that has gone with this subject. ~harring
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 16 Sep 2012 06:52:11 -0700 Brian Harring ferri...@gmail.com wrote: The live version of the doc is available at http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html I think you're being a bit glib with your dismissal of the labels parsing scheme. You've got the following problems, that labels don't have: You dismiss the dep:build? ( dep:run? ( ) ) problem as don't do that. Labels doesn't have this problem: it doesn't try to reuse an existing syntax precisely because the existing syntax is extremely awkward for this kind of thing. You say there's an implict build,run. This can't be an implicit dep:build,run? ( ) using that syntax, however, since then you wouldn't be able to put a dep:post? inside it by the above. So again you've got a special case to deal with simply because of the syntax -- your syntax doesn't correspond directly to the meaning of dependencies. There's also the issue of what negations do at the top level... You discourage grouping of dependencies by the use flag that selects them (see xscreensaver in your examples). Logically, xscreensaver related things belong together. Your negation example also tries to bring related dependencies together. But it's a mess. What if one of the dependencies was a build dependency, and one a run dependency? You'd end up with something silly like this: dep:build,run? ( !dep:run? ( dev-util/diffball ) !dep:build? ( dev-util/bsdiff ) ) Your syntax also prevents the following: DEPENDENCIES=foo? ( $(make_foo_deps blah) ) and would encourage something like this instead: DEPENDENCIES= dep:build? ( foo? ( $(make_foo_build_deps blah) ) ) dep:run? ( foo? ( $(make_foo_run_deps blah) ) ) dep:build,run? ( foo? ( $(make_foo_build_and_run_deps blah) ) ) which makes it much harder for the foo.eclass authors to switch what kinds of dependencies they use. For example, if foo.eclass starts needing an install dependency, your syntax requires every foo user to be updated, whereas labels does not. To get around that, you'd have to allow deeply embedded dep: blocks. You're also still speaking in terms of rendering DEPEND etc. That's not really what we want, though. As you've observed, a lot of atoms are in both DEPEND and RDEPEND. Conceptually, it makes much more sense to consider such an atom to be a single dependency that is both a build and a runtime dependency than it does to consider it as two unrelated dependencies. This is especially the case now that we have := slot dependencies. Ultimately, it comes down to the observation that the flag? ( ) syntax is strongly nested and hierarchical, but dependency roles aren't. Labels can give all the advantages of your proposal (including the backwards compatibility, if that's desired), but without the need to shoehorn the idea into an unsuitable syntax. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Sat, 15 Sep 2012 18:47:56 -0400 Mike Frysinger vap...@gentoo.org wrote: On Tuesday 11 September 2012 14:06:30 Alexis Ballier wrote: On Tue, 28 Aug 2012 00:23:11 + (UTC) Mike Frysinger wrote: vapier 12/08/28 00:23:11 Modified: ChangeLog profiles.desc Log: add new s390x profile #345421 [...] @@ -152,7 +153,7 @@ x86 default/linux/x86/10.0/server stable # Gentoo/FreeBSD Profiles -amd64-fbsd default/bsd/fbsd/amd64/9.0 stable +amd64-fbsd default/bsd/fbsd/amd64/9.0 dev sparc-fbsddefault/bsd/fbsd/sparc/8.2 exp x86-fbsd default/bsd/fbsd/x86/8.2 dev x86-fbsd default/bsd/fbsd/x86/9.0 dev please be more careful, it is good practice to review the cvs diff output before hitting ci when committing to the profiles or eclass directories. that was only partially an accident. amd64-fbsd has no business being in stable since it has broken deps and has no stable keywords. search the archives as for why its stable. profile not being stable is the cause for broken deps, not the consequence... also, where does your idea stable profile == stable keywords come from ? if you want them to be the same, you need to invent something that would make repoman checks fatals for broken deps rather than displaying non fatal warnings that nobody ever reads because it needs -d. also, you are missing some bug # for the 'broken deps' part. packages that have gained broken deps when the profile was marked 'dev', or that you committed with your profile.desc locally modified, do not count and are your fault actually...
Re: [gentoo-dev] Lastrites: media-libs/gmyth, media-plugins/gst-plugins-mythtv, net-libs/libmonetra, dev-php/pecl-mcve, dev-vcs/svk, net-im/jabberd, net-p2p/sancho-bin, media-sound/xfi-drivers, app-mi
Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Upstream keeps inactive for ages and, then, it has broke again # now with gnutls-3 (#421385). Removal in a month. net-im/jabberd What about the 1.4 version? It depends on openssl, so maybe it doesn't have the gnutls issue. I kinda like jabberd. //Peter pgpUp0raARUwx.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, Sep 16, 2012 at 03:39:49PM +0100, Ciaran McCreesh wrote:
On Sun, 16 Sep 2012 06:52:11 -0700
Brian Harring ferri...@gmail.com wrote:
The live version of the doc is available at
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html
I think you're being a bit glib with your dismissal of the labels
parsing scheme. You've got the following problems, that labels don't
have:
You dismiss the dep:build? ( dep:run? ( ) ) problem as don't do that.
x? ( !x? ( dep ) ) already exists syntactically. dep:build? (
dep:run? ( blah ) ) is no different, so yes, I dismiss it- frankly
with prejudice since you keep bringing that example up but ignoring
that it's not a new issue (plus ignoring that it never occurs in the
wild because it's a self-solving issue).
Labels doesn't have this problem: it doesn't try to reuse an existing
syntax precisely because the existing syntax is extremely awkward for
this kind of thing.
Labels have a human comprehension problem, and require a fair amount
more work for the various parsers.
You may not agree on that view, but there seems to be some consensus
on that (as much as one ever gets in gentoo at least).
You say there's an implict build,run. This can't be an implicit
dep:build,run? ( ) using that syntax, however, since then you
wouldn't be able to put a dep:post? inside it by the above.
You're misunderstanding; you're thinking about it as to how exheres
labels are done which is basically
build+run: ${DEPENDENCIES}
One thing to keep in mind here; I don't mind making the parser do some
extra work if it's easier on devs to deal with (including
aesthetically; like it or not, dependencies is needed, and screaming
labels are the one true religion isn't going to get us to where we
need to go- pragmatic compromise will).
Either way, in the absense of an explicit dep context, dep:build,run?
is assumed. The parser/visitation implementation is admittedly more
complex, but it's not in the realm of 'hard'. This is assuming a
non-shit implementation mind you.
Either way, my focus here is on the human, as I've stated.
So again
you've got a special case to deal with simply because of the syntax --
your syntax doesn't correspond directly to the meaning of dependencies.
doesn't correspond directly to the meaning of dependencies is a
vague assertion; back that one up. I'm assuming you're complaining
that conditionals are being used (the but they're not USE flags! bit
which is a subjective view of the conditional namespace).
If that's not what you're referencing, then frankly I'll just go with
explain to me how this same critique doesn't apply to labels.
There's also the issue of what negations do at the top level...
Yeah, I did skimp on that one; technically speaking, negations aren't
required if they prove too much of a pain in the ass. Negation at the
top level could be interpretted two ways:
1) negating against all possible dep types; thus a !dep:build? would
be dep:post,run? . Too slick in my view, but who knows, othes may
think it straight forward.
2) Treat it as a negation of the implicit dep:build,run; meaning
!dep:build? would be dep:run?.
Unsure of which is preferably at this juncture.
You discourage grouping of dependencies by the use flag that selects
them (see xscreensaver in your examples). Logically, xscreensaver
related things belong together.
I do not discourage grouping. The example is an automated
conversion, as explicitly mentioned in the doc.
A secondary condensing of those deps I'll add to make clear it's
supported.
Your negation example also tries to
bring related dependencies together. But it's a mess. What if one of
the dependencies was a build dependency, and one a run dependency?
You'd end up with something silly like this:
dep:build,run? (
!dep:run? ( dev-util/diffball )
!dep:build? ( dev-util/bsdiff )
)
Ciaran, we use a fucking bash format. We lost the ability to block
silly idiocy long ago via that choice.
As said, 'x? ( !x? ( dep ) )' already exists, despite being dumb. The
beauty of it however is that the syntax rules themselves make it such
that it doesn't ever actually come up in real world usage- the dep
wouldn't be used fundamentally.
My intention is a syntax/format that is natural to the dev, and
doesn't force them to do silly shit. If they choose to do silly shit,
that's on their head; trying to explicitly ban all possible dumb uses
just makes the rules worse via increased complexity.
Also, just to be clear, this critique applies to exheres labels just
the same. That example, rewritten to drop the negations is thus:
dep:build,run? (
dep:build? ( dev-util/diffball )
dep:run? ( dev-util/bsdiff )
)
Yep. That's pretty dumb. But no less retarded than someone doing the
following in labels:
build+run:
build: dev-util/diffball
run: dev-util/bsdiff
Which I'll note isn't banned in your usage,
Re: [gentoo-dev] Lastrites: media-libs/gmyth, media-plugins/gst-plugins-mythtv, net-libs/libmonetra, dev-php/pecl-mcve, dev-vcs/svk, net-im/jabberd, net-p2p/sancho-bin, media-sound/xfi-drivers, app-mi
On 16 September 2012 23:40, Peter Stuge pe...@stuge.se wrote: Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Upstream keeps inactive for ages and, then, it has broke again # now with gnutls-3 (#421385). Removal in a month. net-im/jabberd What about the 1.4 version? It depends on openssl, so maybe it doesn't have the gnutls issue. I kinda like jabberd. So step up and take on maintainership of that package. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sep 16, 2012 4:55 PM, Brian Harring ferri...@gmail.com wrote:
Folks-
Keeping it short and quick, a basic glep has been written for what I'm
proposing for DEPENDENCIES enhancement.
The live version of the doc is available at
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html
Am I the only one who thinks that this dep:{build,...} thing looks really
ugly and is hard to read?
IMO simply removing the dep part would greatly improve things:
DEPENDENCIES=
:build,run? ( ... )
:run? ( ... )
s/:/@/ would also be interesting
DEPENDENCIES=
@build,run? ( ... )
@run? ( ... )
Alex | wired
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sun, 16 Sep 2012, Alex Alexander wrote:
Am I the only one who thinks that this dep:{build,...} thing looks
really ugly and is hard to read?
+1
IMO simply removing the dep part would greatly improve things:
DEPENDENCIES=
:build,run? ( ... )
:run? ( ... )
IMHO it would improve readability even more if we would stay with our
traditional *DEPEND variables. In any case, package managers will have
to support them indefinitely for existing EAPIs.
Ulrich
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 16 Sep 2012 09:05:28 -0700 Brian Harring ferri...@gmail.com wrote: Labels doesn't have this problem: it doesn't try to reuse an existing syntax precisely because the existing syntax is extremely awkward for this kind of thing. Labels have a human comprehension problem, and require a fair amount more work for the various parsers. You may not agree on that view, but there seems to be some consensus on that (as much as one ever gets in gentoo at least). I've never heard that view coming from anyone who has actually used labels. It's only come from people who haven't tried using it, and who have a history of disagreeing with anything that says 'Exherbo' on it. You're taking about consensus among people who have never tried it because they don't like it; consensus among people who have tried it is that the labels syntax is good. My intention is a syntax/format that is natural to the dev, and doesn't force them to do silly shit. Labels already solve that. We know because we've got extensive experience with them. Adoption of labels has been demonstrated to be easy, both for former Gentoo developers and for people who haven't previously written ebuilds. We *know* that labels are easy to learn and easy to use. We also know that they admit an efficient implementation, that they compose nicely, that they allow dependencies to be specified accurately and that they scale to larger numbers of dependency classes. Your syntax also prevents the following: DEPENDENCIES=foo? ( $(make_foo_deps blah) ) Err, no it doesn't. I think you're reading too literally into the example mplayer translation I put in the doc- again, that was just a quicky, automated form, you can push dep:blah down beneath conditionals as necessary/desired. If you see something claiming otherwise, or implying otherwise in the glep, please tell me exactly where so I can fix the wording. The point is that nesting prevents composition. Labels are context insensitive, which allows groups of dependencies to be added anywhere, whereas dep: blocks can only be added if the surrounding groups are specified in a particular way. 1) first, collapse dependencies down, than render the *DEPEND views, thus enabling easy and quick initial integration; effectively no impact on the api/functionality of the PM at this phase. Specification in terms of rendering has a huge problem, though. Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what does this do? || ( dep:build? ( a ) dep:run? ( b ) ) Ultimately, it comes down to the observation that the flag? ( ) syntax is strongly nested and hierarchical, but dependency roles aren't. There is a bit of truth in that views on flag? ( ) vs the random-ass context labeling (which is hierarchical- keep in mind your stack pushing/popping confusion). There's not any stack confusion in practice. Labels only have slightly complicated rules to allow every side case to be covered. You're taking the don't do that approach to nesting weirdness; labels go the specify it precisely route instead. Labels can give all the advantages of your proposal (including the backwards compatibility, if that's desired), but without the need to shoehorn the idea into an unsuitable syntax. If you want your proposal to go anywhere, you're going to need a better transition plan then and then devs convert their ebuilds/eclasses. I'd suggested it prior, but no traction there. Your rewrite *DEPEND approach can just as easily be used with labels. -- Ciaran McCreesh signature.asc Description: PGP signature
Last rites: tla.eclass (was: Re: [gentoo-dev] tla.eclass)
On Sat, 15 Sep 2012, Michał Górny wrote: Not used by any ebuild in the tree, and dev-util/tla was removed four years ago. Remove? Yes, please. tla.class will be removed in 30 days then. Sending to -dev-announce as required by policy. However, it should be moved to Sunrise; there's one ebuild using it there. I'll take care of this. Ulrich
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-09-16 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-09-16 23h59 UTC. Removals: dev-db/pgpool 2012-09-16 12:21:52 pacho dev-ruby/spruz 2012-09-16 12:24:30 pacho dev-util/pkg-config-lite2012-09-16 12:25:56 pacho x11-misc/glipper2012-09-16 12:27:39 pacho net-fs/mount-cifs 2012-09-16 12:28:35 pacho app-misc/jbidwatcher2012-09-16 12:35:22 pacho app-laptop/lenovo-sl-laptop 2012-09-16 12:37:49 pacho dev-python/sexy-python 2012-09-16 12:39:45 pacho media-plugins/vdr-cdda 2012-09-16 12:41:00 pacho dev-ruby/Ruby-MemCache 2012-09-16 12:41:47 pacho x11-misc/transset-df2012-09-16 12:42:38 pacho Additions: net-wireless/multimode 2012-09-10 02:22:38 zerochaos net-wireless/gr-baz 2012-09-10 02:30:22 zerochaos net-wireless/sdrsharp 2012-09-10 02:39:37 zerochaos net-wireless/uhd2012-09-10 03:13:47 zerochaos dev-libs/liborcus 2012-09-10 09:17:40 scarabeus media-sound/gnaural 2012-09-10 11:16:53 miknix sys-firmware/ipxe 2012-09-10 21:32:58 cardoe dev-perl/Tie-Cycle 2012-09-11 03:14:04 tove dev-perl/Business-ISMN 2012-09-11 03:21:08 tove dev-perl/Business-ISSN 2012-09-11 03:31:54 tove dev-games/gigi 2012-09-11 15:57:21 tomka games-strategy/freeorion2012-09-11 16:01:06 tomka dev-perl/Business-ISBN-Data 2012-09-11 16:32:13 tove dev-perl/Business-ISBN 2012-09-11 16:36:35 tove app-admin/gksu-polkit 2012-09-12 11:57:26 tetromino net-im/purple-events2012-09-12 21:34:59 hasufell x11-plugins/purple-libnotify-plus 2012-09-12 21:36:43 hasufell x11-themes/ubuntu-wallpapers2012-09-15 14:06:58 pacho dev-ml/ocamlpam 2012-09-15 14:31:18 aballier dev-ml/ocamldap 2012-09-15 15:13:57 aballier app-misc/lfm2012-09-16 09:26:38 radhermit net-analyzer/alive 2012-09-16 14:17:34 jer dev-libs/intel-common 2012-09-16 19:10:55 jlec dev-python/ecdsa2012-09-16 20:05:55 blueness dev-python/slowaes 2012-09-16 20:24:22 blueness net-misc/electrum 2012-09-16 20:45:21 blueness -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-db/pgpool,removed,pacho,2012-09-16 12:21:52 dev-ruby/spruz,removed,pacho,2012-09-16 12:24:30 dev-util/pkg-config-lite,removed,pacho,2012-09-16 12:25:56 x11-misc/glipper,removed,pacho,2012-09-16 12:27:39 net-fs/mount-cifs,removed,pacho,2012-09-16 12:28:35 app-misc/jbidwatcher,removed,pacho,2012-09-16 12:35:22 app-laptop/lenovo-sl-laptop,removed,pacho,2012-09-16 12:37:49 dev-python/sexy-python,removed,pacho,2012-09-16 12:39:45 media-plugins/vdr-cdda,removed,pacho,2012-09-16 12:41:00 dev-ruby/Ruby-MemCache,removed,pacho,2012-09-16 12:41:47 x11-misc/transset-df,removed,pacho,2012-09-16 12:42:38 Added Packages: net-wireless/multimode,added,zerochaos,2012-09-10 02:22:38 net-wireless/gr-baz,added,zerochaos,2012-09-10 02:30:22 net-wireless/sdrsharp,added,zerochaos,2012-09-10 02:39:37 net-wireless/uhd,added,zerochaos,2012-09-10 03:13:47 dev-libs/liborcus,added,scarabeus,2012-09-10 09:17:40 media-sound/gnaural,added,miknix,2012-09-10 11:16:53 sys-firmware/ipxe,added,cardoe,2012-09-10 21:32:58 dev-perl/Tie-Cycle,added,tove,2012-09-11 03:14:04 dev-perl/Business-ISMN,added,tove,2012-09-11 03:21:08 dev-perl/Business-ISSN,added,tove,2012-09-11 03:31:54 dev-games/gigi,added,tomka,2012-09-11 15:57:21 games-strategy/freeorion,added,tomka,2012-09-11 16:01:06 dev-perl/Business-ISBN-Data,added,tove,2012-09-11 16:32:13 dev-perl/Business-ISBN,added,tove,2012-09-11 16:36:35 app-admin/gksu-polkit,added,tetromino,2012-09-12 11:57:26 net-im/purple-events,added,hasufell,2012-09-12 21:34:59 x11-plugins/purple-libnotify-plus,added,hasufell,2012-09-12 21:36:43 x11-themes/ubuntu-wallpapers,added,pacho,2012-09-15 14:06:58 dev-ml/ocamlpam,added,aballier,2012-09-15 14:31:18 dev-ml/ocamldap,added,aballier,2012-09-15 15:13:57 app-misc/lfm,added,radhermit,2012-09-16 09:26:38 net-analyzer/alive,added,jer,2012-09-16 14:17:34 dev-libs/intel-common,added,jlec,2012-09-16 19:10:55 dev-python/ecdsa,added,blueness,2012-09-16 20:05:55 dev-python/slowaes,added,blueness,2012-09-16 20:24:22 net-misc/electrum,added,blueness,2012-09-16 20:45:21 Done.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Sunday 16 September 2012 11:01:00 Alexis Ballier wrote: also, you are missing some bug # for the 'broken deps' part. packages that have gained broken deps when the profile was marked 'dev', or that you committed with your profile.desc locally modified, do not count and are your fault actually... wrong. if i'm version bumping a package and i see broken amd64-fbsd deps, that is not my problem. sounds like i'll simply de-keyword it in the future and let someone else pick up the pieces. do a repoman on the tree. there are multiple packages coming back right now with broken amd64-fbsd deps. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Sunday 16 September 2012 03:51:04 Brian Harring wrote:
+ if ! has $EAPI 0 1 2 3; then
+ eqawarn built_with_use should not be used in $EAPI; use USE
deps.
+ elif has $EAPI 2 3; then
+ if [[ $hidden == yes ]] || $missing_was_set; then
+ eqawarn built_with_use in EAPI=$EAPI without --missing
or --
hidden
usage, should use USE deps instead. +else
+ eqawarn built_with_use should not be used; upgrade to
EAPI=4
instead
+ fi
+ fi
i'd do:
case ${EAPI:-0} in
# No support in these EAPIs, so don't warn.
0|1) ;;
# Maybe warn as some functionality exist.
2|3) [[...]] eqawarn ... ;;
# Assume EAPI=4 or newer where all functionality exists.
*) eqawarn ... ;;
esac
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Sun, Sep 16, 2012 at 10:10:47PM -0400, Mike Frysinger wrote:
On Sunday 16 September 2012 03:51:04 Brian Harring wrote:
+ if ! has $EAPI 0 1 2 3; then
+ eqawarn built_with_use should not be used in $EAPI; use USE
deps.
+ elif has $EAPI 2 3; then
+ if [[ $hidden == yes ]] || $missing_was_set; then
+ eqawarn built_with_use in EAPI=$EAPI without --missing
or --
hidden
usage, should use USE deps instead. + else
+ eqawarn built_with_use should not be used; upgrade to
EAPI=4
instead
+ fi
+ fi
i'd do:
case ${EAPI:-0} in
# No support in these EAPIs, so don't warn.
0|1) ;;
# Maybe warn as some functionality exist.
2|3) [[...]] eqawarn ... ;;
# Assume EAPI=4 or newer where all functionality exists.
*) eqawarn ... ;;
esac
I'd be fine w/ it; worth noting, that was a 4am patch, so I'm not
claiming perfect implementatoin there. :)
My main focus here is switching built_with_use to actively nagging
people to stop using it; this includes nagging EAPI0/1 users of it.
Sans the implementation details, anyone got complaints with the
intent?
~brian
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
On Sep 16, 2012 4:55 PM, Brian Harring [1]ferri...@gmail.com wrote:
Folks-
Keeping it short and quick, a basic glep has been written for what
I'm
proposing for DEPENDENCIES enhancement.
The live version of the doc is available at
[2]http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
ndencies.html
Am I the only one who thinks that this dep:{build,...} thing looks
really ugly and is hard to read?
IMO simply removing the dep part would greatly improve things:
That 'dep' part isn't great, but it's added for a reason; to unify
with USE_EXPAND/use group intended syntax. There's a reference in
there to
http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which
I'll formalize soon enough.
DEPENDENCIES=
:build,run? ( ... )
:run? ( ... )
For your suggestion, consider it if we *do* fxi USE expand- via using
the same namespace:setting form.
Using app-admin/mcollective ad an example, it's deps are thus:
DEPEND=ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
RDEPEND=dev-ruby/stomp
ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
Which, if USE_EXPAND targets were groupped, would go from this
ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
dep:run? ( dev-ruby/stomp )
to this:
ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
:run? ( dev-ruby/stomp )
s/:/@/ would also be interesting
Just a note; the character choosen was *intentionally* one that isn't
a valid use character. @ is a valid character due to linguas. See
the thread I referenced (ciaran's response, then my response).
Short version; to use @, we need use subgroups; thus
linguas@ca@valencia .
DEPENDENCIES=
@build,run? ( ... )
@run? ( ... )
DEPENDENCIES=
ruby@targets_ruby18? ( dev-lang/ruby:1.8 )
ruby@targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
@run? ( dev-ruby/stomp )
Using equivalent syntax for mcollective.
I'm not a huge fan of dep:, and I'm a bit wary of a bare
@{run,test,whatever} since it carries with it an implicit this is
targetting the dep namespace.
That said, I'm not opposed to it- just as I said, I'm a bit wary at
first glance.
Comments?
~harring
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
Brian Harring wrote: Comments? : is used for namespaces elsewhere too. The familiarity is good. //Peter
Re: [gentoo-dev] Lastrites: media-libs/gmyth, media-plugins/gst-plugins-mythtv, net-libs/libmonetra, dev-php/pecl-mcve, dev-vcs/svk, net-im/jabberd, net-p2p/sancho-bin, media-sound/xfi-drivers, app-mi
Ben de Groot wrote: On 16 September 2012 23:40, Peter Stuge pe...@stuge.se wrote: Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (16 Sep 2012) # Upstream keeps inactive for ages and, then, it has broke again # now with gnutls-3 (#421385). Removal in a month. net-im/jabberd What about the 1.4 version? It depends on openssl, so maybe it doesn't have the gnutls issue. I kinda like jabberd. So step up and take on maintainership of that package. I would have, had I been a developer. I still haven't finished the recruitment process. It requires so much concentrated effort that it is a significant project which I can not fit into my schedule without cutting into too many other things. It's been that way for a few years now. Maybe something will change in Prague. //Peter
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sun, 2012-09-16 at 06:52 -0700, Brian Harring wrote: Folks- Keeping it short and quick, a basic glep has been written for what I'm proposing for DEPENDENCIES enhancement. The live version of the doc is available at http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html Wording fixes will occur, but the core concept shouldn't change (and if it does, per PEP standards, the changes will be noted/tracked). Please have a read through; it should be clear/concise as to why PM authors are pushing for a unified dependencies to be done, what we can get from it now, what it enables moving forward, and the direct cost to devs should this idea be implemented. Just to be absolutely clear, what I'm proposing is basically zero cost for devs- they can (and should when it's in their benefit) switch to the new syntax when it makes their job easier; it can be used in parallel to existing DEPEND/RDEPEND/PDEPEND both to ease transition/compatibility. In addition, a prototype portage patch has been cut for dependencies support (needs work/full validation), and a matching pkgcore one has been cut. I realize it's a complex subject; if you have questions, please feel to ask. Thanks, and pardon the ancillary/daft noise that has gone with this subject. ~harring I like the idea of a unified DEPENDENCIES. Potential flame wars aside, I also like the extended USE flag syntax approach. While it would be nice to loose the repetitive dep: portion, I can understand the importance of maintaining a namespace ID to prevent it from being injected where it does not belong. It adds to the consistency of the USE flag syntax while condensing the results. Reducing the size will help speed things along as well as reduce resource overhead (rsyncing the tree). I think it will be a good step forward in the evolution of gentoo. I would also put forth effort to help with tools to help devs migrate and check correctness before committing. -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
