[gentoo-dev] Re: GLEP 55

2008-06-10 Thread Tiziano Müller
Joe Peterson wrote:

 Ciaran McCreesh wrote:
 And a file extension is far less obscurely complex than enforcing
 arbitrary syntax restrictions upon ebuilds.
 
 I disagree.  One is exposed to devs only as ebuild syntax; the other is
 exposed in an inappropriate location to everyone looking at the portage
 tree.
 
 No it can't. EAPI has to be known before the source can start. Bash
 doesn't provide traps for executing code upon changed variables.
 
 Doing it out-of-band solve this.
 
 No, it's only needed once per non-trivial change. So we might as well
 just change it for every EAPI.
 
 Huh?  If the new portage knows how to determine the EAPI definitively
 (and that would be defined), it can deal with the differences.
 
 And then how do we deal with EAPI 3, where the syntax changes again?
 
 Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
 from there.  If you change the way you declare EAPI each time, yeah,
 that's a problem, but I'm not sure why that would ne necessary.
No, that is not the problem.

Example:
In EAPI 42 we define that the package manager must provide a global function
extract_depend_from_setup_py() such that it is callable at a global level
in an ebuild like this

*snip start*

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=42

DESCRIPTION=A library aiming to support agile and test-driven python
development on various levels.
SRC_URI=http://codespeak.net/download/${PN}/${P}.tar.gz;
HOMEPAGE=http://codespeak.net/py/;
KEYWORDS=~amd64 ~x86
SLOT=0
LICENSE=MIT
IUSE=

extract_depend_from_setup_py

*snip end*

Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
tries to source the above ebuild to determine the EAPI version (as it is
being currently done as far as I understood it) because
extract_depend_from_setup_py is undefined.
So it won't even be able to read out the EAPI.

With the EAPI in the filename tools now knowing EAPI-42 will either ignore
the above foo-1.0.ebuild-42 or mask it because they may identify the
EAPI-version without sourcing the ebuild.

And: No, just sourcing the ebuild and simply masking it because we can't
source it is a no-go (since you're abusing error-handling as a case
switch).


-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: GLEP 55

2008-06-10 Thread Tiziano Müller
Ciaran McCreesh wrote:

 On Mon, 9 Jun 2008 22:35:25 -0700
 Donnie Berkholz [EMAIL PROTECTED] wrote:
 Did anyone already propose specifying this in metadata.xml?
 
 Yup. That's a no-go, since metadata.xml is quite rightly treated as
 being not suitable for anything the package manager really needs.
 
 It also moves the EAPI definition even further away from the ebuild,
 which makes it even harder to work with.
 
 And, of course, it's not backwards compatible, so it'd still need a
 file extension change.
 

Another ugly solution: Having the EAPI on a per-package (like
$portagedir/cat/package-1) or per-tree basis ($portagedir/profiles/eapi)
and start providing our tree as overlays of more than one tree
(will end up in a mess of dependencies, but it would still be nice to
specify the EAPI for a complete overlay instead of having the name all the
ebuilds like .eapi-X :-).
In addition: it wouldn't be possible to identify the EAPI of an ebuild by
just looking at it...


-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 10:33:34 +0200
Tiziano Müller [EMAIL PROTECTED] wrote:
 Another ugly solution: Having the EAPI on a per-package (like
 $portagedir/cat/package-1) or per-tree basis
 ($portagedir/profiles/eapi) and start providing our tree as overlays
 of more than one tree (will end up in a mess of dependencies, but it
 would still be nice to specify the EAPI for a complete overlay
 instead of having the name all the ebuilds like .eapi-X :-).
 In addition: it wouldn't be possible to identify the EAPI of an
 ebuild by just looking at it...

Kills the upgrade path completely. No good.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Luca Barbato

Tiziano Müller wrote:

Another ugly solution: Having the EAPI on a per-package (like
$portagedir/cat/package-1) or per-tree basis ($portagedir/profiles/eapi)


I like the per tree basis and I already asked about that (since makes 
things clearer and older portage can be tricked by rsync.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Luca Barbato

Ciaran McCreesh wrote:

Kills the upgrade path completely. No good.


Not really, you change the rsync paths and older portage will pick a 
repo that just has the necessary to upgrade to the next portage.


This kind of things would work better using an scm supporting branches 
and tags a bit better.


lu


--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: A few questions to our nominees

2008-06-10 Thread Tiziano Müller
Peter Weller wrote:

 On Sun, 2008-06-08 at 13:41 +0100, Alex Howells wrote:
 [snip]
 I often don't agree with him, but can't help but respect the work he
 does.
 
 I would like to see Council move towards a more compressed meeting
 format -- people presenting arguments need to work out their stuff
 before bringing it up in the meeting, and to allow for quick
 turn-around of decisions I'd suggest fortnightly meetings which are
 time-limited to 60 minutes each.  A prioritized schedule determines
 which order we deal with issues in and anything not getting attention
 is bumped 2 weeks, with the priority adjusted if necessary to ensure
 it gets attention then.
 
 Each issue should be limited to between 5-20 minutes. If people can't
 get through the politics and debate in the allotted time then it
 should either get bumped 2 weeks and given another 5-20 minutes, or we
 should table a special meeting to allow a full 60-90 minutes *just* to
 decide that one issue and nothing else.
 
 Sitting around in #gentoo-council for 3-4 hours every month isn't
 conducive to progress, it's going to make people get tired/bored and
 not pay proper attention and/or not bother to turn up, which just
 leads to elections. Endless cycle?
 
 ++ From me on this one. If I were elected to the Council, I would do my
 best to get this happening.

++ from me too. Along the lines to what I wrote in gentoo.project.



-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: threads vs. smp

2008-06-10 Thread Christian Faulhammer
Hi,

Hanno Böck [EMAIL PROTECTED]:
 This is a recent list of ebuilds using the local flag smp
 
 dev-lang/erlang/erlang-12.2.2.ebuild

 It is called SMP support in Erlang, and users will expect exactly that
tied to a smp USE flag.

V-Li


-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://www.faulhammer.org/


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 11:40:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
 Ciaran McCreesh wrote:
  Kills the upgrade path completely. No good.
 
 Not really, you change the rsync paths and older portage will pick a 
 repo that just has the necessary to upgrade to the next portage.
 
 This kind of things would work better using an scm supporting
 branches and tags a bit better.

picard_facepalm.jpg

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Rémi Cardona

Ciaran McCreesh a écrit :

Kills the upgrade path completely. No good.


Lemme sum this up in layman's terms :

1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
avoid that for various reasons, all 100% valid.


2) Putting the EAPI in the filename :

 + it solves 1)
 + it keeps backward compatibility because old PM won't recognize the 
filenames

 - it's not very pretty

3) Putting the EAPI in metadata.xml or in another external file

 + it solves 1)
 + it keeps pretty file names
 - it breaks backwards compatibility
 - (specific to metadata.xml) PM will have to learn to read XML (yuck)

That's about it, right?


--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Luca Barbato

Tiziano Müller wrote:

Joe Peterson wrote:


Ciaran McCreesh wrote:

And a file extension is far less obscurely complex than enforcing
arbitrary syntax restrictions upon ebuilds.

I disagree.  One is exposed to devs only as ebuild syntax; the other is
exposed in an inappropriate location to everyone looking at the portage
tree.


No it can't. EAPI has to be known before the source can start. Bash
doesn't provide traps for executing code upon changed variables.

Doing it out-of-band solve this.


No, it's only needed once per non-trivial change. So we might as well
just change it for every EAPI.

Huh?  If the new portage knows how to determine the EAPI definitively
(and that would be defined), it can deal with the differences.


And then how do we deal with EAPI 3, where the syntax changes again?

Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
from there.  If you change the way you declare EAPI each time, yeah,
that's a problem, but I'm not sure why that would ne necessary.

No, that is not the problem.

Example:
In EAPI 42 we define that the package manager must provide a global function
extract_depend_from_setup_py() such that it is callable at a global level
in an ebuild like this

*snip start*

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=42

DESCRIPTION=A library aiming to support agile and test-driven python
development on various levels.
SRC_URI=http://codespeak.net/download/${PN}/${P}.tar.gz;
HOMEPAGE=http://codespeak.net/py/;
KEYWORDS=~amd64 ~x86
SLOT=0
LICENSE=MIT
IUSE=

extract_depend_from_setup_py

*snip end*

Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
tries to source the above ebuild to determine the EAPI version (as it is
being currently done as far as I understood it) because
extract_depend_from_setup_py is undefined.
So it won't even be able to read out the EAPI.

With the EAPI in the filename tools now knowing EAPI-42 will either ignore
the above foo-1.0.ebuild-42 or mask it because they may identify the
EAPI-version without sourcing the ebuild.



Check if exists a line EAPI=*$, if does and the rest of the string 
matches an understood eapi, go on sourcing, otherwise ignore/mask it...


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Tiziano Müller
Luca Barbato wrote:

 Tiziano Müller wrote:
 Joe Peterson wrote:
 
 Ciaran McCreesh wrote:
 And a file extension is far less obscurely complex than enforcing
 arbitrary syntax restrictions upon ebuilds.
 I disagree.  One is exposed to devs only as ebuild syntax; the other is
 exposed in an inappropriate location to everyone looking at the portage
 tree.

 No it can't. EAPI has to be known before the source can start. Bash
 doesn't provide traps for executing code upon changed variables.
 Doing it out-of-band solve this.

 No, it's only needed once per non-trivial change. So we might as well
 just change it for every EAPI.
 Huh?  If the new portage knows how to determine the EAPI definitively
 (and that would be defined), it can deal with the differences.

 And then how do we deal with EAPI 3, where the syntax changes again?
 Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
 from there.  If you change the way you declare EAPI each time, yeah,
 that's a problem, but I'm not sure why that would ne necessary.
 No, that is not the problem.
 
 Example:
 In EAPI 42 we define that the package manager must provide a global
 function extract_depend_from_setup_py() such that it is callable at a
 global level in an ebuild like this
 
 *snip start*
 
 # Copyright 1999-2007 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: $
 
 EAPI=42
 
 DESCRIPTION=A library aiming to support agile and test-driven python
 development on various levels.
 SRC_URI=http://codespeak.net/download/${PN}/${P}.tar.gz;
 HOMEPAGE=http://codespeak.net/py/;
 KEYWORDS=~amd64 ~x86
 SLOT=0
 LICENSE=MIT
 IUSE=
 
 extract_depend_from_setup_py
 
 *snip end*
 
 Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
 tries to source the above ebuild to determine the EAPI version (as it is
 being currently done as far as I understood it) because
 extract_depend_from_setup_py is undefined.
 So it won't even be able to read out the EAPI.
 
 With the EAPI in the filename tools now knowing EAPI-42 will either
 ignore the above foo-1.0.ebuild-42 or mask it because they may identify
 the EAPI-version without sourcing the ebuild.
 
 
 Check if exists a line EAPI=*$, if does and the rest of the string
 matches an understood eapi, go on sourcing, otherwise ignore/mask it...

... and package managers which don't do that already still fail.


-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Piotr Jaroszyński
 The simplest way is to change the syncpoint in the new package manager and
 leave the previous uri with a compatibility repo for the older ones.

So we add a new repo each time a new EAPI comes out? Sounds like a big mess.

-- 
Best Regards,
Piotr Jaroszyński
���^�X�����(��j)b�b�

Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Fernando J. Pereda


On 10 Jun 2008, at 12:30, Rémi Cardona wrote:


Ciaran McCreesh a écrit :

picard_facepalm.jpg


I don't think any of us are completely thrilled by either proposals,  
but the EAPI-in-a-separate-file does have the potential for more  
flexibility, ie package-wide EAPI.


And it does keep filenames simple enough.


And it is not backwards compatible.

- ferdy--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Luca Barbato

Tiziano Müller wrote:

... and package managers which don't do that already still fail.


To put everything in perspective all this discussion is done in order to 
workaround the issue of an old and outdated package manager that cannot 
be upgraded once it syncs from a too new repository.


