Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Sun, 16 Sep 2012 19:41:14 -0700
Brian Harring ferri...@gmail.com wrote:
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?
How about raising the EAPI baseline from 0 to 2 - ie. every package may
use EAPI 2; not the same as deprecating 0 1 - and do:
case ${EAPI:-0} in
0|1|2|3|4) eqawarn From date onwards this will die ;;
*) die ... ;;
esac
as EAPI 2 supports the --missing case via constructs as:
|| (
=foo/bar-1
foo/bar-1[baz]
)
Almost all affected packages can be bumped straight to 4 anyway and
so use the improved syntax.
The aim would be to get rid of built_with_use not only in a distant
future. The corresponding bug [1] is from 2009 and can't be fixed
[1] https://bugs.gentoo.org/show_bug.cgi?id=261562
~brian
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, 17 Sep 2012 08:45:22 +0200 Ralph Sennhauser s...@gentoo.org wrote: The aim would be to get rid of built_with_use not only in a distant future. The corresponding bug [1] is from 2009 and can't be fixed ... without something like increasing EAPI baseline.
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
El lun, 17-09-2012 a las 07:56 +0200, Peter Stuge escribió: 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 I really doubt even oldest 1.4 version will have less unresolved bugs than current (already unmaintained and buggy) 1.6.x versions signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
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?
I have a concern about it, yes. But, maybe there's a good answer to my
concern, so please consider this a friendly ebuild development question
disguised as a complaint :)
Unless I'm missing something, it seems that once we deprive the ebuild
developer of this feature, there is no simple, supported way to retrieve
the information except to depend on it.
The issue is that calculating dependencies is not the only reason we
might want to know if a package was built with a particular USE-flag,
and if we get rid of built_with_use, we literally cut ourselves off from
retrieving this information in any officially sanctioned way (except to
DEPEND on it, which may not be semantically correct).
I can think of all kinds of legitimate reasons we might want to know if
the installed such-and-such package was built with so-and-so use-flags
without depending on it. i.e.:
o if the current gcc falls within a certain range of version
numbers and was built with graphite, we are going to trigger
a compiler bug. Suppose that there is no graphite support
or dependency in ${P}, and that we can apply a patch which will work
around the bug, but at a performance cost in ${P} we'd rather not
pay unless we have to.
o We need to modify a Makefile based on how a package we
BDEPEND on was built -- but suppose there is no BDEPEND
/limitation/ to enforce -- in other words, either way, our package
will build, and there is no correlating reverse dependency to worry
about at runtime.
Such needs are fairly unusual, but they do come up in real life.
My concern is that this will lead to people doing things like:
o cut-pasting the old implementation of built_with_use into ebuilds,
-- but that implementation will break if the portage database layout
changes
o creating bogus one-off use-flags as a way of performing these queries
(and, thanks to the upcoming requirement that USE flags
always appear in IUSE, exposing those flags to the end-user, perhaps
with some confusing description like whether such-and-such was
built with so-and-so).
o creating BDEPENDs of -- and sketchy parsers for -- portage-utils or
similar suites, just to ask this question.
Admittedly, it's hard to prevent people from doing
built-with-use foo/bar baz || die ${P} needs foo/bar with baz
since, once upon a time, that was SOP, and we'd have to parse the bash
code or something to qa warn for it automatically.
But any number of similar prohibitions are simply documented in the
developer handbook, including this one.
Am I missing something, here? I kinda think we should go the opposite
direction and un-deprecate the API. It seems like we are cutting off
our nose to spite our face here.
-gmt
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, 17 Sep 2012 00:58:02 -0700 Gregory M. Turner g...@malth.us wrote: Unless I'm missing something, it seems that once we deprive the ebuild developer of this feature, there is no simple, supported way to retrieve the information except to depend on it. has_version. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, 17 Sep 2012 00:58:02 -0700
Gregory M. Turner g...@malth.us wrote:
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?
I have a concern about it, yes. But, maybe there's a good answer to
my concern, so please consider this a friendly ebuild development
question disguised as a complaint :)
Unless I'm missing something, it seems that once we deprive the
ebuild developer of this feature, there is no simple, supported way
to retrieve the information except to depend on it.
The issue is that calculating dependencies is not the only reason we
might want to know if a package was built with a particular USE-flag,
and if we get rid of built_with_use, we literally cut ourselves off
from retrieving this information in any officially sanctioned way
(except to DEPEND on it, which may not be semantically correct).
I can think of all kinds of legitimate reasons we might want to know
if the installed such-and-such package was built with so-and-so
use-flags without depending on it. i.e.:
o if the current gcc falls within a certain range of version
numbers and was built with graphite, we are going to trigger
a compiler bug. Suppose that there is no graphite support
or dependency in ${P}, and that we can apply a patch which will
work around the bug, but at a performance cost in ${P} we'd rather not
pay unless we have to.
o We need to modify a Makefile based on how a package we
BDEPEND on was built -- but suppose there is no BDEPEND
/limitation/ to enforce -- in other words, either way, our package
will build, and there is no correlating reverse dependency to
worry about at runtime.
Such needs are fairly unusual, but they do come up in real life.
My concern is that this will lead to people doing things like:
o cut-pasting the old implementation of built_with_use into ebuilds,
-- but that implementation will break if the portage database
layout changes
o creating bogus one-off use-flags as a way of performing these
queries (and, thanks to the upcoming requirement that USE flags
always appear in IUSE, exposing those flags to the end-user,
perhaps with some confusing description like whether such-and-such
was built with so-and-so).
o creating BDEPENDs of -- and sketchy parsers for -- portage-utils
or similar suites, just to ask this question.
Admittedly, it's hard to prevent people from doing
built-with-use foo/bar baz || die ${P} needs foo/bar with baz
since, once upon a time, that was SOP, and we'd have to parse the
bash code or something to qa warn for it automatically.
But any number of similar prohibitions are simply documented in the
developer handbook, including this one.
Am I missing something, here? I kinda think we should go the
opposite direction and un-deprecate the API. It seems like we are
cutting off our nose to spite our face here.
-gmt
has_version foo/bar[baz] can be used in EAPI 2 and later.
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 17 September 2012 13:56, Peter Stuge pe...@stuge.se wrote: 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. You don't have to be a developer: http://www.gentoo.org/proj/en/qa/proxy-maintainers/ -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] DESCRIPTION=Based on the ${ECLASS} eclass
On Sat, Sep 15, 2012 at 8:59 AM, Michał Górny mgo...@gentoo.org wrote:
On Fri, 14 Sep 2012 19:43:42 -0400
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
On 09/14/2012 05:27 PM, Michał Górny wrote:
On Fri, 14 Sep 2012 17:18:16 -0400
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/14/2012 04:56 PM, Ciaran McCreesh wrote:
On Fri, 14 Sep 2012 16:51:54 -0400
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
I have a personal vendetta on this subject. Several eclasses set
a completely worthless description (and even more set a mostly
worthless DESCRIPTION) which ends up contaminating the
DESCRIPTION for an ebuild when inherit is done after DESCRIPTION
is set.
http://article.gmane.org/gmane.linux.gentoo.devel/78813/
I realize that most of you will find this a little pedantic,
however, I find that needing to move my DESCRIPTION to below the
inherit often severely affects the readability of the ebuild, and
all to avoid a completely (or nearly) worthless DESCRIPTION from
contaminating my environment.
You want your inherit line to be as near as the top as possible.
The only things you should have before the inherit line are EAPI
and any variables used by eclasses to determine behaviour.
I have a nasty habit of writing ebuilds to be both live and
versioned which requires me to test ${PV} then set things like
inherit VCS, SRC-URI, and KEYWORDS below. The large if block
looks better in my opinion below the settings which are the same
for all versions, rather than in the middle.
Yes, it's a readability issue, but the point is, this shouldn't be
an issue at all.
Use unifdef. Look at my overlay, and my ebuilds in the tree.
So just so we are clear, everyone but me thinks that
DESCRIPTION=Based on the ${ECLASS} eclass is a completely useful
and critically required piece of code?
No. We agree with you that it is useless but you are saying that with
a *completely* wrong reasoning.
Until that point I'll probably keep bringing this up.
Don't forget to threaten us that you'll leave Gentoo.
--
Best regards,
Michał Górny
This was uncalled-for. I see no such tone from his e-mails. We need no
more flames. We had enough of these already.
--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
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: I kinda like jabberd. So step up and take on maintainership of that package. I would have, had I been a developer. You don't have to be a developer: http://www.gentoo.org/proj/en/qa/proxy-maintainers/ And still be dependent on someone else? No, that's not the reason I use Gentoo. //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
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 really doubt even oldest 1.4 version will have less unresolved bugs than current (already unmaintained and buggy) 1.6.x versions Should you check that, before removing it? //Peter pgp8xeJopDAXs.pgp Description: PGP signature
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On 9/17/2012 1:00 AM, Ciaran McCreesh wrote: On Mon, 17 Sep 2012 00:58:02 -0700 Gregory M. Turner g...@malth.us wrote: Unless I'm missing something, it seems that once we deprive the ebuild developer of this feature, there is no simple, supported way to retrieve the information except to depend on it. has_version. On 9/17/2012 1:10 AM, Ralph Sennhauser wrote: On Mon, 17 Sep 2012 00:58:02 -0700 has_version foo/bar[baz] can be used in EAPI 2 and later. oh, duh... I guess I was just conflating the two, sorry for the noise :) -gmt
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sep 17, 2012 6:13 AM, Brian Harring ferri...@gmail.com wrote:
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 )
Ok, now I get it. I've read the other threads as well, but failed to put it
all together. Happens when you barely sleep every night :-)
I don't like this mix of dependency types and use flag deps. It smells
trouble. Dependency types should be easy to separate and read, but the
above example is a mess, dep: or no dep:.
Why? Because you have to scan the whole thing to sort out which lines are
dependency types and which lines are use deps and even then it would be
easy to misread something.
If we want to stay away from labels (which aren't that bad IMO), I'd
recommend the following instead:
Force explicit setting of the dependency type and disallow the mix of
dependency types and use flag deps at the same level / block.
DEPENDENCIES=
:build,run? ( lib/foo )
:run? (
lib/bar
someuseflag? ( random/app )
)
:*? (
thing? (
:build? ( lib/thing )
:run? ( lib/thingrunner )
)
Or, using your example:
:build,run? (
ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
)
:run? ( dev-ruby/stomp )
Alex | wired
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On 17 September 2012 18:55, Alex Alexander alex.alexan...@gmail.com wrote:
On Sep 17, 2012 6:13 AM, Brian Harring ferri...@gmail.com wrote:
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 )
Ok, now I get it. I've read the other threads as well, but failed to put it
all together. Happens when you barely sleep every night :-)
I don't like this mix of dependency types and use flag deps. It smells
trouble. Dependency types should be easy to separate and read, but the above
example is a mess, dep: or no dep:.
Why? Because you have to scan the whole thing to sort out which lines are
dependency types and which lines are use deps and even then it would be easy
to misread something.
If we want to stay away from labels (which aren't that bad IMO), I'd
recommend the following instead:
Force explicit setting of the dependency type and disallow the mix of
dependency types and use flag deps at the same level / block.
DEPENDENCIES=
:build,run? ( lib/foo )
:run? (
lib/bar
someuseflag? ( random/app )
)
:*? (
thing? (
:build? ( lib/thing )
:run? ( lib/thingrunner )
)
Or, using your example:
:build,run? (
ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
)
:run? ( dev-ruby/stomp )
Alex | wired
Or, even easier and more straightforward: just keep using *DEPEND. The
case hasn't been made yet why we need to change that in the first
place.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
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 17/09/12 12:03, Peter Stuge 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 really doubt even oldest 1.4 version will have less unresolved bugs than current (already unmaintained and buggy) 1.6.x versions Should you check that, before removing it? That would be a job for the maintainer of the package, not member of the treecleaners... -Samuli
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Sun, 16 Sep 2012 22:06:19 -0400 Mike Frysinger vap...@gentoo.org wrote: 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. why do you want to treat amd64-fbsd different than other arches ? just to make the work of those that want to maintain that arch a pain ? you know, standard procedure is to drop keywords and file a bug when a new dep comes in a new version. deps that are _already_ broken should not happen because, heh, the profile is marked stable... in case this happens there's nothing sane to do, better use repoman --force and file an urgent bug to the arch team. do a repoman on the tree. there are multiple packages coming back right now with broken amd64-fbsd deps. if people do not file bugs and think it's fine to commit packages with broken deps, or silently dekeyword just because they can like you suggested in the first paragraph, this will not change anytime soon. and no thanks, i wont be doing repoman checks on the tree, i had been doing this for x86-fbsd, spending hours fixing the mess i could, and had to re-do it every couple of months because every other dev was committing packages with broken deps. now, would you please file bugs when you see such broken packages and let the keywording level be sanitized ? thanks
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Mon, 17 Sep 2012 19:49:12 +0800 Ben de Groot yng...@gentoo.org wrote: Or, even easier and more straightforward: just keep using *DEPEND. The case hasn't been made yet why we need to change that in the first place. We're looking at something like eight *DEPEND variables in EAPI 6, with considerable overlap between them all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On 17 September 2012 20:41, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 17 Sep 2012 19:49:12 +0800 Ben de Groot yng...@gentoo.org wrote: Or, even easier and more straightforward: just keep using *DEPEND. The case hasn't been made yet why we need to change that in the first place. We're looking at something like eight *DEPEND variables in EAPI 6, with considerable overlap between them all. And like now, in the great majority of cases, only two or three will be used. The enormous cost of moving to a different system (or the folly of using two systems in parallel) is not worth the slight benefit of a more cosmetic handling of the few cases where a few more *DEPEND variables would be needed and/or there is some overlap to be dealt with. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Mon, 17 Sep 2012 21:48:07 +0800 Ben de Groot yng...@gentoo.org wrote: On 17 September 2012 20:41, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 17 Sep 2012 19:49:12 +0800 Ben de Groot yng...@gentoo.org wrote: Or, even easier and more straightforward: just keep using *DEPEND. The case hasn't been made yet why we need to change that in the first place. We're looking at something like eight *DEPEND variables in EAPI 6, with considerable overlap between them all. And like now, in the great majority of cases, only two or three will be used. And even now, people are using COMMON_DEPEND to work around *DEPEND duplication. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On 17 September 2012 21:58, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 17 Sep 2012 21:48:07 +0800 Ben de Groot yng...@gentoo.org wrote: On 17 September 2012 20:41, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 17 Sep 2012 19:49:12 +0800 Ben de Groot yng...@gentoo.org wrote: Or, even easier and more straightforward: just keep using *DEPEND. The case hasn't been made yet why we need to change that in the first place. We're looking at something like eight *DEPEND variables in EAPI 6, with considerable overlap between them all. And like now, in the great majority of cases, only two or three will be used. And even now, people are using COMMON_DEPEND to work around *DEPEND duplication. Yes, and that works just fine. I don't see what's wrong with that... -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Mon, 17 Sep 2012 22:11:59 +0800 Ben de Groot yng...@gentoo.org wrote: And even now, people are using COMMON_DEPEND to work around *DEPEND duplication. Yes, and that works just fine. I don't see what's wrong with that... Well perhaps you should read Brian's lengthy explanation that started this thread, then. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Mon, Sep 17, 2012 at 9:48 AM, Ben de Groot yng...@gentoo.org wrote:
On 17 September 2012 20:41, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Mon, 17 Sep 2012 19:49:12 +0800
Ben de Groot yng...@gentoo.org wrote:
Or, even easier and more straightforward: just keep using *DEPEND. The
case hasn't been made yet why we need to change that in the first
place.
We're looking at something like eight *DEPEND variables in EAPI 6, with
considerable overlap between them all.
And like now, in the great majority of cases, only two or three will be used.
The enormous cost of moving to a different system (or the folly of using
two systems in parallel) is not worth the slight benefit of a more cosmetic
handling of the few cases where a few more *DEPEND variables would be
needed and/or there is some overlap to be dealt with.
As someone who's been reading these threads, but hasn't actually
written any ebuilds from scratch, I'd like to offer my perspective as
a well-intentioned beginner:
On labels: The labels, to me, appeared largely more readable (and less
formidable a syntax to read and write as a human) than the foo? (
bar/baz ) syntax...until someone demonstrated a distinction between
depends and dependency types. I hadn't even noticed a distinction
between the two, until that point was raised.
While I like the labels (to me, they feel similar to Makefiles or C
switch statements), a clearer distinction between dependencies and
dependency types would be nice.
On unified DEPENDS vs *DEPEND: It seems to me that at a code level,
there's no real semantic difference. Since they both parse out
losslessly to the same abstract thing, you could serialize that
abstract thing back out into either format. Given most cases will be
simple, you could even serialize it away into something not
bash-based, if desired. All this means, to me, that the behavior of
the two under the hood is essentially irrelevant, and any bugs in
complex implementation could be caught with automated testing.
I personally favor a singular 'DEPENDS', because
1) I feel it would lead to better-organized documentation (I'm looking
for details about one var, rather than two or three vars--oh and then
there's the other N *DEPENDS I may not even have heard of yet), and
2) I worry less about accidental namespace pollution in my make.conf
file. Why do I worry about namespace pollution? Rather than using
profiles, I have around 40-50 USE flags divided by category into
varnames like SYS_USE_COMPRESION, and then I have a line that says
USE=${SYS_USE_CPU} ${SYS_USE_COMPRESSION} ${SYS_USE_DONOTWANT} # etc
which coalesces it all. When I ran into a strange problem some time
back, someone assisting me initially suspected that my SYS_USE_* vars
might be conflicting with something internal to portage.
Again, this isn't coming from a seasoned developer, this is coming
from a well-intentioned beginner with very little time on his hands.
--
:wq
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 Mon, Sep 17, 2012 at 5:02 AM, Peter Stuge pe...@stuge.se wrote: Ben de Groot wrote: I kinda like jabberd. So step up and take on maintainership of that package. I would have, had I been a developer. You don't have to be a developer: http://www.gentoo.org/proj/en/qa/proxy-maintainers/ And still be dependent on someone else? No, that's not the reason I use Gentoo. Well, as a user there are only two ways to get or keep your favorite package in the tree: 1. Get a developer to maintain it. 2. Get a proxy-maintainer to maintain it. That's it. Whether you pay them, beg, appeal to their God, or whatever, if you don't do one or the other your package will get pruned eventually. If your favorite package isn't in the tree you can: 1. Keep your own ebuild in /usr/local/portage or whatever. 2. Publish your own overlay. 3. Use somebody else's overlay. 3a. Use sunrise. You're never forced to stay in-tree, though you'll find that your life might be easier if you do (more eyeballs, if somebody renames a dep or does something big to the tree they'll fix your ebuild for you, etc). I don't think there is any realistic alternative. Our users expect packages in the tree to meet basic QA standards, which requires maintainers. Other distros use similar approaches - in fact it seems like if anything Gentoo keeps quite a bit of stuff in the main tree that many other distros push out into their equivalents of overlays. Rich
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
Rich Freeman wrote: Well, as a user there are only two ways to get or keep your favorite package in the tree: .. If your favorite package isn't in the tree you can: .. I know all this, and I have my own overlay because I'm not a developer. I was just saying that proxy-maintaining isn't relevant for me. //Peter
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On 17 September 2012 22:14, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 17 Sep 2012 22:11:59 +0800 Ben de Groot yng...@gentoo.org wrote: And even now, people are using COMMON_DEPEND to work around *DEPEND duplication. Yes, and that works just fine. I don't see what's wrong with that... Well perhaps you should read Brian's lengthy explanation that started this thread, then. If you mean the email that started this thread, that was neither lengthy nor explanatory. If you mean the GLEP, that is indeed lengthy, but mostly goes into the mechanism. It doesn't go into the rationale to any degree of satisfaction. It doesn't make at all clear why the supposed benefits would outweigh the costs of such a big change. If I missed any such explanation among the myriad of related threads, then please be so kind to link to it. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Sun, 16 Sep 2012 22:06:19 -0400 Mike Frysinger vap...@gentoo.org wrote: 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. now that the repoman run has finished, lets analyze it: dev-vcs/git/git-1.7.12-r2.ebuild: ~amd64-fbsd(default/bsd/fbsd/amd64/9.0) ['app-text/highlight'] x11-base/xorg-drivers/xorg-drivers-1.13.ebuild: ~amd64-fbsd(default/bsd/fbsd/amd64/9.0) ['x11-drivers/xf86-video-chips', 'x11-drivers/xf86-video-rendition', 'x11-drivers/xf86-video-tseng'] both added and unnoticed when the profile was marked as dev net-misc/wget/wget-1.14.ebuild: ~amd64-fbsd(default/bsd/fbsd/amd64/9.0) ['sys-apps/util-linux'] bumped by you, earlier, probably when you made your local change. util-_linux_ not being keyworded on fbsd is not what I would call a broken dep. uuid functions are provided by either e2fsprogs-libs or the libc on freebsd. maybe it would be a good idea to drop keywords and ask for rekeywording to the arch team in that case ?
[gentoo-dev] netqmail-1.06 install phase failure -- bugzilla 435334
Installing mail-mta/netqmail-1.06 into a gentoo amd64 stable system fails during the install/setup phase apparently due to a change in the arguments of /usr/bin/queue-repair.py Gentoo Bugzill # 435334 submitted and all available information attached. -- G.Wolfe Woodbury redwo...@gmail.com
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
El lun, 17-09-2012 a las 14:47 +0300, Samuli Suominen escribió: On 17/09/12 12:03, Peter Stuge 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 really doubt even oldest 1.4 version will have less unresolved bugs than current (already unmaintained and buggy) 1.6.x versions Should you check that, before removing it? That would be a job for the maintainer of the package, not member of the treecleaners... -Samuli You also would need to provide a fix for existing bug, not keep it as-is forever signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, Sep 17, 2012 at 08:45:22AM +0200, Ralph Sennhauser wrote:
On Sun, 16 Sep 2012 19:41:14 -0700
Brian Harring ferri...@gmail.com wrote:
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?
How about raising the EAPI baseline from 0 to 2 - ie. every package may
use EAPI 2; not the same as deprecating 0 1 - and do:
case ${EAPI:-0} in
0|1|2|3|4) eqawarn From date onwards this will die ;;
*) die ... ;;
esac
as EAPI 2 supports the --missing case via constructs as:
|| (
=foo/bar-1
foo/bar-1[baz]
)
I'd rather be more aggressive on this one, actually; either way, for
herds/devs, a full scan of the tree was done to identify what invokes
bulit_with_use whether directly, or indirectly via invoking a function
that does.
Resultant logs/tree is at
http://dev.gentoo.org/~ferringb/built_with_use-cleanup/ .
For the 'env' files that are nestled away in there, that's a pkgcore
dump of the environment of the ebuild post sourcing for ease of
tracing how built_with_use was actually invoked.
Sidenote, if in looking at the env dumps you see something that looks
like it shouldn't be saved, let me know- I'm generally pretty anal
about trying to ensure nothing pkgcore related is accessible by
ebuilds/eclasses, nor saved to the env.
Almost all affected packages can be bumped straight to 4 anyway and
so use the improved syntax.
~11% already are EAPI4, just triggered via eclass pathways.
Either way, herds, please take a look- the views should make it easy
for y'all to trace down the offenses and deal with them.
~harring
Re: [gentoo-dev] making USE=upnp a global flag
Le samedi 08 septembre 2012 à 20:29 +0200, Michał Górny a écrit : On Sat, 8 Sep 2012 10:37:49 -0700 Mike Frysinger vap...@gentoo.org wrote: i'm surprised this hasn't happened already. currently at 18 users (and i'm adding another), so time to make global. i'll use the description: upnp: Enable support for the Universal Plug and Play (UPnP) network protocol Not sure about that description. It's whole stack of protocols which usually benefit from more refined description. On the other hand, the local descriptions in the tree show that some people simply don't care and you are guessing what it does anyway... Enable support for DLNA/UPnP seems a good enough description. People that care about it most likely will know two things about it: * opens up ports on the router for torrents/games * makes PC talk to TV/console for audio/video I'll admit this does not fit tracker but that's because I wasn't inspired when I had to find a USE flag to select a video metadata extractor :). -- Gilles Dartiguelongue e...@gentoo.org Gentoo
[gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, Sep 17, 2012 at 08:45:22AM +0200, Ralph Sennhauser wrote: Almost all affected packages can be bumped straight to 4 anyway and so use the improved syntax. toolchain_src_compile: EAPI=0: count: 38 I'm not sure this can change any time soon. :/ -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
[gentoo-dev] Re: GLEP: gentoo sync based unified deps proposal
On Sun, 16 Sep 2012 06:52:11 -0700 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 *stamp* Ship it! -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
A potential dev-libs/dep package might have valid use case for USE flags related to USE_EXPAND=DEP. Your suggested syntax for types of dependencies in DEPENDENCIES would conflict with these USE flags after implementing : delimiter for USE_EXPAND-related USE flags. I vote for a separate syntax for types of dependencies. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
