Re: [gentoo-dev] Packages up for grabs
On Tue, 25 Dec 2007 20:19:41 +0200 Christian Heim wrote: - dev-util/scanmem I'll take this one if there are no objections. Thanks, Aggelos -- Aggelos Orfanakos, http://agorf.gr/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Packages up for grabs
On Dec 26, 2007 1:19 AM, Christian Heim [EMAIL PROTECTED] wrote: - app-text/antiword I can take this to complete my anti-office collection. -- Duy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote: On 12/25/07, Roy Marples [EMAIL PROTECTED] wrote: Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI 1 environment, or what? If it's that such a big deal, then simply ensure that Thankyou for reading and understanding the GLEP before jumping in and commenting. I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Roy Marples wrote: I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Do you count version as metadata? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Roy Marples wrote: On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote: On 12/25/07, Roy Marples [EMAIL PROTECTED] wrote: Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI 1 environment, or what? If it's that such a big deal, then simply ensure that Thankyou for reading and understanding the GLEP before jumping in and commenting. I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Thanks Roy Roy++ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 16:39 +0100, Jan Kundrát wrote: Roy Marples wrote: I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Do you count version as metadata? No. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Jan Kundrát a écrit :
Roy Marples wrote:
I understand that metadata in a file name is pure and simple hackery
that has no place here and the GLEP is a flimsy attempt to justify it.
Do you count version as metadata?
I'll bite :)
Version numbers aren't metadata because they uniquely identify the
ebuild/package.
EAPI on the other hand brings no such information to identify the
package. Furthermore, the GLEP proposes that no 2 ebuilds with the exact
same version may exist regardless of different EAPIs.
In the end, ${CATEGORY}/${PF} is like the key in a RDB table. The EAPI
is just extra info.
I'll just wrap this up by saying that I don't have an opinion on whether
putting the EAPI inside the ebuild or outside is better for the complex
operations involved in portage. I'll leave that to the more informed devs :)
Cheers,
Rémi
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 16:32 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 15:04:52 + Roy Marples [EMAIL PROTECTED] wrote: I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Alright, so where would you stick EAPI such that all the requirements that've previously been described are met? I neither know, nor care. I just feel very strongly that the current proposal is wrong, and no requirements that you or others may have can possibly outweigh that. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 27 Dec 2007 15:04:52 + Roy Marples [EMAIL PROTECTED] wrote: I understand that metadata in a file name is pure and simple hackery that has no place here and the GLEP is a flimsy attempt to justify it. Alright, so where would you stick EAPI such that all the requirements that've previously been described are met? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 16:50 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 16:45:06 + Roy Marples [EMAIL PROTECTED] wrote: Alright, so where would you stick EAPI such that all the requirements that've previously been described are met? I neither know, nor care. I just feel very strongly that the current proposal is wrong, and no requirements that you or others may have can possibly outweigh that. So you have no technical objections, no alternatives, no understanding of why it's necessary and no actual reason to call it 'wrong'. Hard to have technical objections to the contents of a string :) Actual reasons were stated in the first email I posted in this thread to which to replied. I care not for alternatives, nor understanding as it's not my domain of expertise or knowledge. But I can smell a blatant hack that is just wrong to the bone like a lot of other people here. Just because you have a the only solution to a problem does not make it right by default. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 27 Dec 2007 16:45:06 + Roy Marples [EMAIL PROTECTED] wrote: Alright, so where would you stick EAPI such that all the requirements that've previously been described are met? I neither know, nor care. I just feel very strongly that the current proposal is wrong, and no requirements that you or others may have can possibly outweigh that. So you have no technical objections, no alternatives, no understanding of why it's necessary and no actual reason to call it 'wrong'. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 27 Dec 2007 17:27:05 + Roy Marples [EMAIL PROTECTED] wrote: But I can smell a blatant hack that is just wrong to the bone like a lot of other people here. Clearly not... As you say, you don't care to understand any of this. You're just jumping in because you think you know what a file extension is and are thus qualified to comment. Unfortunately, the file extension is largely irrelevant -- it's merely the end result, and it's everything that leads up to that that's the important part. Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 18:11 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. If there are no other colours then maybe you shouldn't install extensions that only work with pink to the detriment of all other colours of the spectrum. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 18:11 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. Any chance we can back on, you know, the actual topic, rather than these useless analogies? Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 08:10:13 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 17:22:22 +0100 Luca Barbato [EMAIL PROTECTED] wrote: I'm thinking about having them embedded in the comment as first line as something like #!/usr/bin/env emerge --eapi $foo Unfortunately the emerge --eapi $foo part would be passed as a single argument to /usr/bin/env, therefore can't work. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 09:55:06 + Ciaran McCreesh [EMAIL PROTECTED] wrote: Stuck ranges into metadata.xml for which EAPIs applied? No package manager required information can be in XML format. Says who? Us. We can change that, if we decide it's the best answer. =) Say the Portage people for the past lots of years. I assume you're referring to some statements I and maybe Nick made several years ago, I don't think Brian, Jason or Zac ever really thought about it. I can only speak for myself, but those past statements were mostly due to experiences made with glsa-check and issues in the python/pyxml relationship (in 2003), things may have changed since then so those statements could be re-evaluated. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Fri, 21 Dec 2007 00:58:39 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007 19:57:12 +0100 Markus Meier [EMAIL PROTECTED] wrote: server12 See previous discussions on why this can't be global (essentially, it has different meanings for everything). Those dicussions usually ended with lets wait for use-deps. And the general meaning of it is enable the server part of the package, just that the impact of server part varies greatly between packages and isn't always intuitive. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 27 Dec 2007 21:28:41 +0100 Michael Haubenwallner [EMAIL PROTECTED] wrote: This also could be done as (using 'ebuild' instead of 'emerge') #! /usr/bin/env ebuild.1 and PM could provide some 'ebuild.1' executable, at the bare mimimum doing nothing but #! /bin/sh exec ebuild --eapi 1 $@ But *why*? We've finally almost gotten people away from installing things using ebuild. Why on earth would we want to bring it back? The correct way to install a package is through the nice, friendly, mask checking, dependency resolving package manager frontend. There is no correct action that can be taken when an ebuild is executed on its own, so ebuilds shouldn't be executable on their own. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Marius Mauch wrote: On Thu, 20 Dec 2007 08:10:13 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 2007-12-27 at 20:48 +0100, Marius Mauch wrote: On Thu, 20 Dec 2007 17:22:22 +0100 Luca Barbato [EMAIL PROTECTED] wrote: I'm thinking about having them embedded in the comment as first line as something like #!/usr/bin/env emerge --eapi $foo Unfortunately the emerge --eapi $foo part would be passed as a single argument to /usr/bin/env, therefore can't work. This also could be done as (using 'ebuild' instead of 'emerge') #! /usr/bin/env ebuild.1 and PM could provide some 'ebuild.1' executable, at the bare mimimum doing nothing but #! /bin/sh exec ebuild --eapi 1 $@ /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: Marius Mauch wrote: On Thu, 20 Dec 2007 08:10:13 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? lu Logical and proper to me. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New developer : Richard Freeman (rich0)
Denis Dupeyron wrote: 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. Yay. Please report to the basement for hazing at 0600. -- looks like christmas at fifty-five degrees this latitude weakens my knees EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass
Excerpts from René 'Necoro' Neumann's message of Fri Nov 09 00:28:47 +0100 2007:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Long schrieb:
René 'Necoro' Neumann wrote:
cmake-utils_src_enable python = -DENABLE_python=...
Wanted would be that it returned -DENABLE_PYTHON=...
I'm not into bash scripting that much, so I do not know a way to do so -
but I guess someone else is ;)
Unfortunately BASH doesn't support ksh93 or zsh style casting to uppercase.
The best way really is via tr:
alias toUpper='tr [[:lower:]] [[:upper:]]'
alias toLower='tr [[:upper:]] [[:lower:]]'
(er aliases don't normally work in scripts, but you get the idea.) Bear in
mind that tr reads stdin and writes to stdout. It has the advantage of
being locale-safe. Every other method I've looked at is much slower and
only works with ASCII.
A function wouldn't be too hard:
toUpper() {
for i; do
echo $i |tr [[:lower:]] [[:upper:]]
done
}
Usage depends on the parameters you pass.
var=$(toUpper $var) # for single vars with no newlines in
This is right the version I've chosen ... so with the help of Steve: a
small patch ;)
Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFHM5uv4UOg/zhYFuARAuELAJjnlDCFDMm3e2mJqYuyT4nkFoaaAJ4go9qp
Qca9r8Y7LpD0YSSylUh2BQ==
=517n
-END PGP SIGNATURE-
Hi Necoro,
It looks like you want to use
'cmake-utils_use_enable python PYTHON'
It's mentioned in the cmake-utils.eclass manpage (app-portage/eclass-manpages),
as well as in the patch you just sent: cmake-utils_use_enable USE flag [flag
name]
:-)
Regards,
Ingmar Vanhassel
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [RFC] Some new global USE-flags
No on logrotate per several previous conversations. The majority of the ones listed are not globally relevent which is the first criteria for creating a new global use flag. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Eclasses (Was: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2])
Ciaran McCreesh wrote: On Mon, 24 Dec 2007 10:52:53 + Steve Long [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: 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. Yeah, so forwards into the future where it's impossible to maintain this format (er..) there'll be another type of ebuild for your purported long-term solution. Hopefully that'll be EAPI 2, and hopefully we're talking months rather than years. Whatever. EAPI=2 works fine with current software. Could you tell me why you're so hot on export'ing EAPI? I thought it was only relevant, environment-wise, to the ebuild and subshells. What is the use case for exporting it externally? * Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor across EAPIs removing features, nor EAPIs changing eclasses. I don't see what's wrong with EAPI (if set, otherwise implicitly whatever the ebuild sets, or 0 if not set there) only applying to the file it's declared in. Since we can't remove eclasses, it would be useful to continue allowing them to examine the EAPI variable for future compatibility. I'm sure there are other restrictions imposed by this enhancement which make maintenance more difficult for no benefit to the maintainer. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote:
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.
I don't think it's that hard to understand You can only set EAPI *once* in
your ebuild. Are you really saying devs won't get that?
Who are these mythical people? Devs take a quiz: the EAPI setting
restrictions can easily be added to it, as well as being documented
elsewhere.
That would of course have to be done doubly so for your GLEP, which imposes
a much more bizarre restriction: that the EAPI must go in the filename.
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).
Odd: I found repoman very fussy about those. Leaving the digs at portage
aside, that's what the new commit reviews are about.
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
Wow, yet another contrived b0rkage. You really don't have a very high
opinion of Gentoo devs, do you?
EAPI=1
export EAPI=2
src_compile() {
cat END somefile
EAPI=3
END
}
All those would be dealt with by the well-defined syntax. I'd start with:
EAPI=foo on its own on a line. The first setting is taken.
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...
Somehow I'm not reading Brian and I agreed that.. and it concerns me that
we haven't so far had portage and pkgcore devs chiming in that your GLEP is
just what they want as the solution to several issues, meriting the work
required to change over, and the future hackiness and restrictions it
imposes.
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 sounds like a borked package manager, and something which should not be
allowed per the spec. If an ebuild author sets EAPI that's what the
metadata EAPI must reflect.
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.
Or you're just contriving examples.
(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.
It's up to the eclass/ebuild author to deal with the consequences of code
they write. In the same light, it's up to the PM devs to ensure that the
EAPIs they support work correctly.
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.)
If you could come up with a more cogent example (that actually poses a
technical challenge) perhaps your peers
[gentoo-dev] Re: [RFC] Some new global USE-flags
Chris Gianelloni wrote: branding: Enable Gentoo specific branding [questionable, as used for splashes/shortcuts/artwork] Well, my personal opinion here is that we should enable this by default on *at least* the desktop profiles, as providing sensible defaults and branding isn't outside the scope of the project. We still stay as close to upstream as possible with this stuff and only use it for branding or optional Gentoo-specific minor config changes. Also, it can still be disabled for people who want everything as upstream intended. I have no objection to it being flagged on by default in desktop profiles, but Gentoo-specific minor config changes concerns me, since I take it as given that installing for a specific distro implies config changes to work with that distro, and not having those because I have turned branding off sounds bad for me as a user and seems a confusion of purpose. (It could lead to more optional config changes bundled in future which wouldn't be apparent without knowledge of the ebuild.) -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 27, 2007 11:40 PM, Doug Klima [EMAIL PROTECTED] wrote: [... EAPI is stuff PM supports/exports to the ebuild ...] Logical and proper to me. Actually, when I'm asked what EAPI is, I just say EAPI is a standard definition for the ebuild structure, implying supporting features from the package manager. Most of the time, the user is happy with the answer ;-) Wkr, Sven Vermeulen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Eclasses (Was: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2])
On Fri, 28 Dec 2007 05:21:06 + Steve Long [EMAIL PROTECTED] wrote: I don't see what's wrong with EAPI (if set, otherwise implicitly whatever the ebuild sets, or 0 if not set there) only applying to the file it's declared in. Because that doesn't work at all, see http://article.gmane.org/gmane.linux.gentoo.devel/53354 Marius -- [EMAIL PROTECTED] mailing list