The simplest way is to change the syncpoint in the new package manager 
and leave the previous uri with a compatibility repo for the older ones.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask

2008-06-10 Thread Peter Volkov
Hello Luis.

В Пнд, 09/06/2008 в 18:12 +, Luis F. Araujo (araujo) пишет:
 araujo  08/06/09 18:12:09
 
   Modified: package.mask
   Log:
   Saving Squeak. Solving bugs #163724 , #196984
 
 Revision  ChangesPath
 1.8705   profiles/package.mask


Whenever you modify anything in profiles directory, please, fill in
ChangeLog. ChangeLogs became useless if only part of developers fill
them. 

Just to remind. There are per-arch ChangeLog, base profile ChangeLog,
features ChangeLog and for other stuff ChangeLog:

/usr/portage/profiles/base/ChangeLog
/usr/portage/profiles/arch/sh/ChangeLog
[snip other archs ChangeLog]
/usr/portage/profiles/default-bsd/ChangeLog
/usr/portage/profiles/embedded/ChangeLog
/usr/portage/profiles/default-linux/arm/ChangeLog
[snip other archs ChangeLog]
/usr/portage/profiles/hardened/x86/ChangeLog
/usr/portage/profiles/features/ChangeLog
/usr/portage/profiles/ChangeLog

Thus whenever you change anything in arch profile, or in base or
features subdirectory use relevant ChangeLog. For other changes like
local USE flags, masking/unmasking/updating masks (not comments :))
use /usr/portage/profiles/ChangeLog.

Thank you,
-- 
Peter.

-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 12:22:03 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
 Tiziano Müller wrote:
  ... and package managers which don't do that already still fail.
 
 To put everything in perspective all this discussion is done in order
 to workaround the issue of an old and outdated package manager that
 cannot be upgraded once it syncs from a too new repository.
 
 The simplest way is to change the syncpoint in the new package
 manager and leave the previous uri with a compatibility repo for the
 older ones.

So you're volunteering to convert the entire tree to the new EAPI all
in one go every two months?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] GLEP 55

2008-06-10 Thread Richard Freeman

Ciaran McCreesh wrote:

On Mon, 09 Jun 2008 22:09:04 -0600
Joe Peterson [EMAIL PROTECTED] wrote:

Debunked according to whom?  I believe that some, including you,
believe you debunked them, but I do not believe there was wholesale
agreement from the dev community.


That doesn't really matter. Most of the dev community don't care to
understand the underlying issue, so all they need to do is go along
with the informed decision that the Council was supposed to have made
on their behalf.



By that logic (that mere ordinary devs need to be guided by their more 
informed elected leaders), we're doing EXACTLY what you propose.  The 
informed decision by the Council was to defer the GLEP.  As a result the 
lesser devs are going along with that decision and not implementing it.


The fact is that most devs probably do care to understand the underlying 
issues.  Many just happen to disagree with you.


I still haven't seen a good argument as to why the EAPI can't be handled 
as something like a magic number.  Maybe make the first line in the ebuild:

#EAPI=foo

ELF vs A.OUT don't use extensions to identify its files - the original 
file format was designed to allow file identification from the contents.


The only issue I can see with putting the EAPI on the first line is with 
legacy package managers.  That could be fixed in a number of ways.  The 
simplest would be just allowing it to break and sending out the fix well 
in advance of any breakage on GMN.  Considering the fiasco that we've 
had with some GCC/GLIBC upgrades and similar stuff in the past this 
would be pretty minor.  A less pretty solution might be a one-time file 
extension change.


There wouldn't be any need to repeat all of this every time the EAPI 
changes - at that point we've standardized the location of the EAPI 
within the file.

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Luca Barbato

Piotr Jaroszyński wrote:

The simplest way is to change the syncpoint in the new package manager and
leave the previous uri with a compatibility repo for the older ones.


So we add a new repo each time a new EAPI comes out? Sounds like a big mess.


It isn't you just keep 2 repos, one with the minimal eapi and the 
minimal set of ebuilds needed to upgrade, one with the latest and greatest.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 13:13:34 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
 Ciaran McCreesh wrote:
  So you're volunteering to convert the entire tree to the new EAPI
  all in one go every two months?
 
 I don't see the need and I won't see the problem given right now what
 is interesting is the set of improvements that aren't forward
 incompatible.

It's likely that any future EAPIs won't be forward compatible because:

* There's a strong desire to make lots of functions stricter.
* The current *DEPEND syntax will probably be replaced with something
more expressive.
* There'll be more phases.

So yes, it's a full tree rewrite if you want to avoid having multiple
EAPIs in the same tree.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Fernando J. Pereda


On 10 Jun 2008, at 13:13, Luca Barbato wrote:
but I dislike empty theories or hardly searched corner cases that  
could be avoided with half of the effort necessary to get there.


Yoy mean like adopting GLEP55, right?

- ferdy

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Luca Barbato

Ciaran McCreesh wrote:

So you're volunteering to convert the entire tree to the new EAPI all
in one go every two months?


I don't see the need and I won't see the problem given right now what is 
interesting is the set of improvements that aren't forward incompatible.


Being that the case you'd just need 2 trees, managed as overlay and a 
marker for each tree on which eapi to use, but I dislike empty theories 
or hardly searched corner cases that could be avoided with half of the 
effort necessary to get there.



lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55

2008-06-10 Thread Jan Kundrát
Joe Peterson wrote:
 But what users *really* don't care about is EAPIs, and this GLEP would
 expose that technical detail to them in a very blatent way.
 Anyone who cares about ebuilds at a file level has to care about EAPIs.
 
 Not really.  A typical user does not need to know about EAPIs at all,
 but he might want to peruse the portage tree to look for ebuilds.  He
 might also want to grep for KEYWORDS or whatever.

If the user knows that keywords are set by the KEYWORDS variable, then
she must be familiar with the EAPI. The meaning of the KEYWORDS variable
is defined by the EAPI.

 Along those lines, as I've said before, migrating to a new extension,
 *one-time*, as a solution to this, although not optimal, would be far
 more satisfactory than introducing a series of ever-changing
 extensions.
 No it won't. It means future EAPIs will be restricted to some
 particular source format.
 
 I assume you mean that EAPI needs to be in the file - again, is this
 bad?  Many file formats specify a file format version as part of the file.

Sure. If current EAPI specified that a sequence of four bytes starting
at offset  0x10 is a little-endian magic number that is used to identify
an EAPI, that'd be all we want. However, current format definition is
rather complex; there's nothing as simple as read several bytes at some
offset and use them.

Cheers,
-jkt
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55

2008-06-10 Thread Joe Peterson
Ciaran McCreesh wrote:
 On Mon, 9 Jun 2008 22:35:25 -0700
 Donnie Berkholz [EMAIL PROTECTED] wrote:
 Did anyone already propose specifying this in metadata.xml?
 
 Yup. That's a no-go, since metadata.xml is quite rightly treated as
 being not suitable for anything the package manager really needs.

I think a separate file, especially one that uses a standard XML format,
would be a fine place for things that the PM needs.  Just because we do
not use it this way now does not mean it is not a good idea.  Also, the
EAPI would be out-of-band and not require sourcing of the bash script to
determine.

 It also moves the EAPI definition even further away from the ebuild,
 which makes it even harder to work with.

Harder to work with in what way?

 And, of course, it's not backwards compatible, so it'd still need a
 file extension change.

I am not convinced of this.  As others have stated, portage/PM should be
upgraded with the new capability well in advance of new EAPIs.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Rémi Cardona wrote:
 Ciaran McCreesh a écrit :
 picard_facepalm.jpg
 
 I don't think any of us are completely thrilled by either proposals, but 
 the EAPI-in-a-separate-file does have the potential for more 
 flexibility, ie package-wide EAPI.
 
 And it does keep filenames simple enough.

+1

-Joe


-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Luca Barbato wrote:
 Check if exists a line EAPI=*$, if does and the rest of the string 
 matches an understood eapi, go on sourcing, otherwise ignore/mask it...

And placing it out-of-band (like # EAPI=...) avoids any sourcing
errors, makes parsing faster, etc.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 07:31:09 -0600
Joe Peterson [EMAIL PROTECTED] wrote:
 I think a separate file, especially one that uses a standard XML
 format, would be a fine place for things that the PM needs.

XML is a pain in the ass.

 Just because we do not use it this way now does not mean it is not a
 good idea.  Also, the EAPI would be out-of-band and not require
 sourcing of the bash script to determine.

The file extension is out-of-band and yet still coupled to the
individual ebuilds in an obvious way.

  It also moves the EAPI definition even further away from the ebuild,
  which makes it even harder to work with.
 
 Harder to work with in what way?

It decouples the EAPI and the thing written in that EAPI.

  And, of course, it's not backwards compatible, so it'd still need a
  file extension change.
 
 I am not convinced of this.  As others have stated, portage/PM should
 be upgraded with the new capability well in advance of new EAPIs.

But that's exactly what EAPIs are there to solve. Having to wait two
years (or however long Gentoo goes between releases these days) just to
use simple new features slows down progress even more.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] GLEP 55

2008-06-10 Thread Joe Peterson
Jan Kundrát wrote:
 If the user knows that keywords are set by the KEYWORDS variable, then
 she must be familiar with the EAPI. The meaning of the KEYWORDS variable
 is defined by the EAPI.

But that's not really what I find objectionable.  There's no need to
make EAPI so special that it alters the file extension.  If EAPI is
accessible as part of the file or in metadata.xml, e.g., it still serves
this purpose well, and that info is exposed at the right level.

 Sure. If current EAPI specified that a sequence of four bytes starting
 at offset  0x10 is a little-endian magic number that is used to identify
 an EAPI, that'd be all we want. However, current format definition is
 rather complex; there's nothing as simple as read several bytes at some
 offset and use them.

I would not suggest byte-level methods, no - these files are not binary.
 There are simple ways to parse text files to find the EAPI.  If it is
in the ebuild, putting it in the header (out-of-band) works.  If it is
in metadata, simply parsing XML works.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Fernando J. Pereda


On 10 Jun 2008, at 15:33, Joe Peterson wrote:


Luca Barbato wrote:

Check if exists a line EAPI=*$, if does and the rest of the string
matches an understood eapi, go on sourcing, otherwise ignore/mask  
it...


And placing it out-of-band (like # EAPI=...) avoids any sourcing
errors, makes parsing faster, etc.


No, it doesn't make parsing faster. Had you bothered to profile any  
package manager you'd know that.


- ferdy


--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Rémi Cardona wrote:
 Ciaran McCreesh a écrit :
 Kills the upgrade path completely. No good.
 
 Lemme sum this up in layman's terms :
 
 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
 avoid that for various reasons, all 100% valid.
 
 2) Putting the EAPI in the filename :
 
   + it solves 1)
   + it keeps backward compatibility because old PM won't recognize the 
 filenames
   - it's not very pretty

I'd say the problems go way beyond just being not pretty.  That longish
email I wrote yesterday has a bunch of reasons I don't like it.  And
pretty makes the issue sound unimportant or superficial.

 3) Putting the EAPI in metadata.xml or in another external file
 
   + it solves 1)
   + it keeps pretty file names
   - it breaks backwards compatibility
   - (specific to metadata.xml) PM will have to learn to read XML (yuck)
 
 That's about it, right?

Good summary, except I think we can find ways to deal with compatibility
(several ideas have been put forth already: giving time for PM to be
upgraded, or a one-time tree or extension bump - and I'm sure there are
even better ones yet to be discussed).  I do not believe that the
filename mangling solution is the one and only way as some people are
insisting.

Also, I'm not sure reading XML is a problem at all - python has good
libs for this already.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Luca Barbato

Fernando J. Pereda wrote:


No, it doesn't make parsing faster. Had you bothered to profile any 
package manager you'd know that.


