Re: [gentoo-dev] Ideas for a (fast) EAPI=3
В Чтв, 09/04/2009 в 15:32 +0100, Ciaran McCreesh пишет: Please provide a list of packages that use custom configure scripts, that currently work with econf (including all the weird things it already passes), that would break with this change and whose ebuilds are using econf. I have yet to see any examples provided. Only one package fail completely here: dev-libs/elfutils. But there are much more packages which does not fail but issue warning about unsupported option. -- Peter.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On N, 2009-04-09 at 10:37 +0200, Tiziano Müller wrote: properties must be cached properly == No opinion, up to the package manager developers. Don't see offhand why it should be an EAPI item at all. Feels like an implementation detail. The metadata cache needs to be specified to make it work with compliant PM's and is therefore a part of the PMS. A change is therefore required to be done on a per-EAPI base. But the metadata cache isn't per-EAPI in the sense of multiple metadata caches, one for each EAPI. There might be per-EAPI metadata cache items though. Anyhow, if zmedico is cool with it, I'm cool. Limit values in $USE to ones in $IUSE: == Seems more of a QA test, but forcing it can make it be caught at start. Don't see why it must be an EAPI item. Just vet the tree of (future?) repoman warnings about it and make it happen for all EAPIs. Impact on overlays is minimal because it is a QA error to not define them and they get what they asked for. Not strongly opposed to it being in the EAPI. Why it has to be done in an EAPI: It matters whether you have to put for example userland_GNU in IUSE if you want to use it in the ebuild or not. I don't think I want to have to specify userland_GNU and co in IUSE. They aren't USE flags that get set by the user, so having to put them in IUSE isn't intuitive either. --disable-dependency-tracking: == possible breakage of (custom) configure scripts that don't accept unknown arguments. Would be nice to pass that for most packages, but doing it always with econf seems slightly inappropriate, given the above. Don't think this is an item for fast-tracked EAPI-3. custom configure scripts mostly already break with econf, so not an issue. Some might accept all current switches we pass with econf, but not --disable-dependency-tracking. Maybe if there's a way to opt out of the --disable-dependency-tracking when necessary... the unlikely need for that will get seen by the maintainer when he/she upgrades the ebuild to EAPI-3. econf is a complex and long (many arguments passed) beast to replicate just without --disable-dependency-tracking ban || ( foo? ( . ) . ) === It is not the business of an EAPI to start disallowing *DEPEND string constructs. It's EAPI's business to define what's valid and what is not. We disagree there. Things should be an EAPI item when it is reasonably required to be. In this case a simple repoman warning on such a construct suffices. There is no useful alternative provided yet to my knowledge and this is really a QA issue, not an EAPI issue. The problem is that there is no valid use case to justify the existence of this construct. In either way users will most likely not have what they want if || ( foo? ( . ) . ) is being used. Disallowing it will therefore help the user to get what the specified and is therefore a good thing. Then we should disallow all constructs that currently give a repoman warning as well? It is a QA issue to me, not something to overload an EAPI with. QA warning for all EAPI's. Not convinced on the sub-optimal use case being the only one, either. Strongly objecting on the grounds that it is not something that should be an EAPI issue. unpack has to handle more types === Would be nice to get a QA warning when unpacking .lzma, .xz, etc that need a build depend for the unpacker and don't have it yet. Then sounds fine. But you don't want unpack fail on unknown types? Seems a bit inconsequent. Unknown types in this case is about not packed at all. Or we could define those types - .patch, .bin, etc PM knows that there's .lzma, .xz and so on, so it could know which build-time deps are necessary - repoman warning anyhow, later some alternative unpacker might surface. Did I miss anything? I'm not even sure anymore where to find a list of items that is current for what's on the table for EAPI-3 right now... The PMS. (just do emerge pms for an up-to-date version). that's a bit complicated with not having texlive installed anywhere yet... -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 09 Apr 2009 04:51:06 +0300 Mart Raudsepp l...@gentoo.org wrote: doins support for symlinks == Lacking information. Need to see if the PMS draft has anything about it. The bug and summaries just talk about the support, but no details. Would it be an argument to doins? The PMS draft explains it. It's simple, though: currently, doins on a symlink does something arbitrary. We want it to install the symlink. unpack failing on unknown types === Uncertain about it's worthiness. Might rather have the opposite with a --strict argument kind of deal. No official objection from me. What with the moving towards auto-die, the trend is towards strict unless explicitly told not to be. properties must be cached properly == No opinion, up to the package manager developers. Don't see offhand why it should be an EAPI item at all. Feels like an implementation detail. The cache format's tied to EAPI in a fairly unpleasant manner. It's a necessary evil. DEFINED_PHASES must be supported (and cached properly) == No opinion, up to the package manager developers more or less. Not sure why this needs to be an EAPI item. Hard to see a use case for the variable being available for ebuild usage for it to be necessary to be an EAPI item. DEFINED_PHASES isn't available to the ebuild. But it is in the metadata cache, which PMS has to cover. By my understanding it is (also?) a required implementation detail to handle pkg_pretend sanely and with minimal time hit. Correct. Without it there's a delay of ~0.1s per ebuild in the resolution set at pretend time, which soon adds up for certain reasonably common use cases. Limit values in $USE to ones in $IUSE: == Seems more of a QA test, but forcing it can make it be caught at start. Don't see why it must be an EAPI item. Just vet the tree of (future?) repoman warnings about it and make it happen for all EAPIs. Impact on overlays is minimal because it is a QA error to not define them and they get what they asked for. It needs to be in EAPI because we're talking about changing how the ebuild environment is specified. Also, repoman can't catch most accidental abuses of this. --disable-dependency-tracking: == possible breakage of (custom) configure scripts that don't accept unknown arguments. Would be nice to pass that for most packages, but doing it always with econf seems slightly inappropriate, given the above. Please provide a list of packages that use custom configure scripts, that currently work with econf (including all the weird things it already passes), that would break with this change and whose ebuilds are using econf. I have yet to see any examples provided. utility commands should die by default == Would like to see a list of those utility commands that would be made to die by default. The PMS draft has one. ban || ( foo? ( . ) . ) === It is not the business of an EAPI to start disallowing *DEPEND string constructs. There is no useful alternative provided yet to my knowledge and this is really a QA issue, not an EAPI issue. There is no use case for the construct anyway. Not convinced on the sub-optimal use case being the only one, either. Strongly objecting on the grounds that it is not something that should be an EAPI issue. Behaviour of || ( foo? ( . ) ) is already an EAPI issue, and has a horrible section of PMS devoted to explaining its quirky behaviour. I'm not even sure anymore where to find a list of items that is current for what's on the table for EAPI-3 right now... Do a git log on the PMS draft (or look at the summary table in the appendix). It's fairly close to one commit per EAPI item. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 09 Apr 2009 13:44:55 +0300 Mart Raudsepp l...@gentoo.org wrote: But the metadata cache isn't per-EAPI in the sense of multiple metadata caches, one for each EAPI. There might be per-EAPI metadata cache items though. The cache format is per-EAPI, with a degree of overlap. I don't think I want to have to specify userland_GNU and co in IUSE. They aren't USE flags that get set by the user, so having to put them in IUSE isn't intuitive either. And with the proposal as currently worded, you don't have to. The profiles do that magically for you. Some might accept all current switches we pass with econf, but not --disable-dependency-tracking. 'might'? Have you found any? Given the mess econf currently passes, it strikes me as highly unlikely. Then we should disallow all constructs that currently give a repoman warning as well? We should disallow constructs that can't be used correctly, if allowing them is a significant burden on the package manager. Unknown types in this case is about not packed at all. Or we could define those types - .patch, .bin, etc PM knows that there's .lzma, .xz and so on, so it could know which build-time deps are necessary - repoman warning anyhow, later some alternative unpacker might surface. Uh. Unknown types doesn't mean fail on lzma if lzma's not installed. Please check the PMS draft for what it does mean. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Hello, On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote: With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Please discuss. Sorry for getting my points of discussion on the details to the list so late. I have covered some of my concerns on the items in meetings and otherwise on IRC, but now I'll try to get to them in further detail and better wording to the mailing list. I'm going to go item-by-item here for the things I don't expect much replies to, and then starting separate threads for those that I do. pkg_pretend === No objections. Gives an intermediate step for handling USE flag combination incompatibilities at pretend stage (to not find it failed in the morning), yet has uses outside that as well. So, once there is a way to express those kind of USE flag dependencies outside of pkg_pretend in a better way in a future EAPI, pkg_pretend will still be useful for other (less common) cases and can provide a description of the problem to the user. Use based deps with non-existing USE flags == No objections. Implements the missing bit of built_with_use --missing Main driving force behind EAPI-3. default src_install === No considerable input yet, catching up with the latest thread about src_install bikeshedding doinclude = Unnecessary. Might be interesting for automatic executable permission removing, but upstream build systems should be fixed instead for such a big and rare error. ban dosed = I don't exactly see a reason for the banning yet, but no objections due to general agreement on it and having no technical objections doins support for symlinks == Lacking information. Need to see if the PMS draft has anything about it. The bug and summaries just talk about the support, but no details. Would it be an argument to doins? unpack failing on unknown types === Uncertain about it's worthiness. Might rather have the opposite with a --strict argument kind of deal. No official objection from me. docompress == Need some more time to digest through it in relation to PORTAGE_COMPRESS, prepalldocs and co. Will try to follow-up before meeting. properties must be cached properly == No opinion, up to the package manager developers. Don't see offhand why it should be an EAPI item at all. Feels like an implementation detail. DEFINED_PHASES must be supported (and cached properly) == No opinion, up to the package manager developers more or less. Not sure why this needs to be an EAPI item. Hard to see a use case for the variable being available for ebuild usage for it to be necessary to be an EAPI item. By my understanding it is (also?) a required implementation detail to handle pkg_pretend sanely and with minimal time hit. Limit values in $USE to ones in $IUSE: == Seems more of a QA test, but forcing it can make it be caught at start. Don't see why it must be an EAPI item. Just vet the tree of (future?) repoman warnings about it and make it happen for all EAPIs. Impact on overlays is minimal because it is a QA error to not define them and they get what they asked for. Not strongly opposed to it being in the EAPI. --disable-dependency-tracking: == possible breakage of (custom) configure scripts that don't accept unknown arguments. Would be nice to pass that for most packages, but doing it always with econf seems slightly inappropriate, given the above. Don't think this is an item for fast-tracked EAPI-3. utility commands should die by default == Would like to see a list of those utility commands that would be made to die by default. ban || ( foo? ( . ) . ) === It is not the business of an EAPI to start disallowing *DEPEND string constructs. There is no useful alternative provided yet to my knowledge and this is really a QA issue, not an EAPI issue. Not convinced on the sub-optimal use case being the only one, either. Strongly objecting on the grounds that it is not something that should be an EAPI issue. unpack has to handle more types === Would be nice to get a QA warning when unpacking .lzma, .xz, etc that need a build depend for the unpacker and don't have it yet. Then sounds fine. In separate threads: * Slot operator support * dohard being deprecated Did I miss anything? I'm not even sure anymore where to find a list of items that is current for what's on the table for EAPI-3 right
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 2009-04-09 at 04:51 +0300, Mart Raudsepp wrote: --disable-dependency-tracking: == possible breakage of (custom) configure scripts that don't accept unknown arguments. Would be nice to pass that for most packages, but doing it always with econf seems slightly inappropriate, given the above. Don't think this is an item for fast-tracked EAPI-3. I'm not a big fan either of this one either, when stuff is patched, you may not want that disabled. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 08:49:16 +0100 Tiziano Müller dev-z...@gentoo.org wrote: So I think it's time for a short eapi bump with some distinct improvements: Some more small candidates to discuss: * How would people feel about killing off automagic RDEPEND=DEPEND behaviour? * Officially kill off AA. It's not useful. * Kill off KV. This should be eclass territory. * Ban dohtml, which is weird, and add '-u dir' to dodoc, so you can use dodoc -r -u html blah instead. * We currently have .xz / .tar.xz support for unpack down for EAPI 3. Am I right in thinking there's nothing stable that can handle .xz files? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Freitag, den 13.03.2009, 20:11 + schrieb Ciaran McCreesh: On Sun, 08 Mar 2009 08:49:16 +0100 Tiziano Müller dev-z...@gentoo.org wrote: So I think it's time for a short eapi bump with some distinct improvements: Some more small candidates to discuss: * How would people feel about killing off automagic RDEPEND=DEPEND behaviour? * Officially kill off AA. It's not useful. Never used it, thus ++ * Kill off KV. This should be eclass territory. ++ * Ban dohtml, which is weird, and add '-u dir' to dodoc, so you can use dodoc -r -u html blah instead. But then we shouldn't introduce doexample, but use dodoc -r -u examples instead. I liked that dohtml can filter based on file endings, this made it in the past easier to install html docs. So, if we could have something like: filter_files -t web docs/ | dodoc -r -u html that would be fine :-) * We currently have .xz / .tar.xz support for unpack down for EAPI 3. Am I right in thinking there's nothing stable that can handle .xz files? As far as I know, but vapier is probably the expert here. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 22:53 Mon 09 Mar , Ciaran McCreesh wrote:
On Mon, 9 Mar 2009 15:39:41 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
* Calling unpack on an unrecognised extension should be fatal,
unless --if-compressed is specified. The default src_unpack needs
to use this.
Why?
Currently, if a package does an explicit 'unpack foo.bar', where .bar is
an unsupported archive format, unpack just does nothing. This isn't a
good default behaviour; if a package really wants something to be
ignored silently, it should have to say so.
I like it when unpack ${A} works regardless of what's in SRC_URI,
especially if it's an uncompressed file rather than an unsupported
compression format.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpHnu7zpMu45.pgp
Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 12 Mar 2009 11:43:58 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
Currently, if a package does an explicit 'unpack foo.bar',
where .bar is an unsupported archive format, unpack just does
nothing. This isn't a good default behaviour; if a package really
wants something to be ignored silently, it should have to say so.
I like it when unpack ${A} works regardless of what's in SRC_URI,
especially if it's an uncompressed file rather than an unsupported
compression format.
You'd have to do unpack --if-compressed ${A} to get that behaviour.
It's sometimes handy to have, and of course it's necessary for
default_src_unpack, but silently ignoring duff inputs isn't very
Unixy or very software engineeringy...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
No idea whether it's fast idea, but:
- USE flags aliases
This could solve problems with USE flag name changes and breaking dependency
tree because of it.
Placed, let's say in profiles/{use.aliases,use.local.aliases}
example - use.aliases: (no idea whether global aliases are really needed)
# global_use_flag - alias1 alias2 ...
xml - libxml2
example - use.local.aliases: (more real-world scenario)
# local_use_flag - alias1 alias2 ...
dev-libs/soprano:sesame2 - java
media-video/transcode:dvdread - dvd
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Fri, 13 Mar 2009 00:05:54 +0100 Maciej Mrozowski reave...@poczta.fm wrote: No idea whether it's fast idea, but: - USE flags aliases Aliases for anything aren't fast or easy. The big problem is this: the interactions between installed packages and the main repository, and between the main repository and overlays, get very messy. Working out exactly what happens when aliases disappear or are inconsistent gets to be rather tricky. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Mon, 2009-03-09 at 15:39 -0700, Donnie Berkholz wrote: * Utility commands, even the ones that aren't functions, should die. To get a non-die version, prefix the command with nonfatal (e.g. 'nonfatal dodoc README', which just returns non-zero on failure rather than splatting). Sounds useful to have less '|| die' all over the place. Whats wrong with 'set -e' and doing '|| true' behind? IMO this would feel more shell-ish. /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Tue, 10 Mar 2009 10:08:06 +0100 Michael Haubenwallner ha...@gentoo.org wrote: Whats wrong with 'set -e' and doing '|| true' behind? Waaay too many false positives. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller dev-z...@gentoo.org wrote:
With eapis 1 and 2 we introduced nice features but also a couple of
new problems. One of them are the use dependencies when the package
you depend on doesn't have the use flag anymore (see [1] for an
example).
Here's another one to consider:
If S= is wrong (which it often is, for packages with icky tarballs),
src_configure and src_compile won't error out. These days this isn't a
huge deal, because your custom src_install will probably fail. But if
we're introducing a default src_install, it will instead see no
Makefile and just do nothing, resulting in an empty package being
installed.
Currently, at the start of src_configure, the package manager does a cd
to ${S} if ${S} exists, and to ${WORKDIR} otherwise. I'd like to
propose that ${S} not existing should instead be an error if either of
the following conditions are met:
* ${A} is non-empty
* Any of src_unpack, src_configure, src_compile or src_install is a
defined phase.
Ebuilds where this would trigger a false positive would have to specify
S=${WORKDIR}.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Monday March 09 Ciaran McCreesh wrote: * src_test run unless RESTRICTed or explicitly disabled by the user (bug 184812) Yes, and I would go even further: keep src_test for unit tests and some kind of pkg_posttest for either a routine to test the package once installed or an elog test recipe, a bit like the emacs testing plans. It could be useful for arch testers, guis, and revdep tests. It would force packagers to define an omitted src_test when upstream actually had one. As mentioned by Christian, src_test is desirable in sci packages to get consistent results, but sci packages depend on lots of others, so you can't limit tests to some categories. And yes, you can't revdep test everything, but you can reduce bug load. It seems to be controversial, so unfortunately does not look like a good candidate for a flash EAPI upgrade. But really, don't dismiss it just because your pet package doesn't pass tests or it takes too long. One solution for packages taking too long to compile is not dismissing tests but a good binary package system. -- Sébastien signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Mon, Mar 9, 2009 at 3:26 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 08 Mar 2009 08:49:16 +0100 Tiziano Müller dev-z...@gentoo.org wrote: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Here're some more easy ones. First up, un-optionaling some optional things. No impact for developers: * PROPERTIES must be cached properly (it's optional in current EAPIs) +1 from me * DEFINED_PHASES must be supported (ditto) +1 from me Next, some probably easy but long standing features: * src_test run unless RESTRICTed or explicitly disabled by the user (bug 184812) I'd love to but please look at the most recent comment I've made on the bug * have econf run ./configure with --disable-dependency-tracking and --enable-fast-install (bug 211529) +1 from me. Did we ever test autoconf 2.13 based stuff? * Limit values in $USE to ones in $IUSE (bug 176467). The existing behaviour's majorly annoying; time for the package manager to start enforcing things strictly. definitely +1 from me. I've been trying to put kernel_linux and such in my ebuilds already to improve this. Some things we should probably sort out: * The list of extensions for unpack probably needs a couple of new things. We also need a way for the actual program being used for the unpack to be added to DEPEND. * Provide ebuilds a way to differentiate between updates and removals (bug 205557), since the way devmanual says to do it got broken by a non-EAPIed change. This one's slightly trickier than initially apparent, because a solution's needed for the weird cases. One example is if you have foo-1:1 and foo-2:2 installed, and you're installing foo-2:1. In this case, it's both a reinstall and an upgrade. One possibility is a REPLACING_VERSIONS variable that contains a list of all versions being replaced, along with a REPLACED_BY_VERSION variable for the pre/postrm part. +1 from me Not sure if these can go in in time for Portage or not: * Utility commands, even the ones that aren't functions, should die. To get a non-die version, prefix the command with nonfatal (e.g. 'nonfatal dodoc README', which just returns non-zero on failure rather than splatting). +1 from me * Calling unpack on an unrecognised extension should be fatal, unless --if-compressed is specified. The default src_unpack needs to use this. +1 from me * pkg_info should work on things that aren't installed, as well as things that are. We'd need to properly educate people about this because I'm pretty sure a bunch of pkg_info()'s require the actual package to be installed currently. -- Ciaran McCreesh
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 21:22 Sun 08 Mar , Donnie Berkholz wrote: On 23:35 Sun 08 Mar , Tiziano Müller wrote: Well, the point I'm trying to make here is a different one: The syntax you proposed is more to write but still equivalent to the one using vars. And looking at the ebuilds - taking G2CONF as an example - it seems that people don't have a problem with putting their config options into vars. And furthermore with your syntax you still have to write out econf $(use_with ...) explicitly while adding it the conf-vars to a var (as proposed) makes the complete src_configure function obsolete, allows the usage of the default src_configure/src_compile/src_install (see http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml for example) and is therefore even shorter to write. I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand. One of the key reasons people use Gentoo is that ebuilds are so easy to get for anyone who has ever built software by hand. I will continue to vehemently defend anything that I think retains this key advantage of Gentoo over other distributions. To return to the original point of this whole thread, your goal was to get EAPI=3 through fairly quickly without tons of controversial points. I don't think this component qualifies. Feel free to bring it up again for 4. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpD63RqCvGov.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 2009-03-08 at 21:22 -0700, Donnie Berkholz wrote: I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand. Fully agreed here, keep it simple software. Even if there are slightly more bits to write in the ebuilds. /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 23:31 -0700 schrieb Donnie Berkholz: On 21:22 Sun 08 Mar , Donnie Berkholz wrote: On 23:35 Sun 08 Mar , Tiziano Müller wrote: Well, the point I'm trying to make here is a different one: The syntax you proposed is more to write but still equivalent to the one using vars. And looking at the ebuilds - taking G2CONF as an example - it seems that people don't have a problem with putting their config options into vars. And furthermore with your syntax you still have to write out econf $(use_with ...) explicitly while adding it the conf-vars to a var (as proposed) makes the complete src_configure function obsolete, allows the usage of the default src_configure/src_compile/src_install (see http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml for example) and is therefore even shorter to write. I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand. One of the key reasons people use Gentoo is that ebuilds are so easy to get for anyone who has ever built software by hand. I will continue to vehemently defend anything that I think retains this key advantage of Gentoo over other distributions. To return to the original point of this whole thread, your goal was to get EAPI=3 through fairly quickly without tons of controversial points. I don't think this component qualifies. Feel free to bring it up again for 4. Wanted to say the same thing. Removed from the list. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Montag, den 09.03.2009, 10:12 +0100 schrieb Michael Haubenwallner: On Sun, 2009-03-08 at 21:22 -0700, Donnie Berkholz wrote: I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand. Fully agreed here, keep it simple software. Even if there are slightly more bits to write in the ebuilds. dito, fully agreed. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 08:49:16 +0100 Tiziano Müller dev-z...@gentoo.org wrote: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Here're some more easy ones. First up, un-optionaling some optional things. No impact for developers: * PROPERTIES must be cached properly (it's optional in current EAPIs) * DEFINED_PHASES must be supported (ditto) Next, some probably easy but long standing features: * src_test run unless RESTRICTed or explicitly disabled by the user (bug 184812) * have econf run ./configure with --disable-dependency-tracking and --enable-fast-install (bug 211529) * Limit values in $USE to ones in $IUSE (bug 176467). The existing behaviour's majorly annoying; time for the package manager to start enforcing things strictly. Some things we should probably sort out: * The list of extensions for unpack probably needs a couple of new things. * Provide ebuilds a way to differentiate between updates and removals (bug 205557), since the way devmanual says to do it got broken by a non-EAPIed change. This one's slightly trickier than initially apparent, because a solution's needed for the weird cases. One example is if you have foo-1:1 and foo-2:2 installed, and you're installing foo-2:1. In this case, it's both a reinstall and an upgrade. One possibility is a REPLACING_VERSIONS variable that contains a list of all versions being replaced, along with a REPLACED_BY_VERSION variable for the pre/postrm part. Not sure if these can go in in time for Portage or not: * Utility commands, even the ones that aren't functions, should die. To get a non-die version, prefix the command with nonfatal (e.g. 'nonfatal dodoc README', which just returns non-zero on failure rather than splatting). * Calling unpack on an unrecognised extension should be fatal, unless --if-compressed is specified. The default src_unpack needs to use this. * pkg_info should work on things that aren't installed, as well as things that are. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: * Limit values in $USE to ones in $IUSE (bug 176467). The existing behaviour's majorly annoying; time for the package manager to start enforcing things strictly. My impression is that most ebuild developers tend to dislike the idea of adding profile-specific flags such as $ARCH, userland_*, kernel_*, and elibc_* to IUSE. Perhaps there should be exemptions for these? - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEUEARECAAYFAkm1gnIACgkQ/ejvha5XGaN8pACYh2FTD9clbUo/kR4xoWi5z1kj KQCdHjyFkhiz7DdSDbCRGrOraayLrRE= =HgYu -END PGP SIGNATURE-
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Mon, 09 Mar 2009 13:56:19 -0700 Zac Medico zmed...@gentoo.org wrote: Ciaran McCreesh wrote: * Limit values in $USE to ones in $IUSE (bug 176467). The existing behaviour's majorly annoying; time for the package manager to start enforcing things strictly. My impression is that most ebuild developers tend to dislike the idea of adding profile-specific flags such as $ARCH, userland_*, kernel_*, and elibc_* to IUSE. Perhaps there should be exemptions for these? If we must do that... Can we get something in profiles a bit like this: USE_EXPAND_IMPLICIT=USERLAND KERNEL ELIBC ARCH USE_EXPAND_UNPREFIXED=ARCH USE_EXPAND_VALUES_USERLAND=GNU freebsd USE_EXPAND_VALUES_KERNEL=linux blah USE_EXPAND_VALUES_ELIBC=glibc USE_EXPAND_VALUES_ARCH=x86 amd64 sparc mips blah so we've got an enforcable complete list of every legal value for them, and less associated mess? That seems like a reasonable approach. What about flags that are commonly forced or masked such as selinux or multilib? Should there be an implicit exemption for all forced/masked flags, or should we introduce an IMPLICIT_IUSE profile variable to enumerate specific ones which are implicit members of IUSE? - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkm1ig8ACgkQ/ejvha5XGaMpxwCgqi0Ma+Wv9s0coMYtagWR8Je/ hBEAn3awatpk505DxKrGtYDwTSYgn+nZ =XHzp -END PGP SIGNATURE-
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 20:26 Mon 09 Mar , Ciaran McCreesh wrote: On Sun, 08 Mar 2009 08:49:16 +0100 Tiziano Müller dev-z...@gentoo.org wrote: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Here're some more easy ones. This list sounds mostly good to me. * Limit values in $USE to ones in $IUSE (bug 176467). The existing behaviour's majorly annoying; time for the package manager to start enforcing things strictly. I really like this one, and I've wanted it for a wihle. Not sure if these can go in in time for Portage or not: * Utility commands, even the ones that aren't functions, should die. To get a non-die version, prefix the command with nonfatal (e.g. 'nonfatal dodoc README', which just returns non-zero on failure rather than splatting). Sounds useful to have less '|| die' all over the place. * Calling unpack on an unrecognised extension should be fatal, unless --if-compressed is specified. The default src_unpack needs to use this. Why? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgplbqZtuOmBU.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Mon, 9 Mar 2009 20:26:24 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: * src_test run unless RESTRICTed or explicitly disabled by the user (bug 184812) This one is not uncontroversial and will not go in a 'quick' EAPI I think. /loki_val
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Tiziano � wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: I'm replying to the top level because I don't think any of the ideas are particularly bad. However, I wanted to raise this point: Should the next EAPI (as proposed) be a major release in terms of naming? And should it really be adding features? It is my opinion that EAPI bumps should move slower, one every year or so, in order to preserve upgradeable options for people that don't update often. However, I'm not going to let my opinion here block progress if it is needed. I would propose that EAPI=2.1 be an extension of EAPI=2 and be limited to only bug fixes as presented instead of smashing the bug fixes in EAPI=3 along with new features. With that said, can't bug fixes be implemented without an EAPI bump? I suppose that is not exactly safe in all cases.. =/ But, we should do a better job fixing bugs while the EAPI is in ~arch still. No, I don't have any ideas on how to accomplish that.. =P (Don't let this post turn into bikeshedding wrt naming options, just throwing it out there without wanting to defend it too much) -Jeremy
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Mon, 9 Mar 2009 15:39:41 -0700 Donnie Berkholz dberkh...@gentoo.org wrote: * Calling unpack on an unrecognised extension should be fatal, unless --if-compressed is specified. The default src_unpack needs to use this. Why? Currently, if a package does an explicit 'unpack foo.bar', where .bar is an unsupported archive format, unpack just does nothing. This isn't a good default behaviour; if a package really wants something to be ignored silently, it should have to say so. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Mon, 09 Mar 2009 17:38:51 -0500 Jeremy Olexa darks...@gentoo.org wrote: Should the next EAPI (as proposed) be a major release in terms of naming? We don't use major.minor numbers for EAPI or have a concept like that. It's too much mess. And should it really be adding features? Well... So far as I can see, the main driving force behind all of this is the immediate need for [use(+)] deps (since developers don't want to have to mess around with complex || statements), and [use(+)] is most definitely a new feature. With that said, can't bug fixes be implemented without an EAPI bump? If we screw up the specification and catch it early enough on, then yes. But [use(+)] really isn't a bug fix... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Is there some kind of time deadline here that you all want? Also, why the bannination of || ( foo? (.).) -- how is it error prone, exactly. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 00:08:37 -0800 Josh Saddler nightmo...@gentoo.org wrote: Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Is there some kind of time deadline here that you all want? If we were sticking through things Paludis has that're useful, the list would be an awful lot longer... And not everything on that list is even in Paludis... But hey, some things never go out of fashion. A few things on the list are required pretty soon. Bug 249166 and various existing screwups in the tree suggest that [use(+)] (or whatever syntax is decided upon) is going to crop up fairly frequently. And certain people are reluctant to nuke their prepalldocs calls despite Council decisions... I think the rest are just there because they're useful and easy. Also, why the bannination of || ( foo? (.).) -- how is it error prone, exactly. Last time I checked, every single use of foo? as a direct child of || in the tree was wrong, as were the Portage docs. Let's say you have the following: DEPEND=|| ( foo? ( cat/foo ) bar? ( cat/bar ) cat/baz ) Then this is wrong: if use foo ; then myconf=--enable-foo elif use bar ; then myconf=--enable-bar else myconf=--enable-baz fi Here's why: Say the user already has baz installed, and has USE=foo. The package manager will see that baz is already installed, and as per the rules for || will not look at the foo or bar deps. So if the user doesn't have foo installed, the --enable-foo will be wrong. So the 'correct' code would have to be something like this: if use foo has_version cat/foo ; then myconf=--enable-foo elif use bar has_version cat/bar ; then myconf=--enable-bar else myconf=--enable-baz fi Except this is *still* a mess, because a user who has USE=foo bar is going to end up with a differently configured package depending upon what he happens to have installed up-front, which is something that's not supposed to happen. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 8 Mar 2009, Ciaran McCreesh wrote: Last time I checked, every single use of foo? as a direct child of || in the tree was wrong, as were the Portage docs. Let's say you have the following: DEPEND=|| ( foo? ( cat/foo ) bar? ( cat/bar ) cat/baz ) Then this is wrong: if use foo ; then myconf=--enable-foo elif use bar ; then myconf=--enable-bar else myconf=--enable-baz fi I would suspect that in most of such cases the code expresses what is intended, but the dependency should be changed: foo? ( cat/foo ) !foo? ( bar? ( cat/bar ) !bar? ( cat/baz ) ) Ulrich
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler: Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Ok, first it's not about paludis,portage,pkgcore,whatever but about the ebuild-format. Paludis also fails if you have DEPEND=cat/foo[moo] in bar-0.1.ebuild but cat/foo doesn't have a moo USE flag. So, please let's focus on the problems we have and try to find a solution. Please fill in the blanks in the table if you know how portage has it implemented. And I used the word fast because people start to use use-dependencies on a larger scale leading to more problems like the one I described in the example. In fact, you could already say that for git the dep-tree is broken because newer subversion doesn't carry the dso USE flag anymore. Is there some kind of time deadline here that you all want? Well, 2 weeks discussion and 1 month implementation would be cool. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009, Tiziano Müller wrote: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ I get Not Found - Error 404 for this URL. Ulrich
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
2009-03-08 10:43:44 Tiziano Müller napisał(a): Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler: Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Ok, first it's not about paludis,portage,pkgcore,whatever but about the ebuild-format. Paludis also fails if you have DEPEND=cat/foo[moo] in bar-0.1.ebuild but cat/foo doesn't have a moo USE flag. So, please let's focus on the problems we have and try to find a solution. Please fill in the blanks in the table if you know how portage has it implemented. And I used the word fast because people start to use use-dependencies on a larger scale leading to more problems like the one I described in the example. In fact, you could already say that for git the dep-tree is broken because newer subversion doesn't carry the dso USE flag anymore. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/subversion/subversion-1.5.5.ebuild?view=markup contains: IUSE=apache2 berkdb debug doc +dso emacs extras java nls perl python ruby sasl vim-syntax +webdav-neon webdav-serf ^^^ (Subversion 1.6.* also has dso USE flag.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 12:05 +0100 schrieb Arfrever Frehtes Taifersar Arahesis: 2009-03-08 10:43:44 Tiziano Müller napisał(a): Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler: Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Is there a reason why we should ram through a new EAPI for something that *looks* like another Paludis supports this so let's make it a Portage standard proposal? Ok, first it's not about paludis,portage,pkgcore,whatever but about the ebuild-format. Paludis also fails if you have DEPEND=cat/foo[moo] in bar-0.1.ebuild but cat/foo doesn't have a moo USE flag. So, please let's focus on the problems we have and try to find a solution. Please fill in the blanks in the table if you know how portage has it implemented. And I used the word fast because people start to use use-dependencies on a larger scale leading to more problems like the one I described in the example. In fact, you could already say that for git the dep-tree is broken because newer subversion doesn't carry the dso USE flag anymore. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/subversion/subversion-1.5.5.ebuild?view=markup contains: IUSE=apache2 berkdb debug doc +dso emacs extras java nls perl python ruby sasl vim-syntax +webdav-neon webdav-serf ^^^ True, but subversion-1.4* doesn't. Anyway, it was meant as an example... signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sunday 08 March 2009, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ I'm not sure if you would like to discuss items to be added to the spreadsheet on this list first, but I accidently added default_src_install (bug 33544) to the list. I did not know it would store and share changes immediately. However, the proposed implementation on the bug does not follow the ideas of adding arguments to the default_src_* implementations (230725). Still, I think adding the default src_install function to EAPI=3 would be both trivial and an improvement for many simple ebuilds. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 08:49 Sun 08 Mar , Tiziano Müller wrote: So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ It's still being edited, so I have no idea whether I'm commenting on the same version as was originally posted. Regardless, here's a few points on the version I'm reading: - pkg_pretend() and a default src_install() would be excellent to have. - docompress is good - doheader/doinclude would be nice, same for dodoc -r, doins symlinks - fixing problems in some existing features would be useful - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). Combined with the addition of src_configure() in EAPI=2, the amount of code could be a large reduction from existing versions without raising the barrier to entry. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpm0J8uQhoXG.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 8 Mar 2009 09:42:29 -0700 Donnie Berkholz dberkh...@gentoo.org wrote: - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). How would that work? I can't see an obvious way of doing it that isn't more or less as verbose as just using multiple calls. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote: On Sun, 8 Mar 2009 09:42:29 -0700 Donnie Berkholz dberkh...@gentoo.org wrote: - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). How would that work? I can't see an obvious way of doing it that isn't more or less as verbose as just using multiple calls. It would just eliminate all but one call to use_with(). Depending on how many you've got, this can shorten things up a fair bit. Here's an example: econf \ $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') econf \ $(use_with x X) \ $(use_with foo libfoo) \ $(use_with bar) \ $(use_with python pygtk) -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpnd1Ie6CDqQ.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: | Hi everyone | | With eapis 1 and 2 we introduced nice features but also a couple of new | problems. One of them are the use dependencies when the package you | depend on doesn't have the use flag anymore (see [1] for an example). Hello all, ~Now that this topic was brought to light, I would like to add another point... ~I'm not sure if this has been worked out, or I just don't know how it is done, but a lot of python packages ~need to check use flags for dev-lang/python, like tk or threads for example. Now this is tricky considering the slotting of ~the interpreter. Let me give you an example: ~Suppose I have both python-2.5 and python-2.6 installed. python-2.5 was installed with tk use flag enabled but python-2.6 has it disabled. ~When some package tries to check for foo? ( dev-lang/python[tk] ) it will merge nicely because the use dep restriction is achieved with python-2.5, even ~if python-2.6 is the selected interpreter and it misses the tk use flag. Is there a way to workaround this? am I missing something? or is just something else ~to take into account for next eapi? ~Thanks a lot, ~Best regards, ~Jesus Rivero (Neurogeek) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmz/lMACgkQdIssYB9vBoPEbwCfYg/BaEhRtNCv1LChbqdAt8RW T8oAmwaA6Jz2HX5NbSHhD3XeN7JnqAHL =oJr/ -END PGP SIGNATURE-
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Mar 08, 2009 at 10:01:05AM -0700, Donnie Berkholz wrote: How would that work? I can't see an obvious way of doing it that isn't more or less as verbose as just using multiple calls. It would just eliminate all but one call to use_with(). Depending on how many you've got, this can shorten things up a fair bit. Here's an example: econf \ $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') econf \ $(use_with x X) \ $(use_with foo libfoo) \ $(use_with bar) \ $(use_with python pygtk) I like this idea also, but I would prefer using something other than spaces in each argument, like so: econf \ $(use_with x:X foo:libfoo bar python:pygtk) - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmz/zUACgkQblQW9DDEZTgnugCgkTMUOCQUbcAs9qcvxxmt2Wna BY4AoKAjdpzXkiiizFsQ8MKUmAwHxZMC =lFam -END PGP SIGNATURE-
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 12:50:19 -0430 Jesus Rivero neurog...@gentoo.org wrote: ~if python-2.6 is the selected interpreter and it misses the tk use flag. Is there a way to workaround this? am I missing something? or is just something else ~to take into account for next eapi? Fixing this mess properly really requires package manager support for multiple ABIs (for some value of B that includes things like Python versions). I doubt this is fixable in the timeframe that seems to be being considered here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). you can solve this right now, even if in a not very elegant way. For instance, if you need glibc with NPTL support, you can use elibc_glibc? ( =sys-libs/glibc-2.3 || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) ) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 10:01 Sun 08 Mar , Donnie Berkholz wrote: On 16:48 Sun 08 Mar , Ciaran McCreesh wrote: On Sun, 8 Mar 2009 09:42:29 -0700 Donnie Berkholz dberkh...@gentoo.org wrote: - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). How would that work? I can't see an obvious way of doing it that isn't more or less as verbose as just using multiple calls. It would just eliminate all but one call to use_with(). Depending on how many you've got, this can shorten things up a fair bit. Here's an example: econf \ $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') econf \ $(use_with x X) \ $(use_with foo libfoo) \ $(use_with bar) \ $(use_with python pygtk) And the straightforward evolution of this would be additional with() and enable() functions for mandatory support. I still find this more intuitive than the set of variables. econf \ $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \ $(with foo bar blah baz) \ $(enable bam paw tick) -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpx0EF3mG45G.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
- I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
strongly oppose this implementation because it makes ebuilds less
like bash scripts that are easy to understand. Instead I suggest
extending use_with() and use_enable() to accept multiple sets of
arguments (alternately, making custom, similar functions that will
take multiple args).
How would that work? I can't see an obvious way of doing it that isn't
more or less as verbose as just using multiple calls.
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
econf \
$(use_with x X) \
$(use_with foo libfoo) \
$(use_with bar) \
$(use_with python pygtk)
The above could be rewritten to:
ECONF_USE_WITH='x X' 'foo libfoo' 'bar' 'python pygtk'
econf $(use_with ${ECONF_USE_WITH})
or an eclass could even export this:
src_configure() {
[ -n ${ECONF_USE_WITH} ] USE_WITH=$(use_with
\${ECONF_USE_WITH}\)
econf ${USE_WITH}
}
Guessing from what I see in the gnome/kde eclasses I think people will
implement the above then in eclasses and I therefore don't see why we
can't do it like that from the beginning...
(Besides, there are already shortcuts in eclasses like G2CONF=...)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 19:06 +0100 schrieb Stelian Ionescu: On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). you can solve this right now, even if in a not very elegant way. For instance, if you need glibc with NPTL support, you can use elibc_glibc? ( =sys-libs/glibc-2.3 || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) ) Well, that's exactly what could be avoided and eventually be written as: elibc_glibc? ( =sys-libs/glibc-2.3[nptl(+)] ) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 17:22 +0100 schrieb Robert Buchholz: On Sunday 08 March 2009, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ I'm not sure if you would like to discuss items to be added to the spreadsheet on this list first, but I accidently added default_src_install (bug 33544) to the list. I did not know it would store and share changes immediately. This accident was intended ;-) However, the proposed implementation on the bug does not follow the ideas of adding arguments to the default_src_* implementations (230725). Still, I think adding the default src_install function to EAPI=3 would be both trivial and an improvement for many simple ebuilds. Fine by me. I didn't add this bug because I thought that the discussion about it could get too controversal and thus not suited for a fast release of a new eapi (mainly thought to be fixing bugs). signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
- I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
strongly oppose this implementation because it makes ebuilds less
like bash scripts that are easy to understand. Instead I suggest
extending use_with() and use_enable() to accept multiple sets of
arguments (alternately, making custom, similar functions that will
take multiple args).
How would that work? I can't see an obvious way of doing it that isn't
more or less as verbose as just using multiple calls.
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
econf \
$(use_with x X) \
$(use_with foo libfoo) \
$(use_with bar) \
$(use_with python pygtk)
And the straightforward evolution of this would be additional with() and
enable() functions for mandatory support. I still find this more
intuitive than the set of variables.
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \
$(with foo bar blah baz) \
$(enable bam paw tick)
Which could already be written as ...
econf --with-{foo,bar}
using bash :-)
(or did I miss the point?)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 19:35 Sun 08 Mar , Tiziano Müller wrote:
Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz dberkh...@gentoo.org wrote:
- I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
strongly oppose this implementation because it makes ebuilds less
like bash scripts that are easy to understand. Instead I suggest
extending use_with() and use_enable() to accept multiple sets of
arguments (alternately, making custom, similar functions that will
take multiple args).
How would that work? I can't see an obvious way of doing it that isn't
more or less as verbose as just using multiple calls.
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
econf \
$(use_with x X) \
$(use_with foo libfoo) \
$(use_with bar) \
$(use_with python pygtk)
And the straightforward evolution of this would be additional with() and
enable() functions for mandatory support. I still find this more
intuitive than the set of variables.
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \
$(with foo bar blah baz) \
$(enable bam paw tick)
Which could already be written as ...
econf --with-{foo,bar}
using bash :-)
(or did I miss the point?)
Consistency, and that gets pretty ugly after a few when you also want to
pass arguments to them.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpijeydm3D5W.pgp
Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 19:27 Sun 08 Mar , Tiziano Müller wrote:
Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
The above could be rewritten to:
ECONF_USE_WITH='x X' 'foo libfoo' 'bar' 'python pygtk'
econf $(use_with ${ECONF_USE_WITH})
Why would I want to obfuscate my code like that by purposely making
people look in multiple places to figure out what it's doing? I don't
see how this is any improvement.
or an eclass could even export this:
src_configure() {
[ -n ${ECONF_USE_WITH} ] USE_WITH=$(use_with
\${ECONF_USE_WITH}\)
econf ${USE_WITH}
}
Guessing from what I see in the gnome/kde eclasses I think people will
implement the above then in eclasses and I therefore don't see why we
can't do it like that from the beginning...
If it can be implemented in an eclass, why would we want to do it as an
EAPI in a package manager? Eclasses can be easily changed, you only need
to write them once, and you don't have to deal with updating approving
a spec and new implementation for a bug in the previous implementation
(which you have to retain indefinitely).
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpEIwaNLiQmh.pgp
Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 15:16 -0700 schrieb Donnie Berkholz:
On 19:27 Sun 08 Mar , Tiziano Müller wrote:
Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
It would just eliminate all but one call to use_with(). Depending on how
many you've got, this can shorten things up a fair bit. Here's an
example:
econf \
$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
The above could be rewritten to:
ECONF_USE_WITH='x X' 'foo libfoo' 'bar' 'python pygtk'
econf $(use_with ${ECONF_USE_WITH})
Why would I want to obfuscate my code like that by purposely making
people look in multiple places to figure out what it's doing? I don't
see how this is any improvement.
or an eclass could even export this:
src_configure() {
[ -n ${ECONF_USE_WITH} ] USE_WITH=$(use_with
\${ECONF_USE_WITH}\)
econf ${USE_WITH}
}
Guessing from what I see in the gnome/kde eclasses I think people will
implement the above then in eclasses and I therefore don't see why we
can't do it like that from the beginning...
If it can be implemented in an eclass, why would we want to do it as an
EAPI in a package manager? Eclasses can be easily changed, you only need
to write them once, and you don't have to deal with updating approving
a spec and new implementation for a bug in the previous implementation
(which you have to retain indefinitely).
Well, the point I'm trying to make here is a different one:
The syntax you proposed is more to write but still equivalent to the one
using vars.
And looking at the ebuilds - taking G2CONF as an example - it seems that
people don't have a problem with putting their config options into vars.
And furthermore with your syntax you still have to write out econf
$(use_with ...) explicitly while adding it the conf-vars to a var (as
proposed) makes the complete src_configure function obsolete, allows the
usage of the default src_configure/src_compile/src_install (see
http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml
for example) and is therefore even shorter to write.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sun, Mar 08, 2009 at 09:42:29AM -0700, Donnie Berkholz wrote: On 08:49 Sun 08 Mar , Tiziano M?ller wrote: So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I strongly oppose this implementation because it makes ebuilds less like bash scripts that are easy to understand. Instead I suggest extending use_with() and use_enable() to accept multiple sets of arguments (alternately, making custom, similar functions that will take multiple args). Combined with the addition of src_configure() in EAPI=2, the amount of code could be a large reduction from existing versions without raising the barrier to entry. While I understand your concerns about the SRC_CONFIGURE stuff, there are two points I'd like to make; 1) The barrier to entry is negligible. How much more difficult is it for someone to learn what CONFIGURE_ENABLES=( 'foo foobar' ) ? I didn't find it difficult at all(and I've used them). 2) src_configure is just one part; src_compile has uses as does src_install. In fact, if you want to do patches, src_prepare would be in there too. What I'm saying is that focusing on the one part(configure) is ignoring the good part of the rest of the proposal. Regards, Thomas -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgp4mn7bM5lm2.pgp Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On 23:35 Sun 08 Mar , Tiziano Müller wrote: Well, the point I'm trying to make here is a different one: The syntax you proposed is more to write but still equivalent to the one using vars. And looking at the ebuilds - taking G2CONF as an example - it seems that people don't have a problem with putting their config options into vars. And furthermore with your syntax you still have to write out econf $(use_with ...) explicitly while adding it the conf-vars to a var (as proposed) makes the complete src_configure function obsolete, allows the usage of the default src_configure/src_compile/src_install (see http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml for example) and is therefore even shorter to write. I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand. One of the key reasons people use Gentoo is that ebuilds are so easy to get for anyone who has ever built software by hand. I will continue to vehemently defend anything that I think retains this key advantage of Gentoo over other distributions. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpN1K1VVp0pJ.pgp Description: PGP signature
[gentoo-dev] Ideas for a (fast) EAPI=3
Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ Please discuss. Cheers, Tiziano [1]: Git depends on subversion[dso], but subversion-1.5.5 doesn't have USE=dso anymore, so my package manager (paludis in that case) tried to downgrade to a version of subversion where the USE flag exists. The PMS says this about the issue: It is an error for a use dependency to be applied to an ebuild which does not have the flag in question in IUSE [...] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
