[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/undvd: undvd-0.3.0.ebuild metadata.xml ChangeLog Manifest
Duncan wrote: > Donnie Berkholz <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Sun, 16 Dec 2007 > 12:49:13 -0800: > >> I think it's valuable to show the flags that actually need to be changed >> rather than a full list of all required flags. > > ++ > I messed about on something similar with jakub for php eclasses (didn't get used, "overkill") a couple of months ago, which is at: http://phpfi.com/283737 ..if that's any help. The paste shows the checkUSE function and how it would be used in an eclass/ebuild (bit long to paste here.) That one's php-specific, but removing the call to phpconfutils_built_with_use would fix that. (It's for built_with_use but changing that isn't hard either.) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Hello, attaching the GLEP. most current version: http://dev.gentoo.org/~peper/glep-0055.html http://dev.gentoo.org/~peper/glep-0055.txt -- Best Regards, Piotr Jaroszyński GLEP: 55 Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) Version: $Revision: $ Last-Modified: $Date: $ Author: Piotr Jaroszyński <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Dec-2007 Post-History: 17-Dec-2007 Abstract This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1). Motivation == Including EAPI in the ebuild file extension has the following advantages: * Possibility to extend the versioning rules in an EAPI, and to use them immediately in the Gentoo tree. For example, addition of the scm suffix - GLEP54 [#GLEP54]_. * Possibility to extend the behaviour of inherit and add new global scope functions (as a result of not sourcing ebuilds with unsupported EAPI). Specification = Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps: * If the pre-source EAPI is not set it defaults to 0. * If the pre-source EAPI is not recognised it is returned immediately. * If the post-source EAPI is not set, it defaults to the pre-source EAPI. * post-source EAPI is returned. The above process should be only used to generate the metadata cache. Should the pre-source EAPI be unsupported the cache entry cannot be generated. Ebuilds with unsupported EAPIs are masked. QA tools should consider it an error for both EAPIs to be set explicitly to different values. Package managers may warn, but must use the post-source EAPI in such cases. Examples: * ``pkg-1.ebuild``, no EAPI set inside the ebuild pre-source EAPI defaults 0, post-source EAPI defaults to pre-source EAPI. EAPI 0 is used. * ``pkg-2.ebuild-0``, no EAPI set inside the ebuild pre-source EAPI is 0, post-source EAPI defaults to pre-source EAPI. EAPI 0 is used. * ``pkg-3.ebuild-1``, no EAPI set inside the ebuild pre-source EAPI is 1, post-source EAPI defaults to pre-source EAPI. EAPI 1 is used. * ``pkg-4.ebuild``, ``EAPI="1"`` pre-source EAPI defaults to 0, post-source EAPI is 1. EAPI 1 is used. * ``pkg-4.ebuild-2``, ``EAPI="1"`` pre-source EAPI is 2, post-source EAPI is 1. EAPI 1 is used, but note that one should **never** explicitly set both EAPIs to different values. * ``pkg-5.ebuild-2``, no EAPI set inside the ebuild, package manager not supporting EAPI 2 pre-source EAPI is 2, post-source EAPI is never checked. ebuild masked because of the unsupported pre-source EAPI. * ``pkg-6.ebuild``, ``EAPI="2"``, package manager not supporting EAPI 2 pre-source EAPI defaults to 0, post-source EAPI is 2. ebuild masked because of the unsupported post-source EAPI. Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. Although it would have the advantage of allowing to provide backward compatible ebuilds, it would introduce problems too. The first is the requirement to have strict EAPI ordering, the second is ensuring that all the ebuilds for a single category/package-version are equivalent, i.e. installing any of them has exactly the same effect to the system. Backwards Compatibility === Currently ebuilds are recognised by the ``.ebuild`` file extension and hence EAPI-suffixed ebuilds are simply ignored by the package manager allowing their immediate usage in the Gentoo tree. References == .. [#GLEP54] GLEP 54, scm package version suffix (http://glep.gentoo.org/glep-0054.html) Copyright = This document has been placed in the public domain. .. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 2007/12/17, Piotr Jaroszyński <[EMAIL PROTECTED]> wrote:
> http://dev.gentoo.org/~peper/glep-0055.html
> * Possibility to extend the versioning rules in an EAPI, and to
> use them immediately in the Gentoo tree. For example, addition of
> the scm suffix - GLEP54 [1].
...
> Currently ebuilds are recognised by the .ebuild file extension and
> hence EAPI-suffixed ebuilds are simply ignored by the package manager
> allowing their immediate usage in the Gentoo tree.
What about other places where some "cat/pkg-version" are used?
- deps: ok, no pb, i guess EAPI=X ebuilds are not allowed to have
dependencies on some "cat/pkg-version" whose "version" is in a syntax
introduced in a later EAPI. Could be made explicit though.
- metadata/cache: latest PMS i've found (2007/07/08 on dev.g.o/~spb)
says it contains some "/-" files. If a
package manager assumes the "" syntax is the one defined in
the said PMS, and you extend this syntax, don't your fear it will
trigger some bugs in said packages manager?
- /var/db/pkg: this one is not specified anywhere afaik, but here too,
putting some "/-" with a new ""
syntax may trigger weird some packages manager bugs. Which would
basically prevent forbid beetween several package managers which don't
support the same EAPI set, or simply downgrading your favorite one.
- profiles/*: how will the various files there ("packages", etc.) ever
be allowed to use some atoms which use an extended versioning syntax?
I'm not saying that the idea is bad though (i 100% agree it's useful),
but "*.ebuild-x" being ignored by current pkg managers is not enough
to conclude you can extend the versioning syntax without backward
compatibility issues.
--
TGL.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 18 Dec 2007 00:40:05 +0100
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> - metadata/cache: latest PMS i've found (2007/07/08 on dev.g.o/~spb)
> says it contains some "/-" files. If a
> package manager assumes the "" syntax is the one defined in
> the said PMS, and you extend this syntax, don't your fear it will
> trigger some bugs in said packages manager?
The package manager shouldn't be fishing around in metadata/cache. It
should only be doing direct lookups in there based upon ebuilds it
finds.
(latest PMS, by the way, is svn co http://svn.repogirl.net/pms)
> - /var/db/pkg: this one is not specified anywhere afaik, but here
> too, putting some "/-" with a new
> "" syntax may trigger weird some packages manager bugs.
> Which would basically prevent forbid beetween several package
> managers which don't support the same EAPI set, or simply downgrading
> your favorite one.
You already can't downgrade package managers, so there's no regression
there.
> - profiles/*: how will the various files there ("packages", etc.)
> ever be allowed to use some atoms which use an extended versioning
> syntax?
Currently profiles/* is limited to using EAPI-0 style things. You
can't, for example, use slot deps in profiles/. Removing this
restriction could be done in two ways (package-mask-1 etc, or
profiles/*/eapi).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński wrote: > Hello, > > attaching the GLEP. > > most current version: > http://dev.gentoo.org/~peper/glep-0055.html > http://dev.gentoo.org/~peper/glep-0055.txt > > > Abstract > > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds > (for example, foo-1.2.3.ebuild-1). I probably missed some of the stuff leading up to this GLEP, but what is the problem with having the EAPI in the file and determining it by looking at the file contents? Making the file extension variable by adding "-" to it would, in my opinion, make the portage tree a bit less clean and not as elegant. Wouldn't software (like editors determining file type by looking at what is after the ".") also need to be reworked to recognize a variable string after "-" at the end? I imagine a lot of people do things now like 'find . -name "*.ebuild" | xargs grep ...'. Not that they could not change their habbits, but forgetting to add a more complex matching rule could lead to errors here. It just seems to me that adding complexity to what is basically a file extension is undesirable unless there is a very good reason why it cannot be done a different way. -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 17 Dec 2007 17:10:46 -0700 Joe Peterson <[EMAIL PROTECTED]> wrote: > I probably missed some of the stuff leading up to this GLEP, but what > is the problem with having the EAPI in the file and determining it by > looking at the file contents? Motivation, second bullet point: | Possibility to extend the behaviour of inherit and add new global | scope functions (as a result of not sourcing ebuilds with unsupported | EAPI). > Making the file extension variable by adding "-" to it would, in > my opinion, make the portage tree a bit less clean and not as elegant. > Wouldn't software (like editors determining file type by looking at > what is after the ".") also need to be reworked to recognize a > variable string after "-" at the end? Yep, but that's not very difficult. And as a side effect, editors could then provide EAPI aware highlighting. > I imagine a lot of people do things now like 'find . -name "*.ebuild" > | xargs grep ...'. Not that they could not change their habbits, but > forgetting to add a more complex matching rule could lead to errors > here. -name '*.ebuild*' isn't exactly much more complex... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: >> I imagine a lot of people do things now like 'find . -name "*.ebuild" >> | xargs grep ...'. Not that they could not change their habbits, but >> forgetting to add a more complex matching rule could lead to errors >> here. > > -name '*.ebuild*' isn't exactly much more complex... No, but to be more "correct" it shouldn't be that open-ended. For example, it really should be a regexp that only allows a dash followed by digits (and then nothing after). Not hard, but if forgotten, it could yield misleading results. Perhaps it's more the "feel" of it that bothers me, and once this path is taken, there is no going back. -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 2007/12/18, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Mon, 17 Dec 2007 17:10:46 -0700 > Joe Peterson <[EMAIL PROTECTED]> wrote: > > I probably missed some of the stuff leading up to this GLEP, but > > what is the problem with having the EAPI in the file and > > determining it by looking at the file contents? > > Motivation, second bullet point: > > | Possibility to extend the behaviour of inherit and add new global > | scope functions (as a result of not sourcing ebuilds with > | unsupported EAPI). Why can't it be in the file but readable without sourcing? For instance, it could be mandatory that EAPI=X, if present, must be the first non-blank and non-comment line of the ebuild (and it would then be checked after sourcing, if the ebuild is sourced, to bug on cases where it's redefined or unset afterwards). -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 17 Dec 2007 17:30:50 -0700 Joe Peterson <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > >> I imagine a lot of people do things now like 'find . -name > >> "*.ebuild" | xargs grep ...'. Not that they could not change > >> their habbits, but forgetting to add a more complex matching rule > >> could lead to errors here. > > > > -name '*.ebuild*' isn't exactly much more complex... > > No, but to be more "correct" it shouldn't be that open-ended. For > example, it really should be a regexp that only allows a dash followed > by digits (and then nothing after). Not hard, but if forgotten, it > could yield misleading results. Perhaps it's more the "feel" of it > that bothers me, and once this path is taken, there is no going back. An EAPI is not limited to a numeric name. We could call the next EAPI "cabbage" if we wanted to. There're already various experimental EAPIs that don't use pure numbers (for example, "paludis-1"). (Sometimes I think the next EAPI *should* be called "cabbage", if only because it'll help disabuse people of the notion that EAPIs are orderable...) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 18 Dec 2007 01:36:51 +0100 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > Why can't it be in the file but readable without sourcing? For > instance, it could be mandatory that EAPI=X, if present, must be the > first non-blank and non-comment line of the ebuild (and it would then > be checked after sourcing, if the ebuild is sourced, to bug on cases > where it's redefined or unset afterwards). That's another option. It's considered less ideal because it's a nasty hack -- it imposes restrictions beyond "it's bash" upon the format of ebuilds. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tuesday 18 December 2007 01:36:51 Thomas de Grenier de Latour wrote: > Why can't it be in the file but readable without sourcing? For instance, > it could be mandatory that EAPI=X, if present, must be the first > non-blank and non-comment line of the ebuild (and it would then be > checked after sourcing, if the ebuild is sourced, to bug on cases where > it's redefined or unset afterwards). This would also mean we had to wait for ages before taking advantage of it because old versions of portage still would try to source the ebuild when the EAPI is unknown. The nice thing about .ebuild-EAPI is that old versions of Portage will ignore it. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Tue, 18 Dec 2007 01:36:51 +0100 > Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: >> Why can't it be in the file but readable without sourcing? For >> instance, it could be mandatory that EAPI=X, if present, must be the >> first non-blank and non-comment line of the ebuild (and it would then >> be checked after sourcing, if the ebuild is sourced, to bug on cases >> where it's redefined or unset afterwards). > > That's another option. It's considered less ideal because it's a nasty > hack -- it imposes restrictions beyond "it's bash" upon the format of > ebuilds. This option is worth thinking about more - there may be satisfactory ways to mediate the issues. It is certainly more elegant, and it avoids another nasty gotcha: that of the pre-source and post-source EAPI disagreeing. Generally, I find that having the same info in two places should be avoided whenever possible. I know the GLEP contains ways of determining the "real" EAPI in this case (post-source), but I can imagine most humans will simply get used to looking at the filename and potentially miss the fact that it doesn't match, and programs that look only pre-source can be mislead. -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 17 Dec 2007 18:05:23 -0700 Joe Peterson <[EMAIL PROTECTED]> wrote: > This option is worth thinking about more - there may be satisfactory > ways to mediate the issues. It is certainly more elegant Introducing new parse and format requirements upon bash files is most definitely not elegant... Everything that currently tries to parse bash that is itself not bash is full of weird bugs. And imposing weird and arbitrary requirements about whitespace, positioning etc is far more prone to developer screwup than the filename approach. > and it avoids another nasty gotcha: that of the pre-source and > post-source EAPI disagreeing. Generally, I find that having the same > info in two places should be avoided whenever possible. I know the > GLEP contains ways of determining the "real" EAPI in this case > (post-source), but I can imagine most humans will simply get used to > looking at the filename and potentially miss the fact that it doesn't > match, and programs that look only pre-source can be mislead. The GLEP's rules are merely to ensure a sane upgrade path. EAPI being specified in two sets of places will only happen if a developer screws up and ignores warnings from QA tools. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Mon, 17 Dec 2007 18:05:23 -0700 > Joe Peterson <[EMAIL PROTECTED]> wrote: >> This option is worth thinking about more - there may be satisfactory >> ways to mediate the issues. It is certainly more elegant > > Introducing new parse and format requirements upon bash files is most > definitely not elegant... Everything that currently tries to parse bash > that is itself not bash is full of weird bugs. And imposing weird and > arbitrary requirements about whitespace, positioning etc is far more > prone to developer screwup than the filename approach. I agree that such rules should not be arbitrary or depend on whitespace. It should behave essentially the same as sourcing the file. But I do agree that this is not trivial. What about storing a copy of the EAPI in the Manifest file - when "ebuild ... digest" is done? That way, it will always match the one authoritative "post-source" EAPI setting, since changing the ebuild will require a new digest run anyway. We have control over the format of Manifest, so parsing it can be fast. If Manifest is not a good candidate, put them in an optional "EAPI" file (which can then also be included in the Manifest). If the external EAPI info for an ebuild is not found, then drop back to assuming it does not have a defined pre-source EAPI. This way, we can guarantee that the pre-source EAPI info matches the post-source, since it was derived from it (during the digest step). Forgive me if this idea has already been suggested. > The GLEP's rules are merely to ensure a sane upgrade path. EAPI being > specified in two sets of places will only happen if a developer screws > up and ignores warnings from QA tools. Yes, but I bet we can do better than that. -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 17 Dec 2007 23:20:01 +0100 Piotr Jaroszyński <[EMAIL PROTECTED]> wrote: > Hello, > > attaching the GLEP. How does this chord with eclasses that set EAPI, instead of ebuilds? Last I read was that EAPI-set-by-eclass was close to being ratified. Kind regards, JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 18 Dec 2007 05:41:45 +0100 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > How does this chord with eclasses that set EAPI, instead of ebuilds? > Last I read was that EAPI-set-by-eclass was close to being ratified. Read where? So far as I'm aware, everyone's been saying "don't set EAPI in an eclass". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 18 Dec 2007 04:46:35 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Tue, 18 Dec 2007 05:41:45 +0100 > Jeroen Roovers <[EMAIL PROTECTED]> wrote: > > How does this chord with eclasses that set EAPI, instead of ebuilds? > > Last I read was that EAPI-set-by-eclass was close to being ratified. > > Read where? So far as I'm aware, everyone's been saying "don't set > EAPI in an eclass". On this mailing list, in the "EAPI placement" thread. JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 18 Dec 2007 06:27:02 +0100 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > On this mailing list, in the "EAPI placement" thread. OK, it would seem that discussion has now died in favour of forbidding eclasses setting EAPI altogether. But now, if pkg-5.ebuild-zillion doesn't set an EAPI variable, how will the eclass know it? Perhaps the GLEP should explain that the package manager is required to set the EAPI variable in the environment. JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
> On Tue, 18 Dec 2007, Ciaran McCreesh wrote: > | Possibility to extend the behaviour of inherit and add new global > | scope functions (as a result of not sourcing ebuilds with > | unsupported EAPI). It seems to me that this will inconvenience the users, in order to solve a technical problem of the package manager. Is this really the right way to go? >> Making the file extension variable by adding "-" to it would, >> in my opinion, make the portage tree a bit less clean and not as >> elegant. +1 >> Wouldn't software (like editors determining file type by looking at >> what is after the ".") also need to be reworked to recognize a >> variable string after "-" at the end? > Yep, but that's not very difficult. And as a side effect, editors > could then provide EAPI aware highlighting. They can also do this if EAPI is set within the file. Ulrich -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 18 Dec 2007 08:17:49 +0100 Ulrich Mueller <[EMAIL PROTECTED]> wrote: > > On Tue, 18 Dec 2007, Ciaran McCreesh wrote: > > | Possibility to extend the behaviour of inherit and add new global > > | scope functions (as a result of not sourcing ebuilds with > > | unsupported EAPI). > > It seems to me that this will inconvenience the users, in order to > solve a technical problem of the package manager. > > Is this really the right way to go? Well, users shouldn't really be doing anything with .ebuild files... Or if by users you mean developers, I'd say it's considerably less inconvenient than having to remember arbitrary syntax restrictions... > >> Wouldn't software (like editors determining file type by looking at > >> what is after the ".") also need to be reworked to recognize a > >> variable string after "-" at the end? > > > Yep, but that's not very difficult. And as a side effect, editors > > could then provide EAPI aware highlighting. > > They can also do this if EAPI is set within the file. It's extremely tricky to do correctly... With Vim it'd only work when opening an existing file with the variable already there. Picking it up as it's added would require insane CursorHold hackery (which also slows down Vim quite a bit). -- Ciaran McCreesh signature.asc Description: PGP signature