Do you have any number to share?

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Fernando J. Pereda wrote:
 On 10 Jun 2008, at 15:33, Joe Peterson wrote:
 
 Luca Barbato wrote:
 Check if exists a line EAPI=*$, if does and the rest of the string
 matches an understood eapi, go on sourcing, otherwise ignore/mask  
 it...
 And placing it out-of-band (like # EAPI=...) avoids any sourcing
 errors, makes parsing faster, etc.
 
 No, it doesn't make parsing faster. Had you bothered to profile any  
 package manager you'd know that.

No, I have not profiled PMs to try this, but you are saying that reading
the first few lines of a file is not faster than sourcing the whole
thing with bash?  Remember that it could abort the minute it sees a non
'#' or blank line, which would be after the first few.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Fernando J. Pereda


On 10 Jun 2008, at 15:46, Joe Peterson wrote:

Also, I'm not sure reading XML is a problem at all - python has good
libs for this already.


Reading XML files is easy, but it makes certain codepaths much much  
slower. Not a good 'feature'.


- ferdy

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Richard Freeman

Rémi Cardona wrote:

Ciaran McCreesh a écrit :

Kills the upgrade path completely. No good.


Lemme sum this up in layman's terms :

1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
avoid that for various reasons, all 100% valid.


2) Putting the EAPI in the filename :

 + it solves 1)
 + it keeps backward compatibility because old PM won't recognize the 
filenames

 - it's not very pretty

3) Putting the EAPI in metadata.xml or in another external file

 + it solves 1)
 + it keeps pretty file names
 - it breaks backwards compatibility
 - (specific to metadata.xml) PM will have to learn to read XML (yuck)

That's about it, right?



You missed some options - I'll try to be honest about their pros/cons:

4) Putting EAPI inside the ebuild, but in a manner that does not require 
sourcing using bash (ie comment at top of file).


+ it solves 1)
+ it keeps pretty file names
+ syntax/implementation is trivial
- it breaks backwards compatibility (eventually - hacks might delay this)
- it does force future ebuilds to have the EAPI line in it

5) Putting EAPI inside the ebuild as in #4, but do a one-time-only 
change of the filenames.


+ it solves 1)
+ it sort-of-keeps pretty file names (two pretty extensions instead of one)
+ syntax/implementation is trivial
+ it preserves backwards compatibility
- it does force future ebuilds to have the EAPI line in it

6) Putting EAPI inside the ebuild as in #4, and do a one-time rsync 
location change


+ it solves 1)
+ the filenames don't change at all
+ syntax is trivial, future ebuilds are trivial
+ it preserves backwards compatibility
- it does force future ebuilds to have the EAPI line in it
- it seems like quite a hack - and you end up with a dummy portage tree 
sitting out there for some period of time



Personally, I tend to lean towards either just putting the EAPI in the 
filename, or putting it in the first line and breaking backwards 
compatibility.  The whole reason we're in this mess is the ebuild file 
format does not include a version field or the equivalent of extensible 
headers used in other sorts of files (tar, etc).  We've certainly broken 
backwards-compatibility before with other changes within the distro. 
All we need to do is make it easy to update to a package manager that 
fixes the break and post instructions prominently, and make sure that 
package managers support the new process for a few months before taking 
advantage of it.


Some object to parsing out the EAPI without sourcing the ebuild (only 
bash can source bash).  I disagree with this argument - every time you 
run a shell script it is sourced by something other than bash - the 
kernel has to figure out what script interpreter to use by parsing the 
first line.  There is no reason we can't use a magic number in the same 
way with the EAPI.  That isn't reason enough on its own to put the EAPI 
in the filename, but it is a start.


Most software packages store version information internal to a file 
format.  I'm actually not aware of many that put it in the filename.

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Fernando J. Pereda


On 10 Jun 2008, at 15:48, Luca Barbato wrote:


Fernando J. Pereda wrote:
No, it doesn't make parsing faster. Had you bothered to profile any  
package manager you'd know that.


Do you have any number to share?


What number are you interested in?

- ferdy

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Richard Freeman

Joe Peterson wrote:


No, I have not profiled PMs to try this, but you are saying that reading
the first few lines of a file is not faster than sourcing the whole
thing with bash?  Remember that it could abort the minute it sees a non
'#' or blank line, which would be after the first few.



Actually, if you specified that the EAPI goes on the first line, then 
you'd only need to read the first line.


And to the extent that the rest got read into memory anyway by the 
kernel, well then it is already in the cache when whatever mechanism is 
invoked to parse the rest of the file.


I don't think that filename-vs-first-line is going to make a big 
difference in practical performance.  Any time lost in determining EAPI 
would be time saved in parsing the file.  And even though you could 
ignore unknown EAPIs, I think that in a typical case users would be 
using an up-to-date package manager that would just end up parsing 
everything all the time anyway.

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 07:49:31 -0600
Joe Peterson [EMAIL PROTECTED] wrote:
  No, it doesn't make parsing faster. Had you bothered to profile
  any package manager you'd know that.
 
 No, I have not profiled PMs to try this, but you are saying that
 reading the first few lines of a file is not faster than sourcing the
 whole thing with bash?  Remember that it could abort the minute it
 sees a non '#' or blank line, which would be after the first few.

The package manager does not currently source the whole thing with
bash to get the EAPI, nor does it open the ebuild file at all for
metadata. You're talking doubling the number of file operations here,
and going from extremely good filesystem locality (which means very few
seeks) to jumping backwards and forwards all over the place.

This is basic stuff you really need to know before you can comment
sensibly on a discussion about package metadata.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 09:49:04 -0400
Richard Freeman [EMAIL PROTECTED] wrote:
 4) Putting EAPI inside the ebuild, but in a manner that does not
 require sourcing using bash (ie comment at top of file).
 
 + it solves 1)
 + it keeps pretty file names
 + syntax/implementation is trivial
 - it breaks backwards compatibility (eventually - hacks might delay
 this)
 - it does force future ebuilds to have the EAPI line in it

- it doubles the number of file reads necessary during resolution.
- it heavily restricts future syntax and meaning of EAPIs
- it makes comments have meaning

 Most software packages store version information internal to a file 
 format.  I'm actually not aware of many that put it in the filename.

Most software doesn't have to care about backwards / forwards
compatibility.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 09:56:18 -0400
Richard Freeman [EMAIL PROTECTED] wrote:
 Joe Peterson wrote:
  No, I have not profiled PMs to try this, but you are saying that
  reading the first few lines of a file is not faster than sourcing
  the whole thing with bash?  Remember that it could abort the minute
  it sees a non '#' or blank line, which would be after the first few.
  
 
 Actually, if you specified that the EAPI goes on the first line, then 
 you'd only need to read the first line.
 
 And to the extent that the rest got read into memory anyway by the 
 kernel, well then it is already in the cache when whatever mechanism
 is invoked to parse the rest of the file.

Except that currently, the ebuild file isn't opened for read. So it's
not in memory at all.

 I don't think that filename-vs-first-line is going to make a big 
 difference in practical performance.

It's about a factor of five difference in cold-cache resolution
performance for Paludis.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Arun Raghavan
On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
[...]
 - it doubles the number of file reads necessary during resolution.

The first read will cause the file to be cached for subsequent reads
anyway, so the performance hit boils down to an additional read() call
(which will probably be buffered by your file I/O library anyway, so
it's unlikely to even result in a context switch). And even without,
it is well worth the lack of fugliness in the ebuild name.

 - it heavily restricts future syntax and meaning of EAPIs

Not by much. It's just a header.

 - it makes comments have meaning

Just as much as #!/bin/bash and # vim: ... do

Regards,
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Arun Raghavan
On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
[...]
 I don't think that filename-vs-first-line is going to make a big
 difference in practical performance.

 It's about a factor of five difference in cold-cache resolution
 performance for Paludis.

Could you please share more details on the experiment that showed this
kind of performance degradation and the numbers, if possible?

Thanks,
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Luca Barbato

Fernando J. Pereda wrote:


On 10 Jun 2008, at 15:48, Luca Barbato wrote:


Fernando J. Pereda wrote:
No, it doesn't make parsing faster. *Had you bothered to profile any 
package manager you'd know that.*


Do you have any number to share?


What number are you interested in?


Profiling numbers...

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Rémi Cardona

Ciaran McCreesh a écrit :

The package manager does not currently source the whole thing with
bash to get the EAPI, nor does it open the ebuild file at all for
metadata. You're talking doubling the number of file operations here,
and going from extremely good filesystem locality (which means very few
seeks) to jumping backwards and forwards all over the place.


Yeah, grepping through the ebuild is just bound to get a massive 
performance hit, I don't have numbers but that just looks obvious.


Ciaran, what other pitfalls do you see for using one EAPI file per 
package (except for the broken compatibility, I know it's a big one) ?



This is basic stuff you really need to know before you can comment
sensibly on a discussion about package metadata.


Then, thanks for explaining those things :) We are learning stuff as we go.

--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Bernd Steinhauser

Luca Barbato schrieb:

Piotr Jaroszyński wrote:
The simplest way is to change the syncpoint in the new package 
manager and

leave the previous uri with a compatibility repo for the older ones.


So we add a new repo each time a new EAPI comes out? Sounds like a big 
mess.


It isn't you just keep 2 repos, one with the minimal eapi and the 
minimal set of ebuilds needed to upgrade, one with the latest and greatest.


lu


Then you could also just provide binaries...

But lets face it, it slows down progress, because you will delay every 
change, because stuff like that you will only do if necessary.

And it is still huge pain, from a users point of view, to upgrade stuff.

And that is, what this is about, making EAPI bumps as less painful as 
possible. The filename is the easiest solution for that.


I really fail to see the point, why it is so important, that the 
extension will still be .ebuild in the future.


There is a lot of software, that keeps using the same filename for 
different versions of stuff and in many cases, that is a huge mess.


I still haven't seen any good reasons against it.
And btw, the KDE overlay users don't seem at all to be confused, because 
the packages are named .kdebuild-1 instead of .ebuild.

Portage (and other tools) keeps happily ignoring them, like it should.
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 16:11:49 +0200
Rémi Cardona [EMAIL PROTECTED] wrote:
 Ciaran McCreesh a écrit :
  The package manager does not currently source the whole thing with
  bash to get the EAPI, nor does it open the ebuild file at all for
  metadata. You're talking doubling the number of file operations
  here, and going from extremely good filesystem locality (which
  means very few seeks) to jumping backwards and forwards all over
  the place.
 
 Yeah, grepping through the ebuild is just bound to get a massive 
 performance hit, I don't have numbers but that just looks obvious.

No no. Doing the seek to open a file in a different directory and then
seeking back to your original directory over and over when otherwise
you'd be doing nice linear opens on adjacent inodes in a single
directory is where the performance hit is.

Paludis is pretty much seek bound in a lot of cases.

 Ciaran, what other pitfalls do you see for using one EAPI file per 
 package (except for the broken compatibility, I know it's a big one) ?

It's moving the relevant information further and further away from
where it's supposed to be. It doubles the number of files a developer
has to check in order to do simple ebuild maintenance.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 19:54:33 +0530
Arun Raghavan [EMAIL PROTECTED] wrote:
 Well, most file systems have a local structure for this data (= block
 group), so it's not going to be a seek that's very far. Secondly, how
 many ebuilds do you need to read directly to get this data in a
 typical case? Isn't this what the metadata cache is for?

It's a nice local structure when you're just using a) a nice, linear,
readahead-friendly-ish slurp of the ebuild directory and b) a nice,
linear slurp of files in the metadata cache, which is how things are
now. When you move that to having to make alternating use of the
metadata cache and the ebuild files, you're suddenly seeking backwards
and forwards between two places over and over.

   - it heavily restricts future syntax and meaning of EAPIs
 
  Not by much. It's just a header.
 
  !-- EAPI=3 --
 
 Do we want to keep the spec so wide open that we support any format
 under the Sun that we fancy? Seems like overgeneralizing to me.

We want to keep it open enough that we're not going to have to go
through yet another backwards compatibility breaking change.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

