Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
I have no strong opinion about this. 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage simple, straightforward but ugly b) .eapi.ebuild - current Portage does not work with this this only has disadvantages in front of a) c) .eapi.new extension - ignored by current Portage same as a) but maybe less ugly 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache This doesn't need a locked down place, just some strict way of setting it, like at most one EAPI=constant_string_without_space so that grep friends can catch it. - Does not allow changing versioning rules unless version becomes a normal metadata variable I'm not entirely sure about this and would need some real example/argument in order to be convinced * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked true but this more would need to be measured and opposed to the number of metadata loads in a dep resolution procedure. a) new extension doesn't have the one year wait drawback and doesn't mess with pm implementation details (eapi) with package names that shall represent upstream ones. b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository I see no advantage there vs 3.a) c) .ebuild in current directory - needs one year wait That could have been done one year ago and would be done now; I think it's still fine now because I don't expect major behavior changes in the ebuild format within one year. To summarize, I would retain 3.a as best solution, having the usable right now advantage of current glep55 and keeping the ebuild's file names (more or less) consistent with upstream ones. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 19:37:11 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 24 Feb 2009 20:28:43 +0100 Alexis Ballier aball...@gentoo.org wrote: On Tue, 24 Feb 2009 18:24:16 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 24 Feb 2009 18:16:54 +0100 Luca Barbato lu_z...@gentoo.org wrote: You're doubling the number of files that have to be read for an operation that's almost purely i/o bound. On top of that, you're introducing a whole bunch of disk seeks in what's otherwise a nice linear operation. I see words, not numbers. Number: double. That's a '2 times'. That only means you're increasing the constant factor in the complexity of the thing... which may very well be completely negligible unless someone provides real benchmarks. In the most common case where metadata is valid, around half of the time it takes Paludis to work out a resolution set is spent grabbing metadata for ebuilds. That sounds like an implementation detail that you could solve by using something else than a flat file database for metadata if open()/read() calls are the slow part. I would be very surprised if that 2 times factor happens to be true, because finding a string in a file is an order of magnitude simpler than sourcing said file with bash. Moreover this doesn't take into account disk and os cache. No no no. *Opening* the file is the slow part, not searching. The file wouldn't otherwise be opened at all. Thus the only drawback is when you open a file, see there that you can't handle the eapi, then close it and open an older one. So you're doing useless things only in that case which in practice will have a ratio far lower than 2. Moreover Luca's benchs show that searching for file names is a negligible factor faster than grepping them while you're just stating that it isn't. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Hi! My preference, most wanted to least wanted: - inside the ebuild If it's not too much pain. Yes, that is a very subjective metric and it's what a large amount of flames has been about. - in the filename, but not as a tail eg: foo-2.3.4-r2+9.build yes, alternate separators might be better. I like .build very much, though. What does the e in ebuild stand for anyway? - in the filename, as a tail eg: foo-2.3.4.ebuild-9 I don't like this much, but it's better than never having EAPI versioning. Regards, Tobias -- printk(Cool stuff's happening!\n) linux-2.4.3/fs/jffs/intrep.c
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty betelge...@gentoo.org wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. [...] I dislike GLEP 55 aesthetically, but I see no other way to move out of this deadlock where we can't use new bash-features till years have passed. So unless someone suggests a solution that allows us to have EAPI as part of the ebuild without having to wait till hell freezes over, I'm behind GLEP 55 as the least-bad solution. /loki_val
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 2009-02-25 at 00:21 +0200, Petteri Räty wrote: get opinions [..] to get some idea what the general developer pool thinks. only allowed to post a single reply to this thread Thank you for that, I usually don't follow long threads, so apologies if things have been discussed already. Basically, I'm all for having GLEP55 as good as possible in favour of as soon as possible before implementation, even if it fits my thoughts quite good already (see below). 2) EAPI in file extension IMO, this should define *how* to read the *final* EAPI from the ebuild. The *how* does not necessarily mean to /source/ the ebuild, so the terms pre-source EAPI and post-source EAPI IMHO are too strongly focussing on (bash) source $EBUILD when used in a generic GLEP. Eventually, the pre-source EAPI could be called major EAPI, and the post-source EAPI could be called major.minor EAPI (see below). The EAPI in file extension also should define the filename-part of the versioning rules. a) .ebuild-eapi c) .eapi.new extension - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this ignored by current portage is an important point for me to *theorethically* guarantee for a possible upgrade path even over long time. 3) EAPI in locked down place in the ebuild This lock down should be done by EAPI in file extension above. lock down can mean any of: post-source (real bash-source), self-parse (grep?), fixed-byte/line-offset, ... My thoughts are to split EAPI into several levels (rename them however you like): entry-point: Specifies how to read the filename-scope EAPI. filename-scope EAPI: Think as major EAPI. Specifies the filename-part of versioning rules. Specifies how to read the global-scope EAPI (can, but eventually should not require bash-sourcing the ebuild). May allow to not define minor, assuming $major.0.0 then. global-scope EAPI: Think as $major.minor EAPI. May specify how to define additional versioning rules. Specifies how to define metadata information. Specifies which metadata information is required/optional/cached/... Specifies how to utilize external resources (eclasses). Specifies which/how actions can/must be defined (pkg_*, src_* functions). Specifies how to read the local-scope EAPI. May allow to not define micro, assuming $major.$minor.0 then. May disallow a local-scope EAPI, specifies it instead. local-scope EAPI: Think as $major.$minor.micro EAPI. Specifies which PM-functions are available for use in actions (fex 'doman' inside src_install). May be specified as part of minor EAPI. Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Gentoo Council Reminder for February 26
Donnie Berkholz wrote: On 23:26 Sun 22 Feb , Donnie Berkholz wrote: This is your friendly reminder! Same bat time (typically the 2nd 4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Here's the preliminary agenda. I'm running a bit behind on -dev, so it's a little out of date re GLEPs 54/55. People including lu_zero, cardoe, dev-zero, and tanderson should fill us in on things below that they've taken responsibility for. Anyone else can chime in anywhere! Open council spot - leio is next on the list. He's willing to join the council. A few of us already voted to confirm him on-list, and we're waiting on the others. Goal: Vote to confirm him, if necessary. There already were enough votes (4/6 I think) to confirm him. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: 3) EAPI in locked down place in the ebuild c) .ebuild in current directory - needs one year wait I'm all for 1 or 3c, because we're not in any rush. I don't see why there's such an immediate need to make as drastic changes as are being suggested for GLEP-55, simply to allow for the possibility of future unknown ebuild mechanisms (like ebuilds not being bash scripts). If ebuilds change significantly from their current form, then and only then, would it be a good time to change the ebuild suffixes. I don't want to get an attachment from bugzilla and find I have to try four different file extensions because whilst the package and version were obvious from the bug, the eapi number wasn't. I also don't want to run into a situation where this package manager supports kdebuilds, whilst that package manager supports gnomebuilds, and a third one supports xfcebuilds. That's just recreating the browser wars, and will leave us with the likes of IE6. I'd be relatively happy with a shebang that specifies the parser or passes the ebuild version, as long as it was standardized, linear and supported by all the PMs (ie, some rogue PM can't suddenly start allowing a myeapi that only it can build)... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmlKQEACgkQu7rWomwgFXoRFACdHfDHuHhj7ojsQV5FvF+rRpRT PgQAoKTq6iAmNLC50a97JHrQghRZK6O0 =ELuP -END PGP SIGNATURE-
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty betelge...@gentoo.org wrote: 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage c) .eapi.new extension - ignored by current Portage Any of the above are fine with me, there is a demonstrated need for this to introduce changes that current portage could not handle. 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension 3.a is just like glep-55, except that the filename extension doesn't change all the time. I like that this will have the benefits of glep-55 plus the benefits of making happy the people who don't want the EAPI in the filename or the extension to change very often. This will effectively change a single EAPI number into a major/minor pair. The major part (the extension name) would only ever change when a major feature is introduced that breaks the current portage rules. The internal EAPI, specified however we like in the major format specification, could be in a fixed location or otherwise easily parseable. Then small changes would alter this minor/internal EAPI value. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim)
[gentoo-dev] Open council spot
* Petteri Räty betelge...@gentoo.org: Donnie Berkholz wrote: Open council spot - leio is next on the list. He's willing to join the council. A few of us already voted to confirm him on-list, and we're waiting on the others. Goal: Vote to confirm him, if necessary. There already were enough votes (4/6 I think) to confirm him. GLEP 39 doesn't specify what happens when a member leaves. It does only talk about slackers. A former council decided to offer any open position to the next in line and if they accept and the current Council unanimously accepts the new person, they get the position. http://www.gentoo.org/proj/en/council/meeting-logs/20070208-summary.txt 4/6 is not unanimously. But... This all was before _reopen_nominations was introduced. With _reopen_nominations I don't see why the council needs to vote at all. There might be a problem if another member leaves as the next two are ranked equally. Thanks
Re: [gentoo-dev] Gentoo Council Reminder for February 26
Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit : On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote: This is your friendly reminder! Same bat time (typically the 2nd 4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! Informal request, but it would be useful to get an idea of the councils views on portage overlay compatibility issues. Specifically, when it comes to gentoo repositories, there is one, and only one definition of what that is- pms's repo spec. The problem here is that the only repository truly conformant to that spec is gentoo-x86, for the rest of the repositories (overlays realistically) whatever portage supports seems to be the eventual standard they grow towards. Problem with this is that there is *zero* way to spot these non-pms repositories as it stands. Simplest example, under portage overlays can unmask pkgs globally (gnome overlay reverting masks in gentoo-x86), I reply here as part of the gnome herd and partly responsible for the mask reverting in the overlay. I didn't know something used in gentoo-x86 couldn't be used in an overlay. Could you point me to the PMS section that treat this ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote: My notes so far: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository c) .ebuild in current directory - needs one year wait 4) eapi as a function; instead of EAPI=1, do eapi 1, required as the first statement (simplest way). pros: - global scope changes can occur (inherit mechanism changes included). - expanding on the first, auto inherits (pkg level) are possible- effectively when eapi gets invoked the manager is in control and can do whatever is desired setting up the env wise. - bash version requirements can be leveled (bash parses as it goes, meaning that essentially it won't parse what follows 'eapi 2' till that command statement finishes) - fits w/ the existing semantics nicely enough. cons: - mangling the version rules for pkgs still isn't possible; no -scm. Arguable if -scm is even desired, but being explicit about it not covering this. - transition is slightly icky; basically one of the following is required- a) for EAPI=2, do 'eapi 3 || die upgrade your manager'. Reason for this is that current managers obviously lack an eapi function, to make managers available *now* blow up the || die is required. This solution can be deployed now, no transition required although at some point stating eapi is required retroactively for all eapis would be wise to eliminate the need for the || die (cut support basically for old managers) b) bashrc trickery, defines an eapi if it's unset. Said eapi function exports EAPI=$1, optionally triggering a die if the eapi isn't 0,1,2 (since any later eapi would require a manager upgrade which would also have the eapi function). Personally, if g54 is ixnayed #4 I tend to think is the best option out there- if g54 is forced in, g55 (or at least something that adjusts the extension to make it invisible to current managers) is required. Commentary? Tend to think #4 is the most aesthetically pleasing to folk, but who knows... ~harring pgpoX8H8NE7jK.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for February 26
On Wed, Feb 25, 2009 at 01:42:38PM +0100, Gilles Dartiguelongue wrote:
Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit :
On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
This is your friendly reminder! Same bat time (typically the 2nd 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !
Informal request, but it would be useful to get an idea of the
councils views on portage overlay compatibility issues.
Specifically, when it comes to gentoo repositories, there is one, and
only one definition of what that is- pms's repo spec. The problem
here is that the only repository truly conformant to that spec is
gentoo-x86, for the rest of the repositories (overlays realistically)
whatever portage supports seems to be the eventual standard they grow
towards.
Problem with this is that there is *zero* way to spot these non-pms
repositories as it stands. Simplest example, under portage overlays
can unmask pkgs globally (gnome overlay reverting masks in
gentoo-x86),
I reply here as part of the gnome herd and partly responsible for the
mask reverting in the overlay. I didn't know something used in
gentoo-x86 couldn't be used in an overlay.
Suspect I wasn't clear; you *can* use things from the parent (although
that whole relationship is outside of PMS); the problem here is that
y'all are reverting something in the *master*.
Literally, bug-buddy was masked in gentoo-x86; enabling your overlay
reverts that masking in *gentoo-x86*. Only reason this even works is
due to portage internals being limited (everything is stacked
together, no true standalones possible).
Could you point me to the PMS section that treat this ?
Flip through the package.mask section (snagging from profiles.tex
directly)-
Note that the \t{-spec} syntax can be used to remove a mask in a
parent profile, but not necessarily a global mask (from
\t{profiles/package.mask}, section~\ref{profiles-package.mask}).
\note Portage currently treats \t{profiles/package.mask} as being on
the leftmost branch of the inherit tree when it comes to \t{-lines}.
This behaviour may not be relied upon.
Note the 'parent profile'. Why they're claiming repo level masking
can't be reversed for that repo, not sure (reasonably sure several
profiles rely on it). Either way, your overlay is trying to revert
entries it doesn't have in that stack.
Only reason it flies for portage is because it collapses it all into
one stack; for managers designed to support multiple standalone repos
that assumption no longer applies, thus that behaviour (outside of
PMS) breaks.
~harring
pgpJ4c3mjvQ3R.pgp
Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for February 26
On Mon, Feb 23, 2009 at 12:56 PM, Donnie Berkholz dberkh...@gentoo.org wrote: This is your friendly reminder! Same bat time (typically the 2nd 4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. This is an informal request for a peaceful compromise on a problem of utmost importance which has the potential to turn into a massive flame-war. Specifically, I'm referring to bug #256614. The latest actions of a recently-recruited 'nirbheek' (belonging to the GNOME herd) on the bug seem to leave the matter in a dicey situation. Needless to say, this matter shadows all other topics on the council's list, and must be resolved ASAP to dampen the inevitable clash of titans. Perhaps the council meeting should be pre-poned to avert an explosion of flaming posts the likes of which haven't been seen this year... yet. Humbly prostrating, ~Nirbheek_who_has_too_many_alter_egos Chauhan -- Resident silly guy and troll
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Tuesday 24 February 2009, Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Thanks for opening a spot to voice our opinions within reasonable limits and without deadlocked discussions. To make it brief, I'd very much prefer 3c[0] for the reasons provided by others before: - From what I can see, it provides for all requirements set out by g55. - There is a backwards-compatible way to implement it. - It does not expose any more internal metadata than current ebuilds do. - I see no rush to implement new EAPI features that require drastic changes enabled by 1*. - It provides a constant face for Gentoo, aka we're the guys and gals using the .ebuild format. Robert [0] Although not with a fixed line limit, but with a strict way to find it, i.e. the first occurence of #?\s*EAPI=[']?([a-zA-Z0-9._]+)[']? or similar. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Wed, 25 Feb 2009 07:34:41 +0100 Tiziano Müller dev-z...@gentoo.org wrote: Well, you could theoretical consider everything in the cache valid within the current scope, find the eapi within the cache or the ebuild and then reconsider things. You can't even do that, because new EAPIs might change how cache entries are validated. An ID might have been moved to a new EAPI using some new EAPI thing (such as changing how inherit works) that doesn't end up altering mtimes in a way that can be caught. Would it be possible to change the cache-format with with G55? Meaning: Have the current cache-format for the current *.ebuild and another for *.ebuild-N (where I mean by cache-format the contents of the cache-files)? If you have GLEP 55 you don't need it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Wed, 25 Feb 2009 09:33:44 +0100 Alexis Ballier aball...@gentoo.org wrote: That sounds like an implementation detail that you could solve by using something else than a flat file database for metadata if open()/read() calls are the slow part. Metadata's shipped with the tree. It's a PMS detail. If we didn't care about package manager performance, we wouldn't be shipping metadata with the tree at all... I would be very surprised if that 2 times factor happens to be true, because finding a string in a file is an order of magnitude simpler than sourcing said file with bash. Moreover this doesn't take into account disk and os cache. No no no. *Opening* the file is the slow part, not searching. The file wouldn't otherwise be opened at all. Thus the only drawback is when you open a file, see there that you can't handle the eapi, then close it and open an older one. Uh. No. The drawback is that you're opening around ten thousand files that would otherwise not be opened. That's a huge cost. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Wed, 25 Feb 2009 04:04:46 +0100 Luca Barbato lu_z...@gentoo.org wrote: given that the simplest thing is hacking ebuild.sh and extract eapi with a simple C program (you can use pcre or ragel if you want) exactly before the ebuild source: That you're bringing ebuild.sh into this shows you still haven't worked out how the process works. There is no need to use ebuild.sh (which is a very good thing, because launching bash is slow) when there's valid metadata. So you have patches for Portage? Please show them. Up there what's enough to check the viability for the solution. No, it's completely wrong. ebuild.sh has nothing to do with this. unknown isn't unsupported? Huh? Please explain what you mean. mv cat/pkg-version.ebuild cat/pkg-version_foo.ebuild emerge -vp pkg portage will warn about not knowing pkg-version_foo and will ignore it. Yes, it will warn noisily. This is unacceptable, since stable users will have months and months of noise when new rules come along. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Wed, 25 Feb 2009 04:04:46 +0100 Luca Barbato lu_z...@gentoo.org wrote: given that the simplest thing is hacking ebuild.sh and extract eapi with a simple C program (you can use pcre or ragel if you want) exactly before the ebuild source: That you're bringing ebuild.sh into this shows you still haven't worked out how the process works. There is no need to use ebuild.sh (which is a very good thing, because launching bash is slow) when there's valid metadata. it there is a valid metadata you have everything there already and you don't have to parse the ebuild so... So you have patches for Portage? Please show them. Up there what's enough to check the viability for the solution. No, it's completely wrong. ebuild.sh has nothing to do with this. Is there another place in portage that extracts the EAPI value? Yes, it will warn noisily. This is unacceptable, since stable users will have months and months of noise when new rules come along. unacceptable... as in it's ugly to see... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote: Yes, it will warn noisily. This is unacceptable, since stable users will have months and months of noise when new rules come along. unacceptable... as in it's ugly to see... No, it's unacceptable because stable users do not need that kind of stuff thrown at them. Stable users use stable because they want a very predictable workflow. Noisy errors that shouldn't affect them(they are in the stable branch) *is* unacceptable, and not just because it's ugly, though that's certainly part of it. -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council -
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Wed, 25 Feb 2009 16:56:04 +0100 Luca Barbato lu_z...@gentoo.org wrote: That you're bringing ebuild.sh into this shows you still haven't worked out how the process works. There is no need to use ebuild.sh (which is a very good thing, because launching bash is slow) when there's valid metadata. it there is a valid metadata you have everything there already and you don't have to parse the ebuild so... Except you can't tell whether the metadata is valid unless you already know the EAPI. As you have already been told. So you have patches for Portage? Please show them. Up there what's enough to check the viability for the solution. No, it's completely wrong. ebuild.sh has nothing to do with this. Is there another place in portage that extracts the EAPI value? Yup. The part where it reads the metadata cache. Yes, it will warn noisily. This is unacceptable, since stable users will have months and months of noise when new rules come along. unacceptable... as in it's ugly to see... No, as in it'll result in zillions of users wondering what's going on and why their screen is getting spammed, and zillions of bug reports and forum posts. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] [RFC] QA bashism check on portage
Hi, what do you think about checking for bashism on install_qa_check? Obviously only for scripts with #!/bin/sh and #!/sbin/runscript as first line. I think checkbashisms.pl [1] could be a good start point. [1] http://svn.debian.org/viewsvn/devscripts/trunk/scripts/checkbashisms.pl -- Timothy `Drizzt` Redaelli FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Wed, 25 Feb 2009 09:33:44 +0100 Alexis Ballier aball...@gentoo.org wrote: That sounds like an implementation detail that you could solve by using something else than a flat file database for metadata if open()/read() calls are the slow part. Metadata's shipped with the tree. It's a PMS detail. If we didn't care about package manager performance, we wouldn't be shipping metadata with the tree at all... I would be very surprised if that 2 times factor happens to be true, because finding a string in a file is an order of magnitude simpler than sourcing said file with bash. Moreover this doesn't take into account disk and os cache. No no no. *Opening* the file is the slow part, not searching. The file wouldn't otherwise be opened at all. Thus the only drawback is when you open a file, see there that you can't handle the eapi, then close it and open an older one. Uh. No. The drawback is that you're opening around ten thousand files that would otherwise not be opened. That's a huge cost. Huge cost... emerge -uDp world (cold os cache) real1m10.353s user0m17.077s sys 0m0.440s with eapitool getting the eapi before sourcing. real1m10.636s user0m16.941s sys 0m0.368s cold cache, no metadata available real6m23.106s user3m32.141s sys 1m50.855s with eapitool real6m26.564s user3m31.853s sys 1m50.511s I'd rather see more people backing their ideas with numbers... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Thomas Anderson wrote: On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote: Yes, it will warn noisily. This is unacceptable, since stable users will have months and months of noise when new rules come along. unacceptable... as in it's ugly to see... No, it's unacceptable because stable users do not need that kind of stuff thrown at them. Stable users use stable because they want a very predictable workflow. Noisy errors that shouldn't affect them(they are in the stable branch) *is* unacceptable, and not just because it's ugly, though that's certainly part of it. You have quite a good point here. It's purely cosmetical, but since it's an unexpected behavior and it's annoying and could alienate our users it's better to avoid it with all our strength. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Wed, 25 Feb 2009 17:17:29 +0100 Luca Barbato lu_z...@gentoo.org wrote: I'd rather see more people backing their ideas with numbers... I already told you your numbers are nonsense. Of course opening the file when you've already opened it isn't going to make any difference. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down Yuck, I want per-package eclasses and all those other goodies. 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage 2a please, though .ebuild.eapi would be fine as well. My reasons are mostly contained in Antarus' glep revision, and the fact that there have been no real valid(IMO) objections. 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository c) .ebuild in current directory - needs one year wait These are all ugly.(c is the worst). Oh, And I certainly hope this is not Democracy(you know what they say, democracy is two wolves and a sheep deciding who to have for dinner) Looking forward to the council meeting, where there will *hopefully* be a decision. Thomas -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgpFU0kxFHMxR.pgp Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Ulrich Mueller wrote: On Wed, 25 Feb 2009, Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. I've already commented on this in December 2007 [1], and my opinion hasn't changed. 1) Status quo 2) EAPI in file extension 3) EAPI in locked down place in the ebuild a) new extension b) new subdirectory like ebuilds/ c) .ebuild in current directory Acceptable for me would be 1) and 3c). I have also stated my opinion before. But I agree with Ulrich. -Joe
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Everyone is only allowed to post a single reply to this thread in order to make it easy to read through. The existing thread should be used for actual discussion about the GLEP and the alternatives. This should be a useful experiment to see if we can control ourselves :) My notes so far: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository c) .ebuild in current directory - needs one year wait Leave EAPI inside the ebuild. That's where I want to find it. Oh, and as others have mentioned, CVS sucks for file renaming and versions. Yet another reason to leave it inside the ebuild. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Brian Harring wrote: 4) eapi as a function; instead of EAPI=1, do eapi 1, required as the first statement (simplest way). pros: - global scope changes can occur (inherit mechanism changes included). - expanding on the first, auto inherits (pkg level) are possible- effectively when eapi gets invoked the manager is in control and can do whatever is desired setting up the env wise. - bash version requirements can be leveled (bash parses as it goes, meaning that essentially it won't parse what follows 'eapi 2' till that command statement finishes) - fits w/ the existing semantics nicely enough. cons: - mangling the version rules for pkgs still isn't possible; no -scm. Arguable if -scm is even desired, but being explicit about it not covering this. - transition is slightly icky; basically one of the following is required- a) for EAPI=2, do 'eapi 3 || die upgrade your manager'. Reason for this is that current managers obviously lack an eapi function, to make managers available *now* blow up the || die is required. This solution can be deployed now, no transition required although at some point stating eapi is required retroactively for all eapis would be wise to eliminate the need for the || die (cut support basically for old managers) b) bashrc trickery, defines an eapi if it's unset. Said eapi function exports EAPI=$1, optionally triggering a die if the eapi isn't 0,1,2 (since any later eapi would require a manager upgrade which would also have the eapi function). Personally, if g54 is ixnayed #4 I tend to think is the best option out there- if g54 is forced in, g55 (or at least something that adjusts the extension to make it invisible to current managers) is required. Commentary? Tend to think #4 is the most aesthetically pleasing to folk, but who knows... ~harring I really like this idea, but nobody else seems to have commented on it. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] [RFC] QA bashism check on portage
On Wednesday 25 February 2009 11:10:01 Timothy Redaelli wrote: what do you think about checking for bashism on install_qa_check? Obviously only for scripts with #!/bin/sh and #!/sbin/runscript as first line. I think checkbashisms.pl [1] could be a good start point. [1] http://svn.debian.org/viewsvn/devscripts/trunk/scripts/checkbashisms.pl i recall it being incorrect in some cases (it checked for what dash supports, not what POSIX supports), but that was a while ago, so maybe my experience is dated at this point. otherwise, integrating it sounds sane to me, and if we can push fixes back to debian, even better. a repoman check on files in files/ would be useful as well i'd think -mike
Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)
On Wed, 25 Feb 2009 04:49:51 -0800 Brian Harring ferri...@gmail.com wrote: 4) eapi as a function; instead of EAPI=1, do eapi 1, required as the first statement (simplest way). Doesn't solve anything over having it as a variable, and has a messy upgrade path. - global scope changes can occur (inherit mechanism changes included). Global scope changes can no more occur than they can with it as a variable. All it does is changes where the barfing occurs to slightly earlier on. - transition is slightly icky; basically one of the following is required- a) for EAPI=2, do 'eapi 3 || die upgrade your manager'. Reason for this is that current managers obviously lack an eapi function, to make managers available *now* blow up the || die is required. This solution can be deployed now, no transition required although at some point stating eapi is required retroactively for all eapis would be wise to eliminate the need for the || die (cut support basically for old managers) Global scope die is very very messy. This leaks out to users in the form of horrible messages that make the user think something's badly broken. b) bashrc trickery, defines an eapi if it's unset. Said eapi function exports EAPI=$1, optionally triggering a die if the eapi isn't 0,1,2 (since any later eapi would require a manager upgrade which would also have the eapi function). Unportable, and still leaks out to users. This whole thing only looks neat until you think about it... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)
On Wed, Feb 25, 2009 at 11:03:07PM +, Ciaran McCreesh wrote: On Wed, 25 Feb 2009 04:49:51 -0800 Brian Harring ferri...@gmail.com wrote: 4) eapi as a function; instead of EAPI=1, do eapi 1, required as the first statement (simplest way). Doesn't solve anything over having it as a variable, and has a messy upgrade path. - global scope changes can occur (inherit mechanism changes included). Global scope changes can no more occur than they can with it as a variable. All it does is changes where the barfing occurs to slightly earlier on. Bullshit. First invocation of the ebuild, that means it can do whatever it wants to the environment- literally swapping in the EAPI environment right then/there. Auto inherits, changing the inherit mechanism, everything (this includes shopt adjustments). Not even sure why you're arguing that one, but back it up w/ examples if you want to continue that line of FUD. - transition is slightly icky; basically one of the following is required- a) for EAPI=2, do 'eapi 3 || die upgrade your manager'. Reason for this is that current managers obviously lack an eapi function, to make managers available *now* blow up the || die is required. This solution can be deployed now, no transition required although at some point stating eapi is required retroactively for all eapis would be wise to eliminate the need for the || die (cut support basically for old managers) Global scope die is very very messy. This leaks out to users in the form of horrible messages that make the user think something's badly broken. One would think upgrade your manager would be... self explanatory. Regardless, spelling it out- the user visible barf is only visible on existant managers. For any manager supporting eapi2 (thus having the function), the function can exist out cleanly (no stderr complaints) from sourcing at that point without issue. b) bashrc trickery, defines an eapi if it's unset. Said eapi function exports EAPI=$1, optionally triggering a die if the eapi isn't 0,1,2 (since any later eapi would require a manager upgrade which would also have the eapi function). Unportable, and still leaks out to users. Two options were given there; one 'leaks out to users', the other is the old behaviour (eapi env setting)- again, this is only visible for the window of pre eapi 3 managers, meaning it's a one time hit (rather then continual as you're implying). Every proposal has uglyness- g55 for example doesn't give the user any indication that they're not seeing ebuilds due to EAPI (in other words loss of functionality that exists now). ~brian pgpFxhOALMjzu.pgp Description: PGP signature
Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)
On Wed, 25 Feb 2009 16:02:46 -0800 Brian Harring ferri...@gmail.com wrote: Bullshit. First invocation of the ebuild, that means it can do whatever it wants to the environment- literally swapping in the EAPI environment right then/there. Auto inherits, changing the inherit mechanism, everything (this includes shopt adjustments). Not even sure why you're arguing that one, but back it up w/ examples if you want to continue that line of FUD. You can do that on a variable assignment too, with all the same implications as having it as a function, and a slightly less horrible upgrade path. Global scope die is very very messy. This leaks out to users in the form of horrible messages that make the user think something's badly broken. One would think upgrade your manager would be... self explanatory. Regardless, spelling it out- the user visible barf is only visible on existant managers. For any manager supporting eapi2 (thus having the function), the function can exist out cleanly (no stderr complaints) from sourcing at that point without issue. Which is a wait a year or more thing... If you do it with a variable instead of a function, you can at least roll out EAPI 3 (without any global scope changes, but with the stricter stop on setting an unsupported EAPI requirement) without the wait. Every proposal has uglyness- g55 for example doesn't give the user any indication that they're not seeing ebuilds due to EAPI (in other words loss of functionality that exists now). Given you're a proponent of not showing users things that're merely masked... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)
On Thu, Feb 26, 2009 at 12:11:04AM +, Ciaran McCreesh wrote: On Wed, 25 Feb 2009 16:02:46 -0800 Brian Harring ferri...@gmail.com wrote: Bullshit. First invocation of the ebuild, that means it can do whatever it wants to the environment- literally swapping in the EAPI environment right then/there. Auto inherits, changing the inherit mechanism, everything (this includes shopt adjustments). Not even sure why you're arguing that one, but back it up w/ examples if you want to continue that line of FUD. You can do that on a variable assignment too, with all the same implications as having it as a function, and a slightly less horrible upgrade path. You're contradicting your own statements. Pkg level eclasses (if reusing inherit) would explode 'in a user visible manner' if using var only. While the above wasn't FUD, definitely was misinfo. Be consistant please. Global scope die is very very messy. This leaks out to users in the form of horrible messages that make the user think something's badly broken. One would think upgrade your manager would be... self explanatory. Regardless, spelling it out- the user visible barf is only visible on existant managers. For any manager supporting eapi2 (thus having the function), the function can exist out cleanly (no stderr complaints) from sourcing at that point without issue. Which is a wait a year or more thing... If you do it with a variable instead of a function, you can at least roll out EAPI 3 (without any global scope changes, but with the stricter stop on setting an unsupported EAPI requirement) without the wait. There is no reason to wait a year let alone wait for EAPI3 to be defined. The eapi function could be added now in preparation (thus killing the user visible pukage), regardless of eapi 3's timeline. The die exists strictly to be thorough about stragglers. Every proposal has uglyness- g55 for example doesn't give the user any indication that they're not seeing ebuilds due to EAPI (in other words loss of functionality that exists now). Given you're a proponent of not showing users things that're merely masked... Say what you want; g55 still has the flaw. ~harring pgpwhFk5mXa6f.pgp Description: PGP signature
Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)
On Wed, 25 Feb 2009 16:24:45 -0800 Brian Harring ferri...@gmail.com wrote: You can do that on a variable assignment too, with all the same implications as having it as a function, and a slightly less horrible upgrade path. You're contradicting your own statements. Pkg level eclasses (if reusing inherit) would explode 'in a user visible manner' if using var only. No, if we're shoving retroactive changes into existing EAPIs (as would be done for making eapi a function), we could instead say EAPI must be assigned to only once. That has *exactly* the same implications as having it as a function, except that the upgrade path is cleaner because there's no need for the horrid global scope die to work around existing package managers. Which is a wait a year or more thing... If you do it with a variable instead of a function, you can at least roll out EAPI 3 (without any global scope changes, but with the stricter stop on setting an unsupported EAPI requirement) without the wait. There is no reason to wait a year let alone wait for EAPI3 to be defined. The eapi function could be added now in preparation (thus killing the user visible pukage), regardless of eapi 3's timeline. The die exists strictly to be thorough about stragglers. But there's no need for the die if you do it on a variable instead of a function. Every proposal has uglyness- g55 for example doesn't give the user any indication that they're not seeing ebuilds due to EAPI (in other words loss of functionality that exists now). Given you're a proponent of not showing users things that're merely masked... Say what you want; g55 still has the flaw. Any sane package manager can, immediately upon a new EAPI being defined, do a stable release updated with minimal information about the new EAPI to enable it to show up as being there but not supported, even if full support needs a new major version and lots of ~arch testing time. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Wed, 25 Feb 2009 16:02:46 -0800 Brian Harring ferri...@gmail.com wrote: snip a few arguments Ciaran and Brian, please respect Pettery's request and move your discussion to the GLEP55 thread or to another thread, but leave it out of this one. Ciaran, please stop abusing other subscribers of the dev ml. Ultimately everyone wants a resolution to this issue but have potentially different ideas of the way to go about that. So different ideas for a solution should be encouraged, not fought. You're obviously free to argue your case and I'm not trying to silence you, but by replying to every and single mail in quite a few cases in a harsh tone, you're behaving like a bully. Please stop that. For anyone else acting overly defensive, please remember that these are technical discussions, so you should expect technical arguments and having your ideas challenged. Also, everyone should be careful not to let emotions affect their arguments. For userrel, - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkml5cAACgkQcAWygvVEyAKrmgCfZK4wpk0+PcZPCftsAyloEhDK 4DkAoJGspbLcPYb0f+FkZqVgb/kGWYhU =SSGP -END PGP SIGNATURE-
Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)
On Wed, 25 Feb 2009 23:43:44 -0100 Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: Ciaran McCreesh wrote: On Wed, 25 Feb 2009 16:02:46 -0800 Brian Harring ferri...@gmail.com wrote: snip a few arguments Ciaran and Brian, please respect Pettery's request and move your discussion to the GLEP55 thread or to another thread, but leave it out of this one. This was moved to another thread, as a casual glance at the subject would have told you. please stop abusing other subscribers of the dev ml. Ultimately everyone wants a resolution to this issue but have potentially different ideas of the way to go about that. So different ideas for a solution should be encouraged, not fought. You're obviously free to argue your case and I'm not trying to silence you, but by replying to every and single mail in quite a few cases in a harsh tone, you're behaving like a bully. Please stop that. One of the nice things about technical discussions is that it is entirely possible for one particular party to be entirely wrong. In this case, Brian is entirely wrong, and calling him on it is the correct thing to do. If you would prefer to see fewer emails from me, perhaps you should start telling people who post the same incorrect claims that have already been demonstrated to be false over and over again to stop it. One of the unfortunate tendencies the Council has shown in the past is to treat any unreplied-to objection as being legitimate and cause for an issue to be postponed, even if that issue has already been addressed earlier on. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Everyone is only allowed to post a single reply to this thread in order to make it easy to read through. The existing thread should be used for actual discussion about the GLEP and the alternatives. This should be a useful experiment to see if we can control ourselves :) My notes so far: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository c) .ebuild in current directory - needs one year wait Regards, Petteri Another option which I haven't seen mentioned here yet would be to just specify that the method of finding the EAPI depends on the file extension. Then, anything with a .ebuild extension can be sourced with bash to find the EAPI, and ebuild formats incompatible with that could use another file extension. This would work with current package managers, while still providing a mechanism for incompatible format changes in the future. It's also aesthetically nicer than current proposals, since the file extension would indicate something about the contents of the file. Or, to put it another way, this would formalize the difference between the ebuild format (which is currently bash throughout the tree), and the EAPI. I don't think anybody would oppose a file extension change for a format change, as opposed to an EAPI change. --Ravi
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Everyone is only allowed to post a single reply to this thread in order to make it easy to read through. The existing thread should be used for actual discussion about the GLEP and the alternatives. This should be a useful experiment to see if we can control ourselves :) I was talking to Alec last night in -dev (yes, I'm still alive), and I tossed out the idea of using metadata.xml instead of mangling the ebuild filename or even sticking it as the first line in the ebuild (as a hashbang or something gentoo-specific, for example). It's nothing fully fleshed out, and I know parsing XML is about as much fun as sticking your tongue into a cross-cut paper shredder, but I figured why not toss it out there? Add a tag like this to metadata.xml eapi pv=2.6.28.7 version=1 / pv = Package Version (incl. revision if needed). v = EAPI version. Other variants: eapi version=1mips-sources-2.6.28.7/eapi eapi pv=2.6.28.71/eapi and such. This allows portage or whatever to associate the chosen/desired EAPI level with a given ebuild version in portage (so the above examples would match mips-sources-2.6.28.7.ebuild) I think there's some other magic going on after metadata is updated in portage, like the whole use.local.desc auto-updating. I figure something like this could also be implemented, maybe even in the same way whereby a backend script parses this out and create a /usr/portage/profiles/eapi.list file that links package revisions with the set eapi level. Then let the various package managers do whatever it is that they do to make use of this information. Call it random brainstorming. No idea on the pros cons -- I haven't even looked at g55 just yet. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Everyone is only allowed to post a single reply to this thread in order to make it easy to read through. The existing thread should be used for actual discussion about the GLEP and the alternatives. This should be a useful experiment to see if we can control ourselves :) My notes so far: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down I don't want to stick with the status quo since being able to probe the EAPI without sourcing the ebuild is quite useful. Among other things, it allows the package manager to avoid the overhead of sourcing the ebuild in case neither the EAPI nor the cache format is understood, which solves a problem [1] discussed in the thread about adding DIGESTS data to the cache. 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage I'd prefer not to introduce an infinite series of file extensions. To me that just seems too unconventional. b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage Either of these is fine with me. 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache I think it's alright to change the EAPI in an existing ebuild. Since you can simply parse the EAPI instead of sourcing the ebuild, having a valid cache isn't so important. - Does not allow changing versioning rules unless version becomes a normal metadata variable As said by Richard [2], it's alright to change the version rules. Since you can simply parse the EAPI, it's not appreciably less accessible than if the EAPI is embedded in the file name. * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked Accessing the cache or parsing the EAPI is relatively inexpensive compared to sourcing the ebuild, so it's not really a problem. Again, once you can parse the EAPI, it's not appreciably less accessible then if the EAPI is embedded in the file name. a) new extension I think a new extension is preferable to a directory. b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository c) .ebuild in current directory - needs one year wait You really only need to wait in order to avoid things like warning messages about invalid name/version (if you want to do naming convention changes). If the name/version appear valid, the existing cache entries will prevent the ebuild from being sourced by existing versions of portage (as long as the timestamp of the cache entry matches the timestamp of the ebuild). [1] http://archives.gentoo.org/gentoo-dev/msg_d667a0dd748b2fefa5a5378000104974.xml [2] http://archives.gentoo.org/gentoo-dev/msg_bf3aa0199bb521b263b19b4997a0429c.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmmKkoACgkQ/ejvha5XGaP+2gCfZvkKYypzKydZ+1+sShQkJKr3 ObAAoNr1r9E9eNRCAisahJyqcu6FDV3S =kj8B -END PGP SIGNATURE-
Re: [gentoo-dev] http://bugs.gentoo.org/show_bug.cgi?id=232084
fyi my email client doesn't recognize urls in the subject line, don't know about anyone elses... but it'd be nice to click the link to the bug, and you know have some clue what this is about without reading the bug (e.g. a useful subject line). /endrant sorry I can't be of any further help here. On Tue, Feb 24, 2009 at 12:57 AM, Andrew D Kirch trel...@trelane.net wrote: Thanks for the help. -- Caleb Cushing http://xenoterracide.blogspot.com
