[gentoo-dev] Re: Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-15 Thread Steve Long
Michael Haubenwallner wrote:
 Fabian Groffen wrote:
 Ciaran McCreesh wrote:
  Steve Long wrote:
   Unless someone can say what using PROPERTIES=prefix would break, I'd
   go with that. It's a /classic/ usage of that variable, as it's simply
   a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
   support it. It'd be great to see the prefix branch finally merged so
   we all get to play with it.
  
  It would break. Prefix ebuilds won't work unless ED is set, and a non
  PROPERTIES aware or non-prefix-property aware package manager won't set
  ED. Unless prefix is reimplemented to require no package manager
  changes for the install to / case, PROPERTIES is out.

Nonsense; we just need some bash changes to integrate it iff we want to
allow prefix ebuilds into the main tree; we're a while away from actually
being at the stage where that would be feasible, even if it were desired.
By the time we do get there, we should be able to fulfil your last
condition, given a sane bash implementation for the mangler in question.

TBH I'm not really worried about alternative manglers atm; they can catch up
w/e afaic. IIRC PROPERTIES are part of EAPI-2, so one would hope they've
already done that by now.

 
 Just to comment on this possibility; I see an option, given the
 definition of ED and EROOT to do Prefix without them, by e.g. using
 ${D}${EPREFIX} instead of ${ED} as shorthand.  When ${EPREFIX} would be
 unset, this would result in simple ${D}, which is backwards
 compatible.  This is not all what is necessary, but a big deal of it.
 
 Question here, however, is whether this is worth it.  Personally, I
 prefer the shorthands, as they give a lot of readability.

Yeah the shorthands are nice, agreed. Ideally we wouldn't need to change
anything in the ebuild though. (I appreciate we're a while away from there,
but if we can at least get the ones which go via emake and econf, that's a
start. We can worry about {scons,distutils,..} later; pro-audio have a nice
exteutils.eclass we can 'borrow' for a start ;)

From the prefix docs, the only place D should be retained over ED is in a
DESTDIR=$D (or ${D}) when configure --prefix=.. has been run. Is that
correct?
 
 Could it also work to initialize them in profile.bashrc if they are
 unset?
 
 Something like
 : ${EPREFIX=}
 : ${ED=${D}}
 : ${EROOT=${ROOT}}
 
That would work yeah, though I think it would be better if we just
integrated that into ebuild.sh. We can check PROPERTIES to see if prefix is
in there, and then enable additional logic, and eg use a different PATH for
external helpers (most of which we can do internally in any case.) I
realise the latter is happening already, but if we're integrating, it
should be happening in the mainline code when applicable, imo. (Not saying
that is the applicable case, just that we can change w/e you see fit.)





Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Fernando J. Pereda
On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote:
 Here you go (this is on an old machine, so you'll get much quicker times if
 you try this at home):

A big gain in the context of ebuilds and source packages. Well done.

- ferdy



pgprSLpWrpb0H.pgp
Description: PGP signature


[gentoo-dev] [RFC] some global useflags

2008-10-15 Thread Markus Meier
server16
logrotate 10
gsm   9
custom-cflags 9
kontact   8
openmp8
plasma7
html  7
demo  7
smp   6
icu   6
editor6
multislot 6
nautilus  6
audacious 6
tools 6
qt3support6
dxr3  6
music 5
smtp  5
fax   5
bsf   5
irc   5
mp4   5
clisp 5
nfs   5
pcsc-lite 5
zvbi  5
http  5
web   5


logrotate: Adds support for the app-admin/logrotate log rotation program

kontact: Enable support for the KDE personal information manager
(kde-base/kdepim*)

openmp: Build support for the OpenMP (support parallel computing),
requires =sys-devel/gcc-4.2 built with USE=openmp

plasma: Build optional plasma widgets that require kde-base/libplasma

smp: Enable support for multiprocessors or multicore systems

bsf: Enable support for Apache Bean Scripting Framework (dev-java/bsf)


what should we do about custom-cflags? should this be global like
Use CFLAGS from /etc/make.conf rather than the default package CFLAGS
(not supported)