2008-06-10 Thread Robert Bridge
On Tue, 10 Jun 2008 02:58:54 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

  Well, in general, if you rely on extensions changing every time a
  program cannot deal with a new feature of a file format, it would be
  quite crazy.  For example, if C programs had to start using .c-2,
  .c-3, etc., it would get ugly fast.
 
 Which is why programs that use any major C feature introduced since
 1980 use the extension '.cc' or '.cpp'.

Except any program using .cc or .cpp for code is liable to break on
gcc, as they are C++ file extensions, and to the best of my (admittedly
limited knowledge) C and C++ are distinct languages...

So relying on the file extension seems to be a recipe for
misunderstanding. Why limit the functionality of the package manager to
rely on the file names? How do you protect the package manager from a
malicious ebuild masquerading under the wrong EAPI? Relying on the file
name for information is the kind of design decision we laugh at in
Windows, so why adopt it here?
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Rémi Cardona

Ciaran McCreesh a écrit :

No no. Doing the seek to open a file in a different directory and then
seeking back to your original directory over and over when otherwise
you'd be doing nice linear opens on adjacent inodes in a single
directory is where the performance hit is.

Paludis is pretty much seek bound in a lot of cases.


Ok


It's moving the relevant information further and further away from
where it's supposed to be. It doubles the number of files a developer
has to check in order to do simple ebuild maintenance.


I said one file per package, not per ebuild. It only doubles the number 
of files if there's only one ebuild in a given package :)


--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 19:40:22 +0530
Arun Raghavan [EMAIL PROTECTED] wrote:
 On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
 [EMAIL PROTECTED] wrote:
 [...]
  I don't think that filename-vs-first-line is going to make a big
  difference in practical performance.
 
  It's about a factor of five difference in cold-cache resolution
  performance for Paludis.
 
 Could you please share more details on the experiment that showed this
 kind of performance degradation and the numbers, if possible?

Shove an open and a getline in when doing what would otherwise be a
successful cache read. It adds a couple of thousand new open()s on
files that would otherwise be left alone, and changes the nice linear
slurp up things in this directory in order until we don't need
anything else pattern into bounce backwards and forwards between lots
of files in two different directories.

On a cold cache, which is the most common use case, this is very very
nasty.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Arun Raghavan
On Tue, Jun 10, 2008 at 7:44 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
[...]
 The first read will cause the file to be cached for subsequent reads
 anyway, so the performance hit boils down to an additional read() call
 (which will probably be buffered by your file I/O library anyway, so
 it's unlikely to even result in a context switch). And even without,
 it is well worth the lack of fugliness in the ebuild name.

 No, it results in a new open() on a file that's elsewhere on disk, which
 results in two new seeks. You get about fifty seeks per second.

Well, most file systems have a local structure for this data (= block
group), so it's not going to be a seek that's very far. Secondly, how
many ebuilds do you need to read directly to get this data in a
typical case? Isn't this what the metadata cache is for?

  - it heavily restricts future syntax and meaning of EAPIs

 Not by much. It's just a header.

 !-- EAPI=3 --

Do we want to keep the spec so wide open that we support any format
under the Sun that we fancy? Seems like overgeneralizing to me.

Regards,
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 15:36:58 +0100
Robert Bridge [EMAIL PROTECTED] wrote:
 So relying on the file extension seems to be a recipe for
 misunderstanding. Why limit the functionality of the package manager
 to rely on the file names? How do you protect the package manager
 from a malicious ebuild masquerading under the wrong EAPI? Relying on
 the file name for information is the kind of design decision we laugh
 at in Windows, so why adopt it here?

There is no protection against malicious ebuilds. Malicious ebuilds
already run code as root when you install them. Being able to get an
ebuild run with the wrong EAPI is utterly irrelevant.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Fernando J. Pereda


On 10 Jun 2008, at 16:14, Ciaran McCreesh wrote:


On Tue, 10 Jun 2008 19:38:52 +0530
Arun Raghavan [EMAIL PROTECTED] wrote:

On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
[...]

- it doubles the number of file reads necessary during resolution.


The first read will cause the file to be cached for subsequent reads
anyway, so the performance hit boils down to an additional read()  
call

(which will probably be buffered by your file I/O library anyway, so
it's unlikely to even result in a context switch). And even without,
it is well worth the lack of fugliness in the ebuild name.


No, it results in a new open() on a file that's elsewhere on disk,  
which

results in two new seeks. You get about fifty seeks per second.


Plus path resolution, which isn't exactly free

- ferdy
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55 - The Long Thread

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 10:51:39 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:
 I urge you all to sit down and hammer out real use case situations 
 instead of the idealistic foo/bar/baz concepts.

The use cases are stated rather clearly in the GLEP, which you clearly
didn't bother to read...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Joe Peterson
Bernd Steinhauser wrote:
 And that is, what this is about, making EAPI bumps as less painful as 
 possible. The filename is the easiest solution for that.

In any design, there are easy short-cuts that can be taken.  But
sometimes these short-cuts break paradigms that are fundamental.  If you
wanted, you could throw a bunch of things into the filename and make it
255 characters long to avoid reading the file, but that clearly would be
a pretty bad design.

 I really fail to see the point, why it is so important, that the 
 extension will still be .ebuild in the future.
 
 There is a lot of software, that keeps using the same filename for 
 different versions of stuff and in many cases, that is a huge mess.

Is the huge mess you are thinking of the basic reality that software
of any reasonable complexity needs to deal with file formats evolving?
If so, that is exactly why EAPIs now are being introduced.

But almost all software deals with this transparently - no need to
expose it to the user, and sticking the version in the filename is both
fragile (renaming the file can alter it) and seems like a hack.

 I still haven't seen any good reasons against it.

I realize that there are two camps of people here.  One camp sees
mangling the filename extension as an undesirable way to deal with this,
and the other camp simply sees no problem with this.

I want to point out, however, that the fact that you do not see the
issue does not make the issue invalid.  I am sure there are people who
work at Apple who care nothing about the way an iPhone looks or feels
and only care that it works correctly.  If that person went to Steve
Jobs and said, Why are you spending so much money to make this thing
look cool?, he would say that Apple is known for making cool things,
and no one would buy something that works great but looks like a piece
of junk.  He'd be right.

I realize this analogy is a bit of an exaggeration, but there is no
reason we cannot make EAPIs work correctly and very efficiently (this is
where technical innovation comes in), while also keeping the basic
interface (and I include file name convention here) clean, standard,
uncluttered, uncomplicated, and elegant.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 09:02:29 -0600
Joe Peterson [EMAIL PROTECTED] wrote:
 But almost all software deals with this transparently - no need to
 expose it to the user, and sticking the version in the filename is
 both fragile (renaming the file can alter it) and seems like a hack.

The typical user does not deal with the ebuild files themselves, and
if they are doing so it's because there's a deficiency in the tools
available to them. Any user who *does* deal with ebuild files is doing
something sufficiently advanced that they need to be aware of EAPIs
anyway.

As for fragile... You might as well say that sticking PN and PV in the
file is fragile and a hack...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Richard Freeman

Ciaran McCreesh wrote:

On Tue, 10 Jun 2008 19:40:22 +0530
Arun Raghavan [EMAIL PROTECTED] wrote:

On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
[...]

I don't think that filename-vs-first-line is going to make a big
difference in practical performance.

It's about a factor of five difference in cold-cache resolution
performance for Paludis.

Could you please share more details on the experiment that showed this
kind of performance degradation and the numbers, if possible?


Shove an open and a getline in when doing what would otherwise be a
successful cache read. It adds a couple of thousand new open()s on
files that would otherwise be left alone, and changes the nice linear
slurp up things in this directory in order until we don't need
anything else pattern into bounce backwards and forwards between lots
of files in two different directories.

On a cold cache, which is the most common use case, this is very very
nasty.



I'm curious as to what operation in particular we're looking at.  Let's 
say I type in paludis --sync:


Obviously the first step is to rsync the portage tree.  Then we find all 
modified files (already output by rsync) and update the caches.  We 
already need to fully parse every file to create a dependency tree, so 
why is it slow to cache the EAPI for each file while we're at it?


Next, suppose I type in paludis -pi world:

Why wouldn't everything you need not already be in the cache?  And if 
something wasn't, then why is reading in the EAPI any slower than 
reading in (R)DEPEND/KEYWORDS/IUSE/etc?


What specific operation (from an end-user perspective) is improved by 
putting EAPI in the filename?  I'm not interested in theoretical 
operations like given a portage tree, find the EAPI of every file - 
users don't do those operations routinely in isolation, but as part of 
larger operations where doing an open and a getline now just speeds up 
the open and getline that would be executed 500 lines later anyway.


Again, I'm not completely opposed to the idea of putting EAPI in the 
filename, but I'm not convinced that the arguments in favor of it are as 
clear-cut as some are suggesting.  If everybody was open about the 
pros/cons of each solution and not suggesting that one solution is 
near-perfect and the others are total non-starters then this whole 
debate would probably be a whole lot less contentious.  When people 
perceive that somebody isn't honest about the shortcomings of their own 
proposal then they're less likely to trust them - it is just a human 
thing...

--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] GLEP 55 - The Long Thread

2008-06-10 Thread Doug Goldstein
Since there's so many places to comment and I have no intention of 
hitting all these areas, I'll just create a new thread.


There's a lot to be said about being stuck in the grand design 
mindset.  I know many Gentoo, Portage, Exherbo, and Paludis developers 
are clearly coming to that point in their programming careers based on 
the comments on this thread and other threads. I would just like to 
caution everyone that they really need to get past this plateau in their 
programming careers and get on to the real mindset that matters in the 
future. The use case mindset.


I urge you all to sit down and hammer out real use case situations 
instead of the idealistic foo/bar/baz concepts.

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 11:08:21 -0400
Richard Freeman [EMAIL PROTECTED] wrote:
 I'm curious as to what operation in particular we're looking at.
 Let's say I type in paludis --sync:

paludis --sync doesn't use metadata.

 Next, suppose I type in paludis -pi world:

If it's straight after a --sync, then yes, some things are pre-loaded
by rsync. Similarly, if it's straight after other operations, then yes,
some things are pre-loaded. But we don't plan for just the use cases
that make our life easy.

 Why wouldn't everything you need not already be in the cache?  And if 
 something wasn't, then why is reading in the EAPI any slower than 
 reading in (R)DEPEND/KEYWORDS/IUSE/etc?

Currently we don't touch the ebuild's content *at all* for metadata
operations, except where there's no or stale metadata cache (which is
rare). We can get away with this currently because 0 and 1 have
identical cache layouts and PMS has some (necessary) weasel wording;
future EAPIs likely won't, so we're back to the chicken / egg problem.

So... We either have the EAPI from the extension (which we already
have, since we have to read the dir to know what versions are
available), in which case we know how to read the metadata cache file.
Or we have to open up a file that would otherwise not be opened, just
to parse one line so we know how to read the cache file.

 What specific operation (from an end-user perspective) is improved by 
 putting EAPI in the filename?  I'm not interested in theoretical 
 operations like given a portage tree, find the EAPI of every file - 
 users don't do those operations routinely in isolation, but as part
 of larger operations where doing an open and a getline now just
 speeds up the open and getline that would be executed 500 lines later
 anyway.

paludis -pi anything on a cold cache.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Mike Auty

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
| No, it results in a new open() on a file that's elsewhere on disk, which
| results in two new seeks. You get about fifty seeks per second.

The speed issues aren't really a concern, since the GLEP suggests that
the ebuild must be sourced anyway.  The GLEP allows for a .ebuild-2 file
to contain EAPI=1.  This requires the package manager to source the
ebuild to find out exactly what EAPI should be being used.  The GLEP
doesn't strictly outline what happens to a .ebuild-1 containing EAPI=2
for a PM that supports EAPI=2 (which needs to be addressed before the
GLEP gets put into action).

It does say a developer should not specify both a pre- and post- source
EAPI, but the GLEP says that if both exist the post-source one is used.
~ That means all package managers would have to source the ebuilds.

