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
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
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
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
--
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
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
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
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
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
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
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
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�
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
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
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
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
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.
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
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
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
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
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,
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.
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
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
--
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
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
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
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 :
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
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
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
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 :
+
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
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.
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
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
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
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
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
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
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
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
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
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?
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.,
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
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
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
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
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
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...
--
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
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
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
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
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,
-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
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
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
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
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
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
# 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
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
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.
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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.
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.
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.
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
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
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
1 - 100 of 118 matches
Mail list logo