Markus


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] some global useflags

2008-10-15 Thread Ciaran McCreesh
On Wed, 15 Oct 2008 18:36:32 +0200
Markus Meier [EMAIL PROTECTED] wrote:
 server16

Already been discussed, can't be done.

 logrotate 10

Already been discussed. Will no doubt descend into the same long
argument that happens every time this comes up.

 custom-cflags 9

Shouldn't be there at all.

 multislot 6

Utterly illegal, needs to die.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-15 Thread Santiago M. Mola
El mar, 14-10-2008 a las 18:24 -0700, Alec Warner escribió:
 On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty [EMAIL PROTECTED] wrote:
 
 
  There's no need to commit straight to stable. Just make two different
  new revisions for each EAPI. Then the arch teams can test it like usual.
 
 Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are
 there multiple versions of the same package' questions and
 complexities.
 

If you're thinking about having two equal versions with different EAPIs,
that's not allowed by GLEP 55:

Note that it is still not permitted to have more than one ebuild with
equal category, package name, and version. Although it would have the
advantage of allowing authors to provide backwards compatible ebuilds,
it would introduce problems too. The first is the requirement to have
strict EAPI ordering, the second is ensuring that all the ebuilds for a
single category/package-version are equivalent, i.e. installing any of
them has exactly the same effect on a given system.

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread David Leverton
On Wednesday 15 October 2008 10:33:22 Steve Long wrote:
 Here you go (this is on an old machine, so you'll get much quicker times if
 you try this at home):
 [EMAIL PROTECTED] ~]$ echo $(run)
 #!/bin/bash
 P='some-crap/god-i-hate-asshats'

I do hope that that isn't directed at anyone in particular.

 for ((i=0;i10;i++)); do echo /usr/share/doc/${P}/examples  /dev/null;

 real 11.25

 real 9.24

So that's what, on the order of 20 microseconds faster for each iteration?

This is a purely stylistic issue, same as the braces with variable expansions.  
You're free to write your own code however you like, but harassing other 
people to do things your favourite way with no practical benefit is just 
going to annoy everyone. 



[gentoo-dev] Re: Re: bzr.eclass into Portage

2008-10-15 Thread Steve Long
Bo Ørsted Andresen wrote:

 On Monday 13 October 2008 04:43:48 Steve Long wrote:
 EBZR_OPTIONS=${EBZR_OPTIONS:-} (and similar variants)
 doesn't do anything (beyond waste lex and yacc time.)
 
 It gets listed in the generated man page.

From what I remember of the awk that generates those manpages, this:
 
# @ECLASS-VARIABLE: EBZR_OPTIONS
# @DESCRIPTION:
# The options passed to the fetch and update commands.

..does that.

 The same consideration applies to all those constant values 'and
 indeed' ${foo} as opposed to $foo, though first time I raised that I got
 sworn at, so not expecting miracles here.
 
 Are you for real?
 
Perhaps you missed the discussion about EAPI in filenames?





[gentoo-dev] Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-15 Thread Steve Long
Alec Warner wrote:
 Petteri Räty wrote:
 There's no need to commit straight to stable. Just make two different
 new revisions for each EAPI. Then the arch teams can test it like usual.
 
 Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are
 there multiple versions of the same package' questions and
 complexities.

Hmm AFAICT there isn't any need to do put it in the filename, as the package
manager will simply ignore an EAPI (which comes from the rsync'ed cache for
the Gentoo tree) it doesn't know. Additionally all the manglers deal with
EAPI 0-2 fine afaik. If it's solely about the different rev ids, I think
it's a bit of a red herring; anyone confused could simply be told this is
a security fix if they cared to ask (or look in the Changelog) and these
aren't exactly going to be all over the tree. Could be masked for
arch-testing [security fix] and then the relevant fixed older version put
into the tree, as now.

Personally I'd rather remove the restriction and allow ebuilds to work with
more than one EAPI, as explicitly declared, instead of having to write two
revisions. One could then also inherit from a security eclass to make it
clear to anyone reading the ebuild what was happening (which would also
work for two different revs with variant EAPIs ofc.)