Personally, as a developer, I don't want to be messing around with yet
more numbers in the ebuild filenames, and I think it looks ugly.  Not
great arguments, granted.

It also feels like a bad idea to separate information required to
process the contents of the file from the contents of the file itself.
P/PN/PV variables are used in clearly defined locations of the file, and
the script could run under a different name and version (as proved by
every version bump around).  The suggestion seems to be that an ebuild
could not run under a different EAPI.  In that case, the EAPI version
should be embedded in the contents of the file.

As people have pointed out though, there's no need to rush this
decision.  We're simply not going to achieve backwards compatibility
forever (we haven't in the past), so why not choose a time period to
allow for upgrades (6 months, a year?) and implement a new EAPI
definition mechanism that's present in the file and offers a slightly
better compromise between the various parties than the current suggestion?

It will require a little more patience, but it offers time for a thought
out and well designed choice.  What's the rush?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhOpDEACgkQu7rWomwgFXoFvgCeMxSfRiQLEZr3QyT+Bx4b5aNe
/9EAnicrcCQTXxsliAeM4mdisgjO7abg
=tGD8
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Bernd Steinhauser

Joe Peterson schrieb:

Bernd Steinhauser wrote:
And that is, what this is about, making EAPI bumps as less painful as 
possible. The filename is the easiest solution for that.


In any design, there are easy short-cuts that can be taken.  But
sometimes these short-cuts break paradigms that are fundamental.  If you
wanted, you could throw a bunch of things into the filename and make it
255 characters long to avoid reading the file, but that clearly would be
a pretty bad design.
Yes, in principle you could do that, but in principle you could do the 
same with the first line in a file or whatever you are suggesting.



I really fail to see the point, why it is so important, that the 
extension will still be .ebuild in the future.


There is a lot of software, that keeps using the same filename for 
different versions of stuff and in many cases, that is a huge mess.


Is the huge mess you are thinking of the basic reality that software
of any reasonable complexity needs to deal with file formats evolving?
If so, that is exactly why EAPIs now are being introduced.

But almost all software deals with this transparently - no need to
expose it to the user, and sticking the version in the filename is both
fragile (renaming the file can alter it) and seems like a hack.
Wow, altering the content of a file can alter it, too. What is the point 
there?

BTW, so you are suggesting, that we shouldn't put the PV in the file name?
We shouldn't put the revision in the file name?

Hm, so in the future, there will be a metadata.xml file, that defines:
- EAPI
- PV
- KEYWORDS
- more stuff
of  the ebuild? Sounds complicated.


I still haven't seen any good reasons against it.


I realize that there are two camps of people here.  One camp sees
mangling the filename extension as an undesirable way to deal with this,
and the other camp simply sees no problem with this.

Seems to be like that.
But I am really impress, how far some people go, to avoid renaming the 
file extension of a file.



--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Doug Goldstein
Let's try to aim to do an EAPI=2 sometime soonish since Portage now has 
USE flag depends in version 2.2 which is looming on the horizon. It'd be 
nice to hit the ground running with supporting these. I know it'll be 
trivial for the Paludis and pkgcore guys to make this work since they 
already support USE flag depends.


So... let's get the party started.
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Patrick Lauer

Doug Goldstein wrote:
Let's try to aim to do an EAPI=2 sometime soonish since Portage now 
has USE flag depends in version 2.2 which is looming on the horizon. 
It'd be nice to hit the ground running with supporting these. I know 
it'll be trivial for the Paludis and pkgcore guys to make this work 
since they already support USE flag depends.


So... let's get the party started.

The question is then, what features do people want there?

I've seen a few things mentioned, but I presume there are two 
restrictions -

1) feature needs to be reasonably useful to enough people
2) feature needs to be implementable in a short enough timeframe

So EAPI 2 is not everything shiny, but a small iterative improvement 
to EAPI 1.


Suggest features then and let's discuss!
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Nirbheek Chauhan
On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
[EMAIL PROTECTED] wrote:
 So EAPI 2 is not everything shiny, but a small iterative improvement to
 EAPI 1.

 Suggest features then and let's discuss!

For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a
tracker for EAPI feature requests.

I personally like https://bugs.gentoo.org/197859 the most -- split out
src_configure from src_compile which will allow sane resuming of
compiles :)

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Doug Goldstein

Nirbheek Chauhan wrote:

On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
[EMAIL PROTECTED] wrote:
  

So EAPI 2 is not everything shiny, but a small iterative improvement to
EAPI 1.

Suggest features then and let's discuss!



For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a
tracker for EAPI feature requests.

I personally like https://bugs.gentoo.org/197859 the most -- split out
src_configure from src_compile which will allow sane resuming of
compiles :)

  
At this point, we should really only discuss features that all 3 package 
managers have implemented.

--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Last rites: kde-base/ksync

2008-06-10 Thread Tobias Heinlein
# Tobias Heinlein [EMAIL PROTECTED] (10 Jun 2008)
# Masked for removal on 20 Jun 2008.
# Pulls in kdelibs of which all current versions are providing
# the same functionality, thus already blocking ksync.
kde-base/ksync
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Richard Brown
On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED] wrote:
 At this point, we should really only discuss features that all 3 package
 managers have implemented.

I'm not sure that's a good idea, only two have implemented EAPI 1 so far.

-- 
Richard Brown
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Olivier Galibert
On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote:
 Ciaran McCreesh a écrit :
 Kills the upgrade path completely. No good.
 
 Lemme sum this up in layman's terms :
 
 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
 avoid that for various reasons, all 100% valid.

sourcing != reading the first line/n first lines/first block and grepping.

  OG.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Rémi Cardona

Olivier Galibert a écrit :

On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote:

Ciaran McCreesh a écrit :

Kills the upgrade path completely. No good.

Lemme sum this up in layman's terms :

1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
avoid that for various reasons, all 100% valid.


sourcing != reading the first line/n first lines/first block and grepping.


IO-wise, it's the same, as most ebuilds fit inside a kernel memory page 
(ie, 4KB on most arches). So with a cold cache, the time required to 
actually run bash to source the ebuild won't matter much.


But we're getting lost on this thread, let's let it cool off for a 
little while :)


Cheers,

Rémi
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Fernando J. Pereda


On 10 Jun 2008, at 19:06, Patrick Lauer wrote:


On Tuesday 10 June 2008 16:54:49 Richard Brown wrote:
On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED]  
wrote:
At this point, we should really only discuss features that all 3  
package

managers have implemented.


I'm not sure that's a good idea, only two have implemented EAPI 1  
so far.



Yes, but noone cares about Paludis.


Ah, Paludis does support EAPI-1 just fine. Thank you.

- ferdy

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Fernando J. Pereda


On 10 Jun 2008, at 18:39, Doug Goldstein wrote:


Nirbheek Chauhan wrote:

On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
[EMAIL PROTECTED] wrote:

So EAPI 2 is not everything shiny, but a small iterative  
improvement to

EAPI 1.

Suggest features then and let's discuss!



For reference of existing ideas -- https://bugs.gentoo.org/174380  
-- a

tracker for EAPI feature requests.

I personally like https://bugs.gentoo.org/197859 the most -- split  
out

src_configure from src_compile which will allow sane resuming of
compiles :)


At this point, we should really only discuss features that all 3  
package managers have implemented.


I'm not sure this intersection isn't empty :/

We might, however, only discuss features that all 3 package managers  
can implement easily.


- ferdy

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Nirbheek Chauhan
On Tue, Jun 10, 2008 at 11:04 PM, Fernando J. Pereda [EMAIL PROTECTED] wrote:

 On 10 Jun 2008, at 18:39, Doug Goldstein wrote:
 At this point, we should really only discuss features that all 3 package
 managers have implemented.

 I'm not sure this intersection isn't empty :/

How about we define this as EAPI=0? =)

Jokes aside, I agree with you. Features that all three package
managers have already implemented (release or beta) are quite
uninteresting. However, this will make for a more sane discussion, and
will _actually_ result in an EAPI=2 getting approved, say, in the next
Council meeting.

I say this is better than a feature-complete EAPI=2 that stays on hold
for a year because we can't collectively decide on it, results in
PM-specific overlays, loud bitching about how nothing ever gets done,
and results in overall wastage of energy.


 We might, however, only discuss features that all 3 package managers can
 implement easily.

I say this should be done in the context of EAPI=3 once we all agree
on what EAPI=2 should contain (let's take it slow ;)

If we start discussing EAPI=3 *now*, we _might_ get it out 6 months later[1] ;p



1. Sorry, that's how open source usually works :)
-- 
~Nirbheek Chauhan
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55 - The Long Thread

2008-06-10 Thread Doug Goldstein

Ciaran McCreesh wrote:

On Tue, 10 Jun 2008 10:51:39 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:
  
I urge you all to sit down and hammer out real use case situations 
instead of the idealistic foo/bar/baz concepts.



The use cases are stated rather clearly in the GLEP, which you clearly
didn't bother to read...

  

Concrete use cases instead of idealistic ones...
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Doug Goldstein

Fernando J. Pereda wrote:


On 10 Jun 2008, at 18:39, Doug Goldstein wrote:


Nirbheek Chauhan wrote:

On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
[EMAIL PROTECTED] wrote:

So EAPI 2 is not everything shiny, but a small iterative 
improvement to

EAPI 1.

Suggest features then and let's discuss!



For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a
tracker for EAPI feature requests.

I personally like https://bugs.gentoo.org/197859 the most -- split out
src_configure from src_compile which will allow sane resuming of
compiles :)


At this point, we should really only discuss features that all 3 
package managers have implemented.


I'm not sure this intersection isn't empty :/

We might, however, only discuss features that all 3 package managers 
can implement easily.


- ferdy


That's more of what I meant.
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Nominations for council

2008-06-10 Thread Alexis Ballier
On Thu, 5 Jun 2008 22:41:40 +0300
Samuli Suominen [EMAIL PROTECTED] wrote:

 Tue, 3 Jun 2008 05:52:35 +
 Ferris McCormick [EMAIL PROTECTED] kirjoitti:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  
  I think nominations are open.  I nominate
 
 Then I'd like to nominate (mostly same ones again)
[..]
 aballier

Thanks, but I decline. Considering all the nominee, I think there are
enough people probably more able than I am to run a council. My habit
of not getting involved in endless discussions would have probably not
helped to get elected anyway ;) Moreover, with all the recent
threads here, I don't think I want to be in the group that will have to
take the decisions.

Regards,

Alexis.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Federico Ferri

Joe Peterson ha scritto:

It was mentioned that comments are to be ignored, but you point out a
perfect and very fundamental example of where this is not true:

#!/usr/bin/env bash

Putting another line close to this one with:

#EAPI=42

or

#!EAPI=42

if you like (conforms more to the shell script specifier), is not too
muchh of a stretch.


The so-called shebang; very good in my opinion!

Works very well for true shell scripts. why it can't work for ebuilds?


First, I think of two alternatives:

1) the interpreter is the EAPI (with /usr/bin/ebuild being EAPI=0)
this will be the first line of a EAPI=0 ebuild:

   #!/usr/bin/ebuild

this will be a EAPI=paludis ebuild:

   #!/usr/bin/ebuild-paludis

apparently it's the same mechanism the shell uses to execute a shell 
script, except for the fact that:

*  ebuild is not an executable file
*  an external program is used to determine the EAPI (i.e.: extract the 
shebang)



2) fixed interpreter name, use arguments for switching EAPIs

this is another option, wich carries itself a GREAT power of leaving an 
open door when in the future will happen something similar to what we 
have now, where switching the EAPI (or replace EAPI with something else) 
is critical and breaks compatibility.


example - EAPI=0:
   #!/usr/bin/ebuild
   ...
another eapi:
   #!/usr/bin/ebuild -eapi paludis

This allows virtually unlimited cases similar to this; for example when 
switching to another-feature-that-breaks-things, another switch will 
be used:


   #!/usr/bin/ebuild -eapi foo -fluffy bar



