Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Mon, 24 Dec 2007 06:03:12 + Steve Long <[EMAIL PROTECTED]> wrote: > * Set the EAPI inside the ebuild in a way that makes it easy to > fetch it This is ok as atm only EAPI=1 is in the tree, so there is no > backward compatibility issue. It's both a backwards and a forwards compatibility issue. > * Have a new ebuild/eclass extension ".eapi-$EAPI" > This is for ebuilds for other package managers; it is envisaged by > some that this will become the new ebuild format since it enables > quick access to the EAPI without accessing the file contents. Full > ebuild names are the primary key for the portage database. Full ebuild names as a primary key is bad. It means you have to normalise versions early on -- equality and equivalence are different for ebuild names already. And eclasses are an entirely separate issue. They need to be dealt with differently, ideally starting with EAPI 2. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Piotr Jaroszy?ski wrote: > Hello, > > I have updated the GLEP, hopefully it is less confusing now and hence the > discussion will be more technical. > Based on your summary of the suggestions on the list, I believe you misunderstood what many of us were arguing for. * Set the EAPI inside the ebuild in a way that makes it easy to fetch it This is ok as atm only EAPI=1 is in the tree, so there is no backward compatibility issue. AND * Have a new ebuild/eclass extension ".eapi-$EAPI" This is for ebuilds for other package managers; it is envisaged by some that this will become the new ebuild format since it enables quick access to the EAPI without accessing the file contents. Full ebuild names are the primary key for the portage database. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-dev-announce] New developer : Richard Freeman (rich0)
Denis Dupeyron wrote: > So please everybody, give a warm welcome to Richard. Richard, big welcome! -Joe -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: EAPI placement
Carsten Lohrke wrote: > On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote: >> * Eclasses may not set EAPI. >> >> * Eclasses may not assume a particular EAPI. > > I disagree here. It would be annoying and possibly even hindering in > future not being able to use higher EAPI features in eclasses. Point is > the eclass has to check, if the author of an ebuild sets another EAPI and > throw an error, in this case. > Agreed. There's no problem from the bash side of this, only the PM specific code. > The most basic issue, which we didn't even discuss yet, afaik, is how to > make every developer aware which feature belongs to which EAPI. I freely > admit, I do not know that. Is there a list somewhere? > Well the official one is the internal Gentoo PMS repo. The Council haven't changed the policy so far this term on what is the "authoritative" PMS. (Nor of course have they accepted any of the drafts officially.) > EAPI issues may lead to a lot of confusion and eclass bloat, especially > since we still can't remove stale eclasses afaik. > Another maintenance headache, agreed. Is it possible to remove an eclass if it can be shown that there are no apps in the tree using it, say for over 2 years? That would give Gentoo equivalence with longer-term "support" from other distros, while allowing some breathing space wrt installed ebuilds. It'd be easy enough to automate a hook to move deleted eclasses to local overlay as well. > On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote: >> Nobody said that eclasses can't use new features. > > Using new features in ebuilds or eclasses relates. EAPI A using ebuild > with EAPI B using eclass (but not defining any EAPI) is your hard nut. > Shouldn't happen, but will. And bugs in eclasses unfortunately don't have > a minor impact. > >> Just that they >> cannot _set_ EAPI or assume they are working with any EAPI. > > And I say they can - under the condition that you have a defined subset of > ebuilds belonging to that eclass. And it's a major loss of flexibility in addition to the maintenance problems you highlight. A dynamic EAPI declaration in an ebuild is foolish, but testing the EAPI value in an eclass and taking alternative action, or indeed allowing dynamic setting in that context (which would require additional metadata-- in this case i think the overhead is worth it, given that eclasses are much less numerous than ebuilds, and it's actually *adding* to what we can do already) makes a lot more sense. the kde4 eclasses in the kde4-experimental overlay set eapi=1. it's fine to do that, it's just too early to do that on lots of eclasses in the main tree, because EAPI=1 is too new So there's no technical reason not to to, apart from some concern about signalling die()? I think putting EAPI above inherit is bad because you're relying on the ebuild author to audit all the eclass code to know which EAPI version is required Ouch. Well at least EAPI anything is still experimental atm. Thank heavens for peer review :D -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New developer : Richard Freeman (rich0)
Denis Dupeyron wrote: > Richard is married and has two children. Yay a parent! (How many are there? I can only think of Neddy..) > So please everybody, give a warm welcome to Richard. > Well done Rich :D -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sun, 23 Dec 2007 14:54:16 +0100
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> On 2007/12/23, Ciaran McCreesh <[EMAIL PROTECTED]>
> wrote:
> > a) It's a massive restriction on what future ebuilds can do.
>
> - it handles a reasonnable range of likely future EAPIs,
It doesn't, though. For example, any good solution to the current eclass
EAPI issues is likely to break it.
> - it includes the "extension changes when the way to extract EAPI
> has to change" to avoid bounding future EAPIs to this range.
Which we'll need to take anyway at some point.
> > c) It's an extremely bizarre restriction, the likes of which do not
> > currently exist, that will confuse the hell out of all the people
> > that don't realise that such a restriction exists.
>
> Devs are already used to follow numerous conventions in the way they
> format their ebuilds.
And they already arbitrarily don't follow them. We get people screwing
up whitespace and brackets in dep strings, for example (Portage doesn't
error check these very well).
> > d) It introduces a new prepass parse layer to an already complex
> > process.
>
> Both solutions add some new steps to this process, and it doesn't look
> to me like there's a significant difference beetween their respective
> added complexity. That said, you're the PM dev here, not me, so if
> you confirm that implementation of an in-contents solution is
> significantly harder, then i will accept the argument.
It's not harder (assuming the syntax is well defined -- single, double
or no quotes? export? leading whitespace? is it the first or the last
match of EAPI="" that's taken?). It's just messy, because we'd have to
deal with stupid cases like:
DESCRPTION="Config file to make Paludis support
EAPI='4' packages"
EAPI="1"
export EAPI=2
src_compile() {
cat < somefile
EAPI=3
END
}
> > e) The Portage guys said no to it.
>
> When/where? I've only seen Marius commenting here, but not on that
> aspect. Also, i've read this 2005 "EBUILD_FORMAT" discussion that
> Steve Long has pointed [1], where Brian was against non-Bash parsing,
> but:
> - he was against changing files extension too,
> - the flaws in the EAPI system designed at this time is what led to
> rethinking it now.
>
> If i've missed something since then (and that's likely), could you
> give me a pointer to the archives? Thanks.
A while after that Brian and I had a huge lengthy argument on IRC about
it. I don't have IRC logs that far back, which is kind of a shame
because we covered pretty much all of the things that people are
moaning about now...
(And you'd also see the highly silly political reasons that lead to
*.ebuild* not being adopted straight off.)
> > > (until some unlikely conditions are met, like a switch away from
> > > Bash format).
> >
> > Or until we do something about eclasses and EAPIs,
>
> If you're not more specific about this "something", it's hard to say
> what solution will handle it best.
If I had a perfect solution to the eclass problem, I'd've posted it
ages ago... But it's fairly likely that a good solution will require
considerably more flexibility than a simple static value in an ebuild
file.
> My point here is that the in-contents alternative is just a syntaxic
> rule which defines a first-pass extraction of a value from an ebuild
> file (as opposed to an ebuild file name extension). How it is then
> used (what the "eapi" function does, if anything, or whether this
> value is the definitive EAPI, or how EAPI vs. eclasses is handled,
> etc.) can be subject to future changes depending on this value. That's
> part of why this solution is not more restrictive than the file name
> extension approach.
But then you get the highly weird result of setting, say, EAPI="4" in
the ebuild but the c/p-v actually having EAPI="3" because of weird hard
to see behind the scenes eclass voodoo. That's equivalent to the "using
the wrong file extension and then overriding with a variable"
situation, except that you're effectively requiring it for future
changes rather than making it something that's a big flashy warning.
(From a technical perspective, changing EAPI mid-source is a massive
pain in the ass. EAPI pretty much has to be able to tinker with PATH
and friends, and there's no sane way of modifying variables as soon as
another variable changes. For example, and not saying that this
specific case is desirable, EAPI foo could require that the first 'sed'
in PATH be GNU sed, whilst EAPI bar could require that it be the normal
system sed.)
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] New developer : Richard Freeman (rich0)
On Sun, 23 Dec 2007 10:19:30 +0100 "Denis Dupeyron" <[EMAIL PROTECTED]> wrote: > So please everybody, give a warm welcome to Richard. Welcome, Richard! JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 04:19:45 +0100 > Luca Barbato <[EMAIL PROTECTED]> wrote: >> Piotr Jaroszyński wrote: >>> On Thursday 20 of December 2007 19:29:22 Zhang Le wrote: So please make those people understand, so they can comment usefully. >>> Are we in the elementary school or something? This is really >>> getting ridiculous. >> ietf.org Are they ridiculous? > > Do you see them explaining what TCP is in great detail in every single > publication that mentions TCP? > usually pointing rfc793 in the right reference section and having an xref pointing it directly embedded on the text referencing it. So, yes. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 16:49:10 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh wrote: As long as there is an agreement in any given point of time, it is OK. Such as, put your EAPI definition on the first line of your ebuild, like EAPI="value" >>> No good for package managers written before the agreement. >> Why not force user to upgrade their PM? > > That's a) exactly what we're trying to avoid with EAPIs, I guess it was giving a smooth upgrade path > b) no good because there isn't a sane way of forcing a package manager > upgrade and Say why? > c) another one of those "wait a year until we can use anything" things. Or spend 6 months discussing something that may or may not be accepted because lacks enough documentation to be decided on... lu - and 2008 is just next week.. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-12-23 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2007-12-23 23h59 UTC. Removals: dev-db/xpg 2007-12-19 03:52:10 wltjr dev-db/firebird-docs2007-12-19 04:02:10 wltjr dev-java/blackdown-java3d-bin 2007-12-19 04:17:15 wltjr sys-auth/pam_console2007-12-20 15:44:50 flameeyes Additions: media-gfx/qtpfsgui 2007-12-17 10:46:48 maekke x11-plugins/lightning 2007-12-17 18:44:52 armin76 dev-ruby/shorturl 2007-12-17 22:08:19 flameeyes dev-ruby/activeresource 2007-12-18 07:03:34 graaff dev-python/coverage 2007-12-18 07:33:18 robbat2 sys-kernel/kerneloops 2007-12-18 17:23:33 gregkh media-video/isight-firmware-tools 2007-12-19 11:30:44 genstef sys-process/incron 2007-12-19 20:50:03 hollow dev-haskell/parsec 2007-12-20 03:04:15 dcoutts dev-haskell/stm 2007-12-20 03:05:34 dcoutts dev-haskell/parallel2007-12-20 03:06:57 dcoutts x11-libs/qt-webkit 2007-12-20 12:25:40 caleb x11-libs/qt-phonon 2007-12-20 12:26:40 caleb x11-libs/qt-qt3support 2007-12-20 13:01:44 caleb x11-libs/qt-dbus2007-12-20 13:16:56 caleb x11-libs/qt-opengl 2007-12-20 16:33:02 caleb app-admin/eselect-ctags 2007-12-21 08:45:39 ulm app-emacs/whine 2007-12-21 14:50:24 ulm x11-libs/qt-core2007-12-21 18:59:13 caleb x11-libs/qt-test2007-12-21 19:03:20 caleb x11-libs/qt-sql 2007-12-21 19:04:14 caleb x11-libs/qt-script 2007-12-21 19:05:53 caleb x11-libs/qt-gui 2007-12-21 19:10:35 caleb x11-libs/qt-svg 2007-12-21 19:12:41 caleb x11-libs/qt-xmlpatterns 2007-12-21 20:03:25 caleb sci-libs/mmdb 2007-12-21 23:23:46 dberkholz net-ftp/filezilla 2007-12-22 04:27:55 jsin net-fs/nfs4-acl-tools 2007-12-22 07:19:20 vapier app-emulation/open-vm-tools 2007-12-22 17:32:11 ikelos app-arch/funzix 2007-12-22 20:37:31 vapier media-plugins/vdr-graphtft 2007-12-23 22:05:09 hd_brummy -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-db/xpg,removed,wltjr,2007-12-19 03:52:10 dev-db/firebird-docs,removed,wltjr,2007-12-19 04:02:10 dev-java/blackdown-java3d-bin,removed,wltjr,2007-12-19 04:17:15 sys-auth/pam_console,removed,flameeyes,2007-12-20 15:44:50 Added Packages: media-gfx/qtpfsgui,added,maekke,2007-12-17 10:46:48 x11-plugins/lightning,added,armin76,2007-12-17 18:44:52 dev-ruby/shorturl,added,flameeyes,2007-12-17 22:08:19 dev-ruby/activeresource,added,graaff,2007-12-18 07:03:34 dev-python/coverage,added,robbat2,2007-12-18 07:33:18 sys-kernel/kerneloops,added,gregkh,2007-12-18 17:23:33 media-video/isight-firmware-tools,added,genstef,2007-12-19 11:30:44 sys-process/incron,added,hollow,2007-12-19 20:50:03 dev-haskell/parsec,added,dcoutts,2007-12-20 03:04:15 dev-haskell/stm,added,dcoutts,2007-12-20 03:05:34 dev-haskell/parallel,added,dcoutts,2007-12-20 03:06:57 x11-libs/qt-webkit,added,caleb,2007-12-20 12:25:40 x11-libs/qt-phonon,added,caleb,2007-12-20 12:26:40 x11-libs/qt-qt3support,added,caleb,2007-12-20 13:01:44 x11-libs/qt-dbus,added,caleb,2007-12-20 13:16:56 x11-libs/qt-opengl,added,caleb,2007-12-20 16:33:02 app-admin/eselect-ctags,added,ulm,2007-12-21 08:45:39 app-emacs/whine,added,ulm,2007-12-21 14:50:24 x11-libs/qt-core,added,caleb,2007-12-21 18:59:13 x11-libs/qt-test,added,caleb,2007-12-21 19:03:20 x11-libs/qt-sql,added,caleb,2007-12-21 19:04:14 x11-libs/qt-script,added,caleb,2007-12-21 19:05:53 x11-libs/qt-gui,added,caleb,2007-12-21 19:10:35 x11-libs/qt-svg,added,caleb,2007-12-21 19:12:41 x11-libs/qt-xmlpatterns,added,caleb,2007-12-21 20:03:25 sci-libs/mmdb,added,dberkholz,2007-12-21 23:23:46 net-ftp/filezilla,added,jsin,2007-12-22 04:27:55 net-fs/nfs4-acl-tools,added,vapier,2007-12-22 07:19:20 app-emulation/open-vm-tools,added,ikelos,2007-12-22 17:32:11 app-arch/funzix,added,vapier,2007-12-22 20:37:31 media-plugins/vdr-graphtft,added,hd_brummy,2007-12-23 22:05:09 Done.
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Duncan wrote: > Steve Long <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Sat, 22 Dec 2007 06:35:07 > +: > >> Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just >> do what he says. > >> [1] >> http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh- > uncensored > > I read the same interview and didn't take it like that, but regardless, > why are you dropping this discussion to a new low? Until you came along, > altho there was disagreement, people were at least maintaining some > civility in the discussion. Then you come along, and I see multiple > personal attack posts. That's not right, and until now, we'd avoided it. > > Please apologize. Just because you don't agree with someone doesn't mean > you have to take it to the level you just have, and it does NOT help. (I > thank you for your agreement with me, as it happens, disagreeing with > Ciaran, on the users thing, but again, we had kept it civil. Here, you > aren't, and it doesn't belong on the list, and regardless of whether you > just agreed with me or not, you need called on it, and I don't see any > other posts doing it yet, so...) > I don't accept that I took it to that level, but I apologise unreservedly for responding to it. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Thu, 2007-12-20 at 19:57 +0100, Markus Meier wrote: > > java5 6 I think eventually we want to do something else there and possibly get rid of that flag. Otherwise we would also end up with java6, java7, ... We aren't exactly saying don't do it, but don't think we would want to push it globally. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 2007/12/23, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > a) It's a massive restriction on what future ebuilds can do. - it handles a reasonnable range of likely future EAPIs, - it includes the "extension changes when the way to extract EAPI has to change" to avoid bounding future EAPIs to this range. > b) It's a massive restriction on what current ebuilds can do. Current ebuilds are the one with the ".ebuild" extension. I'm not proposing any change to the way they are handled. Now, if you mean that there are some stuffs allowed in ".ebuild" files which would no more be allowed in the ".something" files, then yes: it introduces some restrictions on how the EAPI is declared. That's how it works. It has yet to be shown that this restrictions fordbids anything else than some pointless code (like setting EAPI depending on $PV), and furthermore that this code would, at the contrary, play well with the GLEP 55 approach (obviously not the case with the previous pointless example). > c) It's an extremely bizarre restriction, the likes of which do not > currently exist, that will confuse the hell out of all the people that > don't realise that such a restriction exists. Devs are already used to follow numerous conventions in the way they format their ebuilds. While this restriction is more than a convention, I assume that's how it will be followed by many people: just doing things the way they are in "skel.something". And for those who happen to break the rule because they edited a ".something" file without knowing what it was, they would learn as soon as they test/use their file (no need to wait for the repoman step, it would be checked whenever the ebuild is sourced). > d) It introduces a new prepass parse layer to an already complex > process. Both solutions add some new steps to this process, and it doesn't look to me like there's a significant difference beetween their respective added complexity. That said, you're the PM dev here, not me, so if you confirm that implementation of an in-contents solution is significantly harder, then i will accept the argument. > e) The Portage guys said no to it. When/where? I've only seen Marius commenting here, but not on that aspect. Also, i've read this 2005 "EBUILD_FORMAT" discussion that Steve Long has pointed [1], where Brian was against non-Bash parsing, but: - he was against changing files extension too, - the flaws in the EAPI system designed at this time is what led to rethinking it now. If i've missed something since then (and that's likely), could you give me a pointer to the archives? Thanks. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/29512 > You keep saying that like *.ebuild-3 and *.ebuild-4 are massively > different. They're not. They're the same extension, decorated slightly > differently. To me they look different enough that it's worth avoiding them if possible (especialy considering the decoration is not just an integer). I absolutly agree that it's a futile and subjective objection to GLEP 55, but so far, and until you answer to what i've left open above, it's the only aspect on which i can think one solution is better than the other. > > (until some unlikely conditions are met, like a switch away from > > Bash format). > > Or until we do something about eclasses and EAPIs, If you're not more specific about this "something", it's hard to say what solution will handle it best. For example, it could be nice that some ebuilds which are just instanciation of an eclass (like the vim-spell-* ones) let their eclass decide what EAPI it needs. That's something which could be handled nicely by a backward-compatible extension of the EAPI-in-contents approach: # Copyright... eapi inherited:vim-spell-2 VIM_SPELL_LANGUAGE="French" inherit vim-spell-2 (the "-2" here is not a specific EAPI, it's just that the "vim-spell" eclass already exists and that it would not be a good idea to apply the needed changes to it) PMs which know how to handle such redirection would then go look for an EAPI declared in the eclass before sourcing the whole thing. PMs which don't yet would see it as an unsupported EAPI and stop there. My point here is that the in-contents alternative is just a syntaxic rule which defines a first-pass extraction of a value from an ebuild file (as opposed to an ebuild file name extension). How it is then used (what the "eapi" function does, if anything, or whether this value is the definitive EAPI, or how EAPI vs. eclasses is handled, etc.) can be subject to future changes depending on this value. That's part of why this solution is not more restrictive than the file name extension approach. > or until we do something about storing metadata outside of the ebuilds > themselves... # Copyright... eapi from-external-metadatas ... I agree there's an unecessary performance impact on doing that though, so you're right that it's a case where changing the file extension would be better. The EAPI decla
[gentoo-dev] New developer : Richard Freeman (rich0)
After a long and bumpy ride, concluded by a very BOFH-esque "LDAP replication failure, we're on it" (thanks Robin, by the way), it's my pleasure to announce that Richard Freeman (rich0) is a new Gentoo developer. Richard has been an amd64 AT for some time already, and so will join the amd64 team. His most notable prowess as an ebuild developer is to be trying to sort out the mess that Eternal Lands is. Richard is married and has two children. For a living he works at a pharma where he manages moderately large projects from a business perspective. He says he mainly focuses on requirements, design, interface, training, procedures, validation/testing/QA/reg compliance, etc... I would like to thank Markus Ullmann (jokey) for taking over the mentoring of Richard after his original mentor left us. So please everybody, give a warm welcome to Richard. Denis. -- [EMAIL PROTECTED] mailing list