Whatever, I don't think this use-case is anywhere near enough to justify the
massive intrusion that GLEP55 is. The versioning thing brought up before is
best done via debian-style epochs, if anyone really wants to fix that.





[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Steve Long
Jan Kundrát wrote:
 Steve Long wrote:
 insinto /usr/share/doc/${P}/examples
 Is there any chance we can start using correctly quoted filenames across
 the board?
 
 Since when is ${P} allowed to have spaces?

I believe I answered this in my prior post.
 
 Besides being faster (quote the whole thing)
 
 Have you done a benchmark certifying that /usr/share/doc/${P}/examples
 is faster than /usr/share/doc/${P}/examples?

Here you go (this is on an old machine, so you'll get much quicker times if
you try this at home):
[EMAIL PROTECTED] ~]$ echo $(run)
#!/bin/bash
P='some-crap/god-i-hate-asshats'
for ((i=0;i10;i++)); do echo /usr/share/doc/${P}/examples  /dev/null;
done
[EMAIL PROTECTED] ~]$ echo $(run2)
#!/bin/bash
P='some-crap/god-i-hate-asshats'
for ((i=0;i10;i++)); do echo /usr/share/doc/$P/examples  /dev/null;
done

[EMAIL PROTECTED] ~]$ for ((l=0;l5;l++)); do time -p ./run; done
real 11.25
user 9.96
sys 1.13
real 11.12
user 9.82
sys 1.16
real 10.99
user 9.70
sys 1.15
real 11.25
user 10.02
sys 1.07
real 11.36
user 10.06
sys 1.16

[EMAIL PROTECTED] ~]$ for ((l=0;l5;l++)); do time -p ./run2; done
real 9.24
user 8.00
sys 1.11
real 9.22
user 8.02
sys 1.08
real 9.08
user 7.90
sys 1.06
real 9.23
user 7.96
sys 1.15
real 9.18
user 7.98
sys 1.09

 more useful error messages in the case of a dev/user slip-up
 
 Could you elaborate?

File not found foo/bar bar/ as opposed to two separate lines; for elib
functions, one would expect there to be an error handler which would be
wrapping that, per-parameter.
 
 They also highlight better in a capable editor.[1]
 
 Please elaborate.
 
I did.





[gentoo-dev] Re: System packages in (R)DEPEND?

2008-10-15 Thread Steve Long
Peter Volkov wrote:
 Jeremy Olexa ?:
 Thomas Sachau wrote:
  Should we depend on all system packages? Should we depend on some
  packages, because they could be removed? If yes, which ones? Or should
  we leave the system packages out completly?

 https://bugs.gentoo.org/show_bug.cgi?id=221311
 
 Please provide reasons/justifications for the proposal of removing
 
 Our documentation, QA team insist that we should not depend on system
 packages and there are good reasons to do that. But still above bug
 clearly states different. Also if we consider perl and some other
 packages, they also could became target to be removed... But I'm not
 going to repeat discussion we already had recently:
 http://thread.gmane.org/gmane.linux.gentoo.devel/54035
 
 So yes, there is ambiguity and the question is valid. But since we had
 discussion recently I don't see what else we can discuss now.
 
Well according to [1] it should all be done in the profiles, and [2] seems
like a good way to accomplish a more effective split. Is there anything
which means portage can't simply move ahead with that?


[1] http://article.gmane.org/gmane.linux.gentoo.devel/54146
[2] http://article.gmane.org/gmane.linux.gentoo.portage.devel/2575