Advantages of both solutions:
* easy to parse
* doesn't break compatibility

What it does not address:
* doesn't break compatibility

In fact, it should break compatibility.
again I can think of two solutions:
1) change the ebuild extension to a different value, once and 
(hopefully) forever, e.g. from .ebuild to .xbuild, and leave the minimal 
set of .ebuild-s for the upgrade path
2) use two repositories: the legacy one, needed for the upgrade path, 
and the shyny-new-repository with the new ebuilds format



best regards,
Federico Ferri

--
#include stdio.h
main(){printf(%x,4275974592);}


-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d-(--) a- C++$ UL+++$ L+++$ E--- W++@ w--@
PE PGP+ R- tv-- DI+ D++ h+
--END GEEK CODE BLOCK--




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Freedesktop utils in ebuild

2008-06-10 Thread René 'Necoro' Neumann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

René 'Necoro' Neumann schrieb:
 Hi list,
 
 I'm currently trying to update an ebuild (x11-misc/zim) to a new version.
 The old one uses a patch to disable running update-desktop-database and
 instead using the fdo-mime_desktop_database_update function.
 
 Now - the new ebuild also wants to call:
 
 - update-mime-database -- disable and use fdo-mime_mime_database_update ?
 - xdg-icon-resource install -- let it run? - or disable it (and replace it
 by what)?
 
 Would be glad, if someone could clarify the use here :)
 
 - Necoro
 

Ping? - Anyone?

Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhO8b0ACgkQ4UOg/zhYFuBFSQCfXwsTyG+wgmwFRZeYDTYYu9IS
6FwAn0Vde7NSQkehB4T0BHymKGeC4b27
=SAW7
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [gentoo-user] dspam useflags improvement (was tuning ./configure parameters via emerge)

2008-06-10 Thread Nicolas Sebrecht
Enrico Weigelt [EMAIL PROTECTED] a écrit:

 which package and which options are you exactly going to change ?
 
 IMHO, it's wise to improve the ebuild and perhaps add some useflag.

I agree. It seems that current useflags doesn't permit enough tuning.
Today, I need to use $EXTRA_ECONF with some packages.

For example, emerge dspam package to make it run with qmail doesn't
work. Here is what the dspam manual says:

-BEGIN--/usr/share/doc/dspam-3.8.0-r11/doc/qmair.txt.bz2--

USER-LEVEL INTEGRATION

If you are only configuring dspam for a small percentage of your users,
this is the best method. Configure dspam to use a standalone local
delivery agent like safecat (if you already use procmail or maildrop as
an LDA, you should call dspam from those tools directly). 

First, create a small script called maildir_mod in /usr/local/bin...

  #!/bin/sh
  VPOPDOMAINS=/home/vpopmail/domains
  if [[ $2 = -d ]]; then
  user=`eval echo $3 | cut -f 1 -d @`
  domain=`eval echo $3 | cut -f 2 -d @`
  cd $VPOPDOMAINS/$domain/$user
  fi
  /usr/local/bin/safecat $1/tmp $1/new 1/dev/null

  NOTE: Be sure to configure VPOPDOMAINS to point to the path for your
virtual domain directories

Now configure DSPAM:

./configure \
  --with-dspam-owner=vpopmail \
  --with-dspam-group=vchkpw \
  --with-delivery-agent=/usr/local/bin/maildir_mod Maildir -d %u \
  # Your arguments

Next, create a .qmail file in the directory for the user with a line to
call dspam, like this:

 | /usr/local/bin/dspam --deliver=innocent --user [EMAIL PROTECTED]

The two environment variables $EXT and $USER are created by the
qmail-local program which begins the local delivery process.

-END/usr/share/doc/dspam-3.8.0-r11/doc/qmair.txt.bz2--


Here is the ebuild content: 

-BEGIN--/usr/portage/mail-filter/dspam/dspam-3.8.0-r11.ebuild-

econf --with-storage-driver=${STORAGE} \
--with-dspam-home=${DSPAM_HOMEDIR} \
--sysconfdir=${DSPAM_CONFDIR} \
$(use_enable daemon) \
$(use_enable ldap) \
$(use_enable clamav) \
$(use_enable large-domain large-scale) \
$(use_enable !large-domain domain-scale) \
$(use_enable syslog) \
$(use_enable debug) \
$(use_enable debug bnr-debug) \
$(use_enable debug verbose-debug) \
--enable-long-usernames \
--with-dspam-group=dspam \
--with-dspam-home-group=dspam \
--with-dspam-mode=${DSPAM_MODE} \
--with-logdir=${DSPAM_LOGDIR} \
${myconf} || die econf failed

-END/usr/portage/mail-filter/dspam/dspam-3.8.0-r11.ebuild-


