On Wed, 11 Jun 2008 08:50:47 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> > And saving your ass when you're using a broken compiler that
> > generates broken code that would force you to reinstall a working
> > compiler by hand when the package manager gets h0rked.
>
> You (upstream) are suppos
Ciaran McCreesh wrote:
You assume that users have working, properly configured compilers. It's
fairly well established that a lot of them don't, particularly on
Gentoo.
"if your code sucks isn't our fault." - gcc upstream
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://de
Ciaran McCreesh wrote:
Sure it will. They won't be able to install their package without
either passing src_test or restricting it.
Developers *do* try to install things before committing, right?
No, they also write the ebuilds using cat /dev/urandom through a perl
regexp.
But more importa
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 07:53:21 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
A whole bunch of science packages have upstreams that say "If you're
building from source, run 'make check' and if it fails don't carry
on".
Their rationale behind that is that their code is severe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Kelly wrote:
| Wrong.
Thanks for that. I'm gonna assume you meant "I think you're wrong".
| Sure, because of how the algorithm works, people could potentially do
| both, but the GLEP makes it pretty clear that they shouldn't.
It doesn't just
On Wed, 11 Jun 2008 08:31:45 +0200
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> > You're missing the cases where the cache isn't usable.
>
> I was not talking about generating cache entries, and neither were
> you. I've replie
On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> You're missing the cases where the cache isn't usable.
>
I was not talking about generating cache entries, and neither were you.
I've replied to you because you were suggesting that the "EAPI in
ebuilds contents" solution had extra cost
On Wed, 11 Jun 2008 08:02:48 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> > Had you bothered to write even trivial test suites for EAPI 1,
> > you'd've found at least one major bug straight away.
>
> http://www.pkgcore.org/trac/pkgcore/newticket
http://www.pkgcore.org/trac/pkgcore/ticket/197
On Wed, 11 Jun 2008 08:01:30 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 07:49:44 +0200
> > Alexis Ballier <[EMAIL PROTECTED]> wrote:
> >> I thought tests were already supposed to pass whatever the EAPI is
> >> and devs were supposed to run them...
Ciaran McCreesh wrote:
On Tue, 10 Jun 2008 17:11:23 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
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
On Wed, 11 Jun 2008 07:58:44 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Oh, so Gentoo has decided that basic QA is another 'poor programming
> > practice' now?
>
> Having a good testsuite is part of the QA, having it not failing is
> part of the QA, running it for s
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 07:49:44 +0200
Alexis Ballier <[EMAIL PROTECTED]> wrote:
I thought tests were already supposed to pass whatever the EAPI is and
devs were supposed to run them...
Supposedly. But in practice this isn't true, because far too many
developers just don't c
On Wed, 11 Jun 2008 07:53:21 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> > A whole bunch of science packages have upstreams that say "If you're
> > building from source, run 'make check' and if it fails don't carry
> > on".
>
> Their rationale behind that is that their code is severely broken,
Ciaran McCreesh wrote:
Oh, so Gentoo has decided that basic QA is another 'poor programming
practice' now?
Having a good testsuite is part of the QA, having it not failing is part
of the QA, running it for supposedly tested code (thus having those test
passed already) every time isn't.
Peop
On Tue, 10 Jun 2008 17:11:23 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> 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
> > >
On Wed, 11 Jun 2008 07:49:44 +0200
Alexis Ballier <[EMAIL PROTECTED]> wrote:
> I thought tests were already supposed to pass whatever the EAPI is and
> devs were supposed to run them...
Supposedly. But in practice this isn't true, because far too many
developers just don't care.
The whole mess st
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 07:39:53 +0200
Rémi Cardona <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh a écrit :
So how are we supposed to handle packages where upstream *require*
that anyone building from source runs 'make check'?
If it's required to get the final binaries, then it
On Wed, 11 Jun 2008 07:48:06 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 06:24:18 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> People will (and should) have -test in FEATURES anyway, good
> >> self-test suites usually take more than twice
On Wed, 11 Jun 2008 07:46:39 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Tue, 10 Jun 2008 22:33:41 -0700
> > Brian Harring <[EMAIL PROTECTED]> wrote:
> >> Lay out how .006/.6 would work properly *per* eapi. As I clarified
> >> in my last email, the master would va
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 ha
On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <[EMAIL PROTECTED]> 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 bet
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 06:24:18 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
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.
Ciaran McCreesh wrote:
On Tue, 10 Jun 2008 22:33:41 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
Lay out how .006/.6 would work properly *per* eapi. As I clarified
in my last email, the master would vary dependant on the eapi- which
isn't valid unless you're retroactively overriding the vers
On Wed, 11 Jun 2008 07:39:53 +0200
Rémi Cardona <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh a écrit :
> > So how are we supposed to handle packages where upstream *require*
> > that anyone building from source runs 'make check'?
>
> If it's required to get the final binaries, then it should be in
Ciaran McCreesh a écrit :
So how are we supposed to handle packages where upstream *require* that
anyone building from source runs 'make check'?
If it's required to get the final binaries, then it should be in
src_compile.
I don't know any package that does require such a thing, but IMHO it
On Tue, 10 Jun 2008 22:33:41 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> Lay out how .006/.6 would work properly *per* eapi. As I clarified
> in my last email, the master would vary dependant on the eapi- which
> isn't valid unless you're retroactively overriding the versioning
> rules of a
Kindly respond to the rest of the email first of all...
On Wed, Jun 11, 2008 at 06:22:31AM +0100, Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 22:16:21 -0700
> Brian Harring <[EMAIL PROTECTED]> wrote:
> > > Also, there is absolutely no reason for all future EAPIs to be a
> > > superset of old eap
On Wed, 11 Jun 2008 06:19:16 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Tue, 10 Jun 2008 23:16:04 -0600
> Ryan Hill <[EMAIL PROTECTED]> wrote:
> > if people are just going to RESTRICT tests when they fail (and they
> > will, because it's a hell of a lot easier than actually fixing
> > t
On Tue, 10 Jun 2008 22:16:21 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> > Also, there is absolutely no reason for all future EAPIs to be a
> > superset of old eapis.
>
> .ebuild-$EAPI-n requires all *versioning rules* to be a superset of
> $EAPI=(n-1); if in doubt, re-read my example above
On Wed, 11 Jun 2008 06:24:18 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> 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.
So how are we suppos
On Tue, 10 Jun 2008 23:16:04 -0600
Ryan Hill <[EMAIL PROTECTED]> wrote:
> if people are just going to RESTRICT tests when they fail (and they
> will, because it's a hell of a lot easier than actually fixing them),
> what's the point of having a testsuite at all? and once a testsuite is
> restricted
On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote:
> 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
You actually pretty much completely misinterpreted what I was saying,
so inserting the example back into the email and trying again...
On Wed, Jun 11, 2008 at 12:25:55AM -0400, Mike Kelly wrote:
> Brian Harring wrote:
> >One thing I'll note is that the .ebuild-$EAPI approach isn't the end
> >all
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
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 bef
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 prev
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.
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
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
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 "th
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 f
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 bei
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 ebuil
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
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
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
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
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, footex
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 proba
On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <[EMAIL PROTECTED]> 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
"=?UTF-8?Q?Piotr_Jaroszy=C5=84ski?=" <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted
below, on Mon, 09 Jun 2008 22:13:20 +0200:
> What's the point of sourcing an ebuild that cannot be used anyway?
As currently seen in portage at least... a PM can be aware of and source
an EAPI it can't
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 i
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 th
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 PM
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 a
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 nic
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
opi
Mike Auty wrote:
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".
Wrong. From the GLEP: "note that one should *never* explicitly set both
EAPIs to different values."
Basically
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 dis
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 Palud
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 som
-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 fu
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 scr
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 nom
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 di
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 clearl
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
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 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 t
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 r
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?
OG.
--
gentoo-dev@lists.gentoo.org ma
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
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%
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.
# 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
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/1743
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 feat
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
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 su
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 f
-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
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 --
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 abou
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 us
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
w
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...
--
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 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
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 ebuil
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 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",
> > "
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
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 fil
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
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
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
Richard Freeman wrote:
> 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
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 subse
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
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.
1 - 100 of 142 matches
Mail list logo