[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Steve Long
Fernando J. Pereda wrote:

 On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote:
 Here you go (this is on an old machine, so you'll get much quicker times
 if you try this at home):
 
 A big gain in the context of ebuilds and source packages. Well done.
 
Yes, almost as important as not sourcing any ebuilds, so let's all stick an
EAPI extension on the end of the filename.





Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Ciaran McCreesh
On Wed, 15 Oct 2008 20:28:43 +0100
Steve Long [EMAIL PROTECTED] wrote:
 Fernando J. Pereda wrote:
  On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote:
  Here you go (this is on an old machine, so you'll get much quicker
  times if you try this at home):
  
  A big gain in the context of ebuilds and source packages. Well done.
  
 Yes, almost as important as not sourcing any ebuilds, so let's all
 stick an EAPI extension on the end of the filename.

If you really think that EAPI as an extension has anything to do with
performance, you are even more sadly mistaken than usual, and I
suggest you lay off the GLEP 55 bashing until you've bothered to read
it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Steve Long
David Leverton wrote:

 On Wednesday 15 October 2008 10:33:22 Steve Long wrote:
 Here you go (this is on an old machine, so you'll get much quicker times
 if you try this at home):
 [EMAIL PROTECTED] ~]$ echo $(run)
 #!/bin/bash
 P='some-crap/god-i-hate-asshats'
 
 I do hope that that isn't directed at anyone in particular.

No, but thanks for drawing attention to it.
 
 for ((i=0;i10;i++)); do echo /usr/share/doc/${P}/examples 
 /dev/null;
 
 real 11.25
 
 real 9.24
 
 So that's what, on the order of 20 microseconds faster for each iteration?

Or ~18%. (You shouldn't use the first iteration in general, btw.)
 
 This is a purely stylistic issue, same as the braces with variable
 expansions.
See my other posts.

 You're free to write your own code however you like, but 
 harassing other people to do things your favourite way with no practical
 benefit is just going to annoy everyone.

I'm sorry you feel harrassed by my talking about the basics of
shell-scripting, it wasn't intended like that. Though, given your tone, I
don't think you are feeling harrassed; perhaps you're just feeling
defensive about your trap boo-boo? Whatever, leaving aside the amateur
dramatics, it was more to show how to do the benchmarking than anything
else; I'd have simply said yes but that reminded me too much of behaviour
I have criticised in the past.

For the record, I'm sorry if my choice of package name caused any offence to
anyone else. It was a quick thing I knocked off, cp'ed and pasted; at most
I thought it would be taken as a joke when I wrote it, then I didn't check
it through in the correct frame of mind (I have flu and was tired, so just
wanted to send the thing and didn't check the script itself) when I sent
it, and for that I apologise to everyone reading.





[gentoo-dev] Re: [RFC] some global useflags

2008-10-15 Thread Steve Long
Ciaran McCreesh wrote:

 On Wed, 15 Oct 2008 18:36:32 +0200
 Markus Meier [EMAIL PROTECTED] wrote:
 server16
 
 Already been discussed, can't be done.

What does it break?





Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Ciaran McCreesh
On Wed, 15 Oct 2008 20:51:32 +0100
Steve Long [EMAIL PROTECTED] wrote:
  So that's what, on the order of 20 microseconds faster for each
  iteration?
 
 Or ~18%. (You shouldn't use the first iteration in general, btw.)

18% of nothing is nothing.

 perhaps you're just feeling defensive about your trap boo-boo?

Those of us who have tried trap have fairly conclusive proof it won't
work. Perhaps you'd like to show how wrong we are and provide a working
demonstration.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] some global useflags

2008-10-15 Thread Ciaran McCreesh
On Wed, 15 Oct 2008 20:53:14 +0100
Steve Long [EMAIL PROTECTED] wrote:
 Ciaran McCreesh wrote:
  On Wed, 15 Oct 2008 18:36:32 +0200
  Markus Meier [EMAIL PROTECTED] wrote:
  server16
  
  Already been discussed, can't be done.
 
 What does it break?

Have a look at, for example, [1], where Mike already gave you an
answer one of the previous times we discussed it.

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/47096/focus=47179

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Fernando J. Pereda
On Wed, Oct 15, 2008 at 08:51:32PM +0100, Ranjit Singh wrote:
  This is a purely stylistic issue, same as the braces with variable
  expansions.
 See my other posts.

Your other posts only show that this is, indeed, a personal stylistic
issue. And a pointless one, too.

- ferdy



pgpY8zl8tdvKz.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] some global useflags

2008-10-15 Thread Robin H. Johnson
On Wed, Oct 15, 2008 at 05:43:38PM +0100, Ciaran McCreesh wrote:
 Utterly illegal, needs to die.
Why? I don't agree that it needs to be the global useflags, but I don't
consider it illegal either.

It's defined by toolchain.eclass and toolchain-binutils.eclass, and
deliberately in a very careful manner, such that USE=-multislot and
USE=multislot do NOT conflict. There are no other uses in the tree.

For binutils, it simply enables slotting entirely.
For gcc, it moves the slot down from the major version to the minor version.

In both cases, which one gets called is controlled by the relevant *-config
utility. It's pretty handy when you are trying to figure out a gcc or binutils
bug in the minor versions.

Definitions:
toolchain-binutils:
if use multislot ; then
SLOT=${CTARGET}-${BVER}
elif is_cross ; then
SLOT=${CTARGET}
else
SLOT=0
fi

toolchain.eclass:
if use multislot ; then 
SLOT=${CTARGET}-${GCC_CONFIG_VER}
elif is_crosscompile; then 
SLOT=${CTARGET}-${GCC_BRANCH_VER}
else 
SLOT=${GCC_BRANCH_VER}
fi   

Packages where used:
sys-devel/binutils
sys-devel/binutils-hppa64
sys-devel/binutils-nios2
sys-devel/gcc
sys-devel/gcc-nios2
sys-devel/kgcc64

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpf0TWTS2gxb.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] some global useflags