I run ('\' end-line char added in this mail only):
prompt EXTRA_ECONF=--with-dspam-owner=vpopmail \
--with-dspam-group=vchkpw \
--with-delivery-agent=\/usr/local/bin/maildir_mod Maildir \-d %u\ \
emerge -v dspam

The compilation failed. I think I will make a bug report...


Nevertheless, I guess dspam and qmail integration can be done on
various ways and dspam can work with a lot of other MTA (you can see
/usr/share/doc/dspam-3.8.0-r11/doc/).
In this context, maintain this package (dspam) with useflags fair
system only would be a lot of work.
Having EXTRA_ECONF is enough (but should be probably more documented). 
If dspam default ebuild could just compile with extra-parameters, it 
would be great.

I hope I didn't missed something.


X-post + Fu2

-- 
Nicolas Sebrecht

-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Bo Ørsted Andresen
On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote:
 Let's try to aim to do an EAPI=2 sometime soonish since Portage now has
 USE flag depends in version 2.2 which is looming on the horizon. It'd be
 nice to hit the ground running with supporting these. I know it'll be
 trivial for the Paludis and pkgcore guys to make this work since they
 already support USE flag depends.

I would like the portage devs to comment upon which of the following features 
they think could easily be implemented before portage 2.2 goes stable. 
There's still some time since it hasn't left package.mask yet, so I'd rather 
they exclude the features that will take too long to implement than anybody 
else doing that...

Already implemented:
- Use dependencies, it's not clear to me whether we all agree entirely upon
  the syntax yet though (bugs #2272 and #174406)

Things I believe should be trivial to implement:
- Custom output names in SRC_URI, also called arrows (bug #177863)
- Guarantee trailing slashes (bug #174408)
- Limit values in $USE (bug #176467)
- doins support for symlinks (bug #179932)
- Enable FEATURES=test by default (bug #184812)
- GLEP 42 - news items

Bigger features I'm interested in:
- Making do* die on failure by default (without changing their behaviour for
  previous eapis). Possibly adding either nonfatal or try_do* for cases where 
  this isn't desired. (bug #138792)
- More phases
  - src_prepare, for applying patches and running autotools etc.
  - src_configure, for running configure scripts (bug #197859)
  - pkg_pretend (bug #177860 - could also be used to fix bug #75936)
  - maint_*, it's not clear to me if this has been fleshed out in sufficient
detail yet (bug #185567)
- default_*, allows an ebuild to redefine phases to add more functionality and
  then call default_$phase. Currently the default phases are lost when
  redefining the phases.
- default for src_install (bug #33544)
- Ranged dependencies (bug #4315)

Of course I'd like GLEPs 54 and 55 too but since the council still hasn't made 
a decision about them I'll leave them out..

-- 
Bo Andresen
Gentoo KDE Dev


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Santiago M. Mola
On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri [EMAIL PROTECTED] wrote:

 The so-called shebang; very good in my opinion!

 Works very well for true shell scripts. why it can't work for ebuilds?

This option was already discussed when GLEP 55 was proposed, and in my
opinion it's totally discarded. The concept of shebang doesn't apply
here at all. Plus /usr/bin/ebuild is a binary provided by portage
which has nothing to do with the process of sourcing ebuilds nor even
with the internals of portage (not to speak of other package
managers).

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Richard Freeman

Santiago M. Mola wrote:

On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri [EMAIL PROTECTED] wrote:

The so-called shebang; very good in my opinion!

Works very well for true shell scripts. why it can't work for ebuilds?


This option was already discussed when GLEP 55 was proposed, and in my
opinion it's totally discarded. The concept of shebang doesn't apply
here at all. Plus /usr/bin/ebuild is a binary provided by portage
which has nothing to do with the process of sourcing ebuilds nor even
with the internals of portage (not to speak of other package
managers).



I had thought of this option as well - I agree that it has a lot of
issues.  I agree that ebuild wouldn't be the right tool, but in the
right framework I could see how something like this might work.

Here is how a portage tree might be handled by a future package manager
that uses shebangs to implement any number of EAPIs that have almost no
restrictions on file contents other than the shebang:

When new ebuilds are synced into the repository, they are executed.
If the interpreter doesn't exist, then it is an unsupported EAPI and the
failure is silently ignored (or logged or whatever).  If the interpreter
does exist it will interpret the file properly - perhaps using a EAPI
command-line option from the shebang line or whatever is appropriate for
that EAPI which the interpreter obviously understands.  If the
interpreter determines that the file uses an EAPI it doesn't know, it
aborts execution and skips the package.  That makes the scheme always
backwards compatible (well, at least until the switch to this approach -
current package managers wouldn't be compatible).

When the new ebuild is executed, it will call appropriate functions to
register itself into the local repository.  That registration might
include callbacks of some kind or whatever - the whole way the ebuild
works could vary by EAPI - since the interpreter used by the EAPI could
change.  The only restriction for compatibility is a standard shebang
line.

Each ebuild would only be executed upon a change when it is synced, so
the overhead isn't huge.  At that point all the data is stored in a
local cache and the ebuilds themselves don't get touched until they are
installed.  Installation will work in an EAPI-dependent way - perhaps by
executing the ebuild with a particular parameter or environment setting
or whatever.  The package manager will know since it has already been
established that this is a supported EAPI by the fact that the ebuild
got processed when it was synced in.

This kind of system also makes it easy to support some scenarios that
are currently hard:

1.  Download a random ebuild off the internet and want to add it to your
repository?  Rather than having to put it in a local portage tree you
could just execute it from anywhere and it would register itself in its
present location - and act like any other package in the tree.

2.  No need for utilities like ebuild to manipulate the install process
- instead just execute the ebuild with the appropriate parameters or
whatever to get it to do the install process.

On the other hand, this is a big change from the present, and I'm not 
convinced that it will actually be a big improvement over some of the 
other EAPI ideas being floated around.  However, it is a 
potentially-neat idea...


--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Marius Mauch
On Wed, 11 Jun 2008 00:11:32 +0200
Bo Ørsted Andresen [EMAIL PROTECTED] wrote:

 On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote:
  Let's try to aim to do an EAPI=2 sometime soonish since Portage now
  has USE flag depends in version 2.2 which is looming on the
  horizon. It'd be nice to hit the ground running with supporting
  these. I know it'll be trivial for the Paludis and pkgcore guys to
  make this work since they already support USE flag depends.
 
 I would like the portage devs to comment upon which of the following
 features they think could easily be implemented before portage 2.2
 goes stable. There's still some time since it hasn't left
 package.mask yet, so I'd rather they exclude the features that will
 take too long to implement than anybody else doing that...

Well, actually I would rather not add any new features between pre8 and
rc1 to not further delay 2.2. And generally I'm also not in favor of
adding new features during the rc phase as it's there to eliminate
remaining bugs and for refinement of existing features, not to add new
unknowns.

 Already implemented:
 - Use dependencies, it's not clear to me whether we all agree
 entirely upon the syntax yet though (bugs #2272 and #174406)
 
 Things I believe should be trivial to implement:
 - Custom output names in SRC_URI, also called arrows (bug #177863)

This I'd definitely delay as it probably affects a number of things.

 - Guarantee trailing slashes (bug #174408)

Mostly a matter of finding the relevant spots, the actual work to
implement it would be trivial. Could be considered as bugfix.

 - Limit values in $USE (bug #176467)

Also requires little actual work, question is only if this should be
enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.
If it should be done for existing EAPIs as well could be considered as
bugfix.

 - doins support for symlinks (bug #179932)

If someone implements it it can be included (do you want an EAPI bump
for that?)

 - Enable FEATURES=test by default (bug #184812)

Only if 99% of the stable and ~arch tree and all potential system
packages build with it (IOW: no)

 - GLEP 42 - news items

Already implemented.

 Bigger features I'm interested in:
 - Making do* die on failure by default (without changing their
 behaviour for previous eapis). Possibly adding either nonfatal or
 try_do* for cases where this isn't desired. (bug #138792)
 - More phases
   - src_prepare, for applying patches and running autotools etc.
   - src_configure, for running configure scripts (bug #197859)
   - pkg_pretend (bug #177860 - could also be used to fix bug #75936)
   - maint_*, it's not clear to me if this has been fleshed out in
 sufficient detail yet (bug #185567)

Unlikely for 2.2.

 - default_*, allows an ebuild to redefine phases to add more
 functionality and then call default_$phase. Currently the default
 phases are lost when redefining the phases.

Should be trivial to implement off-hand (just converting the existing
defaults to wrappers)

 - default for src_install (bug #33544)

Should also not be terribly difficult, though I'd rather wait until
after 2.2 final.

 - Ranged dependencies (bug #4315)

Unlikely for 2.2.

 Of course I'd like GLEPs 54 and 55 too but since the council still
 hasn't made a decision about them I'll leave them out..

Well, I already said everything about those during the first discussion
round and the relevant council meeting.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Richard Freeman wrote:
 On the other hand, this is a big change from the present, and I'm not 
 convinced that it will actually be a big improvement over some of the 
 other EAPI ideas being floated around.  However, it is a 
 potentially-neat idea...

Rich, interesting thoughts!  But yeah, I agree that for now that is a lot.

My idea for the #! thing was much smaller-scale and is a way to add simple
syntax to allow declaration of the EAPI in the file with no sourcing and no
filename extension mangling (plus, no pre-source/post-source issues):

Just have one shebang-like line in the header before any real bash code
(#!EAPI=3, #EAPI=3, or whatever is agreed-upon).  This is out-of-band meta
info, so it's OK that it's in a comment.  It's ignored by bash, but it can be
read trivially without sourcing.  To accelerate things for the tree (I've seen
others mention this idea too), store the EAPI in the portage cache when it is
generated.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Thomas de Grenier de Latour
On 2008/06/10, Ciaran McCreesh [EMAIL PROTECTED] wrote:

 Currently we don't touch the ebuild's content *at all* for metadata
 operations, except where there's no or stale metadata cache (which is
 rare). We can get away with this currently because 0 and 1 have
 identical cache layouts and PMS has some (necessary) weasel wording;
 future EAPIs likely won't, so we're back to the chicken / egg problem.
 
 So... We either have the EAPI from the extension (which we already
 have, since we have to read the dir to know what versions are
 available), in which case we know how to read the metadata cache file.
 Or we have to open up a file that would otherwise not be opened, just
 to parse one line so we know how to read the cache file.

Or you apply to future EAPI's cache formats one of the solutions that
have been proposed for the ebuild side of the very same chicken / egg
problem: for instance, you could use $EAPI as cache filename extension. 

And that's it, you can get EAPI from the cache, hence no more extra
reading of ebuild files, and no more perfs issues.

It sounds so simple, am I missing something obvious?

-- 
TGL.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Bo Ørsted Andresen
On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
  I would like the portage devs to comment upon which of the following
  features they think could easily be implemented before portage 2.2
  goes stable. There's still some time since it hasn't left
  package.mask yet, so I'd rather they exclude the features that will
  take too long to implement than anybody else doing that...

 Well, actually I would rather not add any new features between pre8 and
 rc1 to not further delay 2.2. And generally I'm also not in favor of
 adding new features during the rc phase as it's there to eliminate
 remaining bugs and for refinement of existing features, not to add new
 unknowns.

Ok.

  Things I believe should be trivial to implement:
  - Custom output names in SRC_URI, also called arrows (bug #177863)

 This I'd definitely delay as it probably affects a number of things.

Such as?

  - Limit values in $USE (bug #176467)

 Also requires little actual work, question is only if this should be
 enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.
 If it should be done for existing EAPIs as well could be considered as
 bugfix.

  - doins support for symlinks (bug #179932)

 If someone implements it it can be included (do you want an EAPI bump
 for that?)

Listed those here because they block the EAPI tracker bug.

  - Enable FEATURES=test by default (bug #184812)

 Only if 99% of the stable and ~arch tree and all potential system
 packages build with it (IOW: no)

Err.. Maybe this could have been phrased better but then I did expect you 
would look at the bug before commenting. The idea is to enable tests by 
default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and 
1. This way devs who want to use EAPI 2 will either have to fix their tests 
or RESTRICT them. Doing it this way avoids the issue of having to fix the 
whole tree all at once. Users can still choose not to go with the default.

  - GLEP 42 - news items

 Already implemented.

And not really an EAPI issue. Hence I shouldn't have mentioned it here. ;)

  - default_*, allows an ebuild to redefine phases to add more
  functionality and then call default_$phase. Currently the default
  phases are lost when redefining the phases.

 Should be trivial to implement off-hand (just converting the existing
 defaults to wrappers)

So that's a candidate for EAPI 2.

  - default for src_install (bug #33544)

 Should also not be terribly difficult, though I'd rather wait until
 after 2.2 final.

-- 
Bo Andresen
Gentoo KDE Dev


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Brian Harring
On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote:
 On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED] wrote:
  At this point, we should really only discuss features that all 3 package
  managers have implemented.
 
 I'm not sure that's a good idea, only two have implemented EAPI 1 so far.

3 have.  If you're aware of a pkgcore issue, then kindly file a bug 
rather then going for mocking on -dev.

Cheers.
~harring


pgpqqaXG5exBg.pgp
Description: PGP signature


Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Brian Harring
On Wed, Jun 11, 2008 at 01:42:34AM +0200, Bo ??rsted Andresen wrote:
 On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
   Things I believe should be trivial to implement:
   - Custom output names in SRC_URI, also called arrows (bug #177863)
 
  This I'd definitely delay as it probably affects a number of things.
 
 Such as?

mirror-dist, aka the GENTOO_MIRROR infrastructure.


   - Limit values in $USE (bug #176467)
 
  Also requires little actual work, question is only if this should be
  enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.

eapi2 only imo, further, seems daft to limit $USE namespace while 
forcing all USE_EXPAND targets in.

Basically, IUSE should be extended to mark/state what USE_EXPAND 
namespaces it cares about- for ARCH (and friends), I'd expect they're 
pushed in regardless of IUSE.


   - Enable FEATURES=test by default (bug #184812)
 
  Only if 99% of the stable and ~arch tree and all potential system
  packages build with it (IOW: no)
 
 Err.. Maybe this could have been phrased better but then I did expect you 
 would look at the bug before commenting. The idea is to enable tests by 
 default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and 
 1. This way devs who want to use EAPI 2 will either have to fix their tests 
 or RESTRICT them. Doing it this way avoids the issue of having to fix the 
 whole tree all at once. Users can still choose not to go with the default.

This shouldn't be forced through by PM's, this should be forced 
through by communal dev agreement; I'd suggest getting that before 
trying to slide it into an eapi.

I'd prefer tests on, but I'm not convinced eapi level is the right 
area- realistically, that seems repo specifics (due to repo quality 
varying).  Either way, discussion is needed- I really doubt devs are 
going to be happy (let alone users if devs aren't careful) if they 
suddenly are forced to cleanup upstreams tests now, rather then as 
time permits.


   - default_*, allows an ebuild to redefine phases to add more
   functionality and then call default_$phase. Currently the default
   phases are lost when redefining the phases.
 
  Should be trivial to implement off-hand (just converting the existing
  defaults to wrappers)
 
 So that's a candidate for EAPI 2.

base_* please, rather then default; precedent is already there via 
base.eclass.  Not a hard req however, just a suggestion.

~harring


pgpqjkozdm18K.pgp
Description: PGP signature


[gentoo-dev] Re: GLEP 55

2008-06-10 Thread Duncan
Bernd Steinhauser [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on  Tue, 10 Jun
2008 05:46:47 +0200:

 No, not really. If you have .txt, .txt-2, .text or .footext in a dir,
 you would still realize, that those should be text files.

The first three, yes, by long tradition, footext, not necessarily, as 
it's too ambiguous.  Just like the penisland dot com domain, which is 
read as pen-island and sells pens, BTW (at least last time I looked, 
after it came up as an example in a discussion similar to this), is that 
foo-text or foot-ext (the way I would read it by default) or foote-XT 
or...?

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] extending existing EAPI semantics

2008-06-10 Thread Brian Harring
Bit curious what folks opinions are re: conversion of eapi 
requirements into a function, instead of a var.  Essentially, 
currently-


#my ebuild.
EAPI=1
inherit blah
DEPEND=monkey

funcs_and_such(){:;}



pros:
* simple, and was enough to get EAPI off the ground w/out massive 
fighting (at least not WW3 level fighting)
* works fine for metadata key level changes, function changes, etc.  
I'm aware folks have stated if DEPENDS changes, it won't be able to 
handle it- they're frankly wrong, they're confusing that post 
sourcing EAPI is checked, *then* if EAPI is supported the metadata is 
handled, else the manager is signaled that an unknown eapi was 
encountered (essentially).  Continuing...

cons:
* EAPI var must be set effectively before any invocations occur.
* global scope invocations (inherit) must be eapi aware;
* future additions to global scope invocations (say elib) will result 
in an error spat by bash (elib wasn't found).
* bash specific (which personally is fine to me, an ebuild is bash).
* doesn't address versioning changes.

Converting it into


#my ebuild.
eapi 1
inherit blah
DEPEND=monkey

funcs_and_such(){:;}



with eapi effectively being

eapi() {
 if [ $1 == 1 ] || [ $1 == 0 ];
   return # we know this eapi, can handle it
 fi
 die unsupported eapi $1
}

pros:
* same benefits as preexisting var approach.
* via conversion to invocation instead of var setting (which is 
untrappable), it's possible to bail the rest of the sourcing, thus 
preventing any error msgs for unknown global invocations (elib fex).
* easy to shoehorn in for any profile.bashrc compliant manager 
(portage/pkgcore); realize paludis is left out here (via it 
intentionally being left out of PMS atm by ciaran), but 
profile.bashrc *is* used by ebuild devs, thus it's a viable course (I 
don't see profile.bashrc ever going away basically).

cons:
* must be the first invocation.
* bash specific (again, ebuild is bash, new format can do things 
w/out having to worry about backwards compatibility).
* doesn't address versioning changes.


Basically, the proposal is an minor tweak of existing support- it has 
the benefit of avoiding the filename complaints from folks and 
addressing the usual global scope invocation will breakzor in later 
versions complaint from paludis folk.

It doesn't particularly provide for people shoving new versioning 
components in, but frankly that's fine due to the mess having 
versioning rules bound to EAPI would entail.

After comments from folks, although if a responder is going to state 
filename is better! skip it please, I already pointed out the diffs 
(meaning bluntly, kindly skip repeating what has already been said).

Cheers
~harring


pgpsalJ0dB2AH.pgp
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Wed, 11 Jun 2008 01:36:01 +0200
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:
 Or you apply to future EAPI's cache formats one of the solutions that
 have been proposed for the ebuild side of the very same chicken / egg
 problem: for instance, you could use $EAPI as cache filename
 extension. 
 
 And that's it, you can get EAPI from the cache, hence no more extra
 reading of ebuild files, and no more perfs issues.
 
 It sounds so simple, am I missing something obvious?

You're missing the cases where the cache isn't usable.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 19:14:11 +0200
Olivier Galibert [EMAIL PROTECTED] wrote:
 On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
  Except that currently, the ebuild file isn't opened for read. So
  it's not in memory at all.
 
 Why would you need the EAPI before the time when you actually want to
 interpret the contents?   

You need the EAPI before you use the metadata. But you don't need the
ebuild to get the metadata in the common case.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] GLEP 55 - The Long Thread

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 15:43:55 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:
  The use cases are stated rather clearly in the GLEP, which you
  clearly didn't bother to read...

 Concrete use cases instead of idealistic ones...

What, new global scope functions is insufficiently concrete?

New global scope functions to replace versionator with something on the
package manager side.

New global scope functions to allow per-cat/pkg eclasses.

Take your pick.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] extending existing EAPI semantics

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 19:56:23 -0700
Brian Harring [EMAIL PROTECTED] wrote:
 * easy to shoehorn in for any profile.bashrc compliant manager 
 (portage/pkgcore); realize paludis is left out here (via it 
 intentionally being left out of PMS atm by ciaran), but 
 profile.bashrc *is* used by ebuild devs, thus it's a viable course (I 
 don't see profile.bashrc ever going away basically).

If profile.bashrc is to be kept, it means massively reducing what can
be done in there.

 * doesn't address versioning changes.

Or indeed any change where the ebuild can't be visible to older package
managers without breaking them.

So basically it's not a solution at all.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] extending existing EAPI semantics

2008-06-10 Thread Brian Harring
On Wed, Jun 11, 2008 at 04:20:04AM +0100, Ciaran McCreesh wrote:
 On Tue, 10 Jun 2008 19:56:23 -0700
 Brian Harring [EMAIL PROTECTED] wrote:
  * easy to shoehorn in for any profile.bashrc compliant manager 
  (portage/pkgcore); realize paludis is left out here (via it 
  intentionally being left out of PMS atm by ciaran), but 
  profile.bashrc *is* used by ebuild devs, thus it's a viable course (I 
  don't see profile.bashrc ever going away basically).
 
 If profile.bashrc is to be kept, it means massively reducing what can
 be done in there.

Restraint in use of profile.bashrc is a per community QA measure, not 
a format restriction- think through the other this is better for QA 
things I've suggested PMS wise, you've responded in the same manner.


  * doesn't address versioning changes.
 
 Or indeed any change where the ebuild can't be visible to older package
 managers without breaking them.
 
 So basically it's not a solution at all.

Name a scenario.

Note, if the scenario is pm doesn't support eapi function, and 
doesn't support profile.bashrc, skip it, you're repeating what I 
already laid out (which results in visible bash complaints, but the 
manager still labeling the eapi inoperable).
~harring


pgp7ybFpcdLqq.pgp
Description: PGP signature


Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Brian Harring
On Tue, Jun 10, 2008 at 12:26:55PM -0400, Doug Goldstein wrote:
 Let's try to aim to do an EAPI=2 sometime soonish since Portage now has 
 USE flag depends in version 2.2 which is looming on the horizon. It'd be 
 nice to hit the ground running with supporting these. I know it'll be 
 trivial for the Paludis and pkgcore guys to make this work since they 
 already support USE flag depends.

The relevant bugs that should go into eapi2-

bug 211529 (econf == configure --disable-dependency-tracking 
  --enable-fast-install)
bug 205557 (export var/api indicating what sort of op this is- 
  replace, install, uninstall, for pkg_*)
bug 203891: STRIP_MASK; this would allow ebuilds to be fully unaware 
  of the strip implementation, although would require the var to be 
  in binpkg metadata (pkgcore specific request, since we allow 
  stripping of unstripped binpkgs)
bug 199722: use/useq; nail it down to one or the other imo.

Not bugged, but potentials for minor cleanup:
* drop AA (basically unused)
* drop RDEPEND=${RDEPEND-${DEPEND}}, unless there is a strong arg to 
  keep it (I recall a historical strong arg to punt it)
* identify any remaining portageq additions needed to allow 
  /var/db/pkg to change format

From the proposed way back when but never got off the ground:
* USE mutually exclusive representation; fancy way of moving code like
 use foon  use !blah  die blah must be enabled if foon is enabled
 into a form that can be detected up front, instead of going 'boom' at 
 pkg_setup time.  This was originally proposed to address USE 
 configurations states for php pkgs, quick look, it still could be 
 useful.  Would be implemented via a new metadata key most likely.


Finally; it needs updating, but glep33 
(http://glep.gentoo.org/glep-0033.html) I'd be interested in trying to 
get into eapi2.  Currently, all managers support some form of env 
saving/restoration that the glep required, so that dependency is gone.  

What remains is basically updating the glep (I can do so), council 
agreement (presume non issue), and implementation- easy for pkgcore, 
presumably easy enough for paludis, easy for portage (already asked 
zac).

If glep33 went in, I'd suggest bug 197859: split 
src_configure/src_compile .  Without g33, holding off on 
src_configure/src_compile would likely be wise since it introduces 
some potentially nasty eapi related issues in eclasses.

Comments welcome.
~harring



pgpNQ16S5rI9j.pgp
Description: PGP signature


Re: [gentoo-dev] extending existing EAPI semantics

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 20:33:11 -0700
Brian Harring [EMAIL PROTECTED] wrote:
  If profile.bashrc is to be kept, it means massively reducing what
  can be done in there.
 
 Restraint in use of profile.bashrc is a per community QA measure, not 
 a format restriction- think through the other this is better for QA 
 things I've suggested PMS wise, you've responded in the same manner.

Except that if profile.bashrc can tinker with package manager
internals, it has to be done in such a way that it works with all
package managers. So it has to be either Portage-specific or extremely
constrained.

   * doesn't address versioning changes.
  
  Or indeed any change where the ebuild can't be visible to older
  package managers without breaking them.
  
  So basically it's not a solution at all.
 
 Name a scenario.

You already named one, and tried to gloss it over as not being the
complete showstopper that it is.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] extending existing EAPI semantics

2008-06-10 Thread Brian Harring
On Wed, Jun 11, 2008 at 04:38:01AM +0100, Ciaran McCreesh wrote:
 On Tue, 10 Jun 2008 20:33:11 -0700
 Brian Harring [EMAIL PROTECTED] wrote:
* doesn't address versioning changes.
   
   Or indeed any change where the ebuild can't be visible to older
   package managers without breaking them.
   
   So basically it's not a solution at all.
  
  Name a scenario.
 
 You already named one, and tried to gloss it over as not being the
 complete showstopper that it is.

Not exactly a show stopper; unknown versions are by and large 
ignored due to paludis devs forcing it upon others.  Ironic, that one.

You're also ignoring is that unlike the .ebuild-$EAPI approach, 
this minor refinement leaves open options for replacement, and that 
this option actually is likely far more agreeable then the filename 
approach you've been trying to force since EAPI's inception (which 
thus far hasn't taken hold despite positively massive noise from you).

One thing I'll note is that the .ebuild-$EAPI approach isn't the end 
all fix to versioning extensions that y'all represent it as.  
Essentially, what .ebuild-$EAPI allows is additions to version 
comparison rules, no subtractions.  Each new $EAPI *must* be a 
superset of previous $EAPIs.

An example would be removal of float comparison rules; for =eapi-1, 
.006  .6;  Now if eapi-2 stated .006 == .6, that literally means that 
the PM would have to maintain versioning rules per eapi level, meaning 
that for an eapi1 ebuild, what it would match would differ from eapi2.  
Aside from that being a cluster-fuck in the implementation, it's a 
cluster-fuck for the dev trying to visualize what the manager is 
actually up to.

Personally, that's a pretty nasty unstated gotcha.  .ebuild-$EAPI 
isn't the end all essentially, it has flaws just the same as other 
solutions.

Marius/genone has advocated it in the past, and frankly I tend to 
agree at this point- versioning rules are a repo level property by and 
large, and the appropriate place to control that is at the repo level.

So... someone other then ciaran have a comment?  We already know 
ciarans views (hard not to when he has 2x greater posting ratio then 
any other person)...

~harring


pgpQNmeUPmHge.pgp
Description: PGP signature


Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Arun Raghavan
On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
[...]
 Why would you need the EAPI before the time when you actually want to
 interpret the contents?

 You need the EAPI before you use the metadata. But you don't need the
 ebuild to get the metadata in the common case.

Does the cache format _really_ need to be extensible the extent that
we're jumping hoops to support arbitrary cache formats?
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Luca Barbato

Bo Ørsted Andresen wrote:

- Enable FEATURES=test by default (bug #184812)

Only if 99% of the stable and ~arch tree and all potential system
packages build with it (IOW: no)


Err.. Maybe this could have been phrased better but then I did expect you 
would look at the bug before commenting.


The bug itself should be phrased better.

The idea is to enable tests by 
default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and 
1. This way devs who want to use EAPI 2 will either have to fix their tests 
or RESTRICT them. Doing it this way avoids the issue of having to fix the 
whole tree all at once. Users can still choose not to go with the default.


People will (and should) have -test in FEATURES anyway, good self-test 
suites usually take more than twice the time to build and run, may have 
additional dependencies that could take lots of time.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] extending existing EAPI semantics

2008-06-10 Thread Mike Kelly

Brian Harring wrote:
One thing I'll note is that the .ebuild-$EAPI approach isn't the end 
all fix to versioning extensions that y'all represent it as.  
Essentially, what .ebuild-$EAPI allows is additions to version 
comparison rules, no subtractions.  Each new $EAPI *must* be a 
superset of previous $EAPIs.


Uhh... no. Just like how older package managers which don't understand 
how to read the EAPI from a filename suffix would basically ignore the 
new ebuilds, any package manager that can, but doesn't recognize the 
eapi of the new one, will just ignore it. It won't ever try to figure 
out its version or anything, it'll just do nothing.


Also, there is absolutely no reason for all future EAPIs to be a 
superset of old eapis. While paludis (and presumably pkgcore and 
portage, I'm not as familiar with their code) has implemented EAPI=1 as 
a few additions to EAPI=0, there is no reason that gentoo might not 
decide to have EAPI=9000 some day, complete with artificial intelligence 
that completely obsoletes USE flags, or some such thing (it's late, I 
know the analogy sucks).



--
Mike Kelly
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Ciaran McCreesh
On Wed, 11 Jun 2008 09:52:17 +0530
Arun Raghavan [EMAIL PROTECTED] wrote:
 On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh
 [EMAIL PROTECTED] wrote:
 [...]
  Why would you need the EAPI before the time when you actually want
  to interpret the contents?
 
  You need the EAPI before you use the metadata. But you don't need
  the ebuild to get the metadata in the common case.
 
 Does the cache format _really_ need to be extensible the extent that
 we're jumping hoops to support arbitrary cache formats?

The cache format needs to be able to have keys added and removed from
it.

But the cache format is largely irrelevant here. There aren't any
non-trivial EAPI related problems introduced by cache that don't already
exist without cache.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] extending existing EAPI semantics

2008-06-10 Thread Luca Barbato

Mike Kelly wrote:

Brian Harring wrote:
One thing I'll note is that the .ebuild-$EAPI approach isn't the end 
all fix to versioning extensions that y'all represent it as.  
Essentially, what .ebuild-$EAPI allows is additions to version 
comparison rules, no subtractions.  Each new $EAPI *must* be a 
superset of previous $EAPIs.


Uhh... no. Just like how older package managers which don't understand 
how to read the EAPI from a filename suffix would basically ignore the 
new ebuilds, any package manager that can, but doesn't recognize the 
eapi of the new one, will just ignore it. It won't ever try to figure 
out its version or anything, it'll just do nothing.


Also, there is absolutely no reason for all future EAPIs to be a 
superset of old eapis. While paludis (and presumably pkgcore and 
portage, I'm not as familiar with their code) has implemented EAPI=1 as 
a few additions to EAPI=0, there is no reason that gentoo might not 
decide to have EAPI=9000 some day, complete with artificial intelligence 
that completely obsoletes USE flags, or some such thing (it's late, I 
know the analogy sucks).




Assuming we won't move from flat file to db

lu - thinking of a darker future.


--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



  1   2   >