2008-10-15 Thread Ciaran McCreesh
On Wed, 15 Oct 2008 14:47:06 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:
 On Wed, Oct 15, 2008 at 05:43:38PM +0100, Ciaran McCreesh wrote:
  Utterly illegal, needs to die.

 Why? I don't agree that it needs to be the global useflags, but I
 don't consider it illegal either.

It's illegal. Generated metadata must be constant and can't vary based
upon user configuration, because if it does the package manager will
show the wrong information at --pretend time. See bug #24439, for
example.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] some global useflags

2008-10-15 Thread Marius Mauch
On Thu, 16 Oct 2008 00:19:27 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Wed, 15 Oct 2008 14:47:06 -0700
 Robin H. Johnson [EMAIL PROTECTED] wrote:
  On Wed, Oct 15, 2008 at 05:43:38PM +0100, Ciaran McCreesh wrote:
   Utterly illegal, needs to die.
 
  Why? I don't agree that it needs to be the global useflags, but I
  don't consider it illegal either.
 
 It's illegal. Generated metadata must be constant and can't vary based
 upon user configuration, because if it does the package manager will
 show the wrong information at --pretend time.

There are also other issues, e.g. it breaks the generation of the
@installed package set as the installed slots can't be found in the
tree. As portage-2.2 makes increased use of slot atoms internally for
vdb handling we got a few bugreports simply due to the cache constraint
violation by USE=multislot.

Marius



USE=multislot, xDEPEND-syntax in SLOT and Slot dependencies [Was: Re: [gentoo-dev] [RFC] some global useflags]

2008-10-15 Thread Robin H. Johnson
I'm deliberately starting a new thread here, because this is meandering
well off the original topic of the global useflag proposals.

On Thu, Oct 16, 2008 at 02:18:16AM +0200, Marius Mauch wrote:
 There are also other issues, e.g. it breaks the generation of the
 @installed package set as the installed slots can't be found in the
 tree. As portage-2.2 makes increased use of slot atoms internally for
 vdb handling we got a few bugreports simply due to the cache constraint
 violation by USE=multislot.
Ok, I found bug #174184 on this matter.

kugelfang proposed to include this in EAPI=1, but I don't find it in
there, what happened?

The short-term fix of use.mask just stops current breakage, but we need
a real solution so that we can keep using it where we actually need it.

Ignoring Vapier's tirade against ciaranm there, we need the
xDEPEND-syntax for SLOTS as the real solution, however that still
wouldn't resolve the portion that has CTARGET as part of the SLOT, since
metadata generated on the rsyncmaster with a different CTARGET wouldn't
match on the clients.

I'm also wondering about a bad interaction with slot dependencies even
without having CTARGET:
Say gcc has two variants, SLOT=3.4 and SLOT=3.4.5. 
The language in the approved version of PMS (section 9.2.5) states: A
specification with a named slot dependency matches only if the slot of
the matched package is squal to ths lot specified.

So if package foo/bar-1.0 contains DEPEND=sys-devel/gcc:3.4 it
wouldn't match the other variant of gcc with SLOT=3.4.5 :-(.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpAf5eX3m8Sz.pgp
Description: PGP signature


Re: USE=multislot, xDEPEND-syntax in SLOT and Slot dependencies [Was: Re: [gentoo-dev] [RFC] some global useflags]

2008-10-15 Thread Marius Mauch
On Wed, 15 Oct 2008 17:20:32 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:

 Ignoring Vapier's tirade against ciaranm there, we need the
 xDEPEND-syntax for SLOTS as the real solution, however that still
 wouldn't resolve the portion that has CTARGET as part of the SLOT,
 since metadata generated on the rsyncmaster with a different CTARGET
 wouldn't match on the clients.

Are there significant USE cases for conditionals in SLOT that aren't
related to multislot and multiple ABIs? (the whole DEPEND syntax in
SLOT doesn't make sense)

For allowing multiple ABIs for a package to be installed I'm not
convinced that using SLOT is the right solution, this should probably
be considered as part of a more general multilib / cross-compile
support (there have been different designs for that).

And maybe in the (distant) future we can even add real multislot support
(same version of a package installed in multiple slots), but that's
going to need _major_ vdb and portage API changes first.

Marius



Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Arun Raghavan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Long wrote:
[...]
 for ((i=0;i10;i++)); do echo /usr/share/doc/${P}/examples 
 /dev/null;
 real 11.25
 real 9.24
 So that's what, on the order of 20 microseconds faster for each iteration?

 Or ~18%. (You shouldn't use the first iteration in general, btw.)

I've not really got an opinion on the topic, per se, but fwiw, this is
really not a meaningful statistic. *If* parsing strings in the ebuild is
not a trivial part of the overall ebuild parsing process, then yes, this
is a significant gain and should be treated as such. I find it unlikely
that this would be the case.

I'm not sure how one can go about measuring the impact of this on ebuild
parsing as a whole. Maybe make take a few typical ebuilds, change
quoting style, and run it through ebuild.sh in a loop. All the inherited
eclasses would need to change too, though, I guess.

Regards,
Arun
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkj2sxgACgkQ+Vqt1inD4uzW3wCfancNcJxcyHerjSZdZfK9UKb7
k5oAn0186/lLTAS2+n1Z7egzhAP1kISV
=CkaZ
-END PGP SIGNATURE-



Re: [gentoo-dev] [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread Peter Volkov
В Срд, 15/10/2008 в 20:51 +0100, Steve Long пишет:
  for ((i=0;i10;i++)); do echo /usr/share/doc/${P}/examples 
  /dev/null;
  
  real 11.25
  
  real 9.24
  
  So that's what, on the order of 20 microseconds faster for each iteration?
 
 Or ~18%. (You shouldn't use the first iteration in general, btw.)

Steve, your example only tests how much time bash takes to parse string.
It's obvious that in quoted strings some expansions could be avoided and
thus bash works faster. But although ebuilds use bash syntax they are
interpreted not only by bash - the time to parse stings is negligible to
other activities. I have not calculated but made a rough estimation
taking into account the number of ebuilds in the tree. So I think we
have of order of 10^6 string. This means that during merge of all
packages we'll win 10 seconds. I don't think it's worth to consider this
gain.

So in portage tree this is the matter of style. That's said, since
personally I don't have any preference on this style and until there
will be arguments not to use this style I'll start to use full quotation
of the strings.

And yes, in pure bash programs possibly this'll make sense.

-- 
Peter.