[gentoo-dev] Re: Re: Re: Multislot dependencies

[Tiziano Müller]

Ciaran McCreesh wrote:

> On Sat, 28 Jun 2008 23:41:17 +0200
> Tiziano Müller <[EMAIL PROTECTED]> wrote:
>> > := only makes sense when something is both a DEPEND and an RDEPEND.
>> > Actual behaviour, for Paludis, is that it rewrites := deps to :=blah
>> > when writing to VDB any time it can, and leaves anything it can't
>> > as := deps. Verifying sanity of := use is left to developers and
>> > the QA tool.
>>
>> ... and the spec.
> 
> The spec's well defined. It just tells you how := works, not how to use
> it in a sensible manner. Pretty much the same as for everything else.
Sorry, but I disagree.

> 
>> > The only sensible thing you can do with multiple matches on := slots
>> > (and ||=, if that route is taken) is to take the slot of the best
>> > matching installed version, and require that ebuilds do that too. In
>> > real world cases, this works just fine.
>> > 
>> so, ebuilds should use best_version instead of has_version for
>> example. That's what I meant and what I miss in the kdebuild-1
>> spec :-)
> 
> Generally, it "just works", because packages are usually fairly good at
> picking up the best installed version themselves anyway. But yes, if
> you have to pass a version manually to a package, best_version is the
> way to do it.

And what about a function to tell the PM explicitly which slot of a
dependency has been used (as an alternative)? Or should that decision
always be left to the PM? (that's something I'd expect to be in the PMS)


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

Re: [gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"

[Donnie Berkholz]

On 23:15 Sun 29 Jun , Fabian Groffen wrote:
> On 29-06-2008 07:29:57 -0400, Mike Frysinger wrote:
> > On Saturday 28 June 2008, Petteri Räty wrote:
> > > Arfrever Frehtes Taifersar Arahesis kirjoitti:
> > > > I would like to suggest that default LDFLAGS in Gentoo contain the
> > > > following flags: "-Wl,-O1,--hash-style=gnu,--sort-common".
> > > >
> > > > -O1 enables some basic optimizations.
> > >
> > > At least adding -O1 should not be problematic. I think vapier was
> > > already suggesting this quite a while ago.
> > 
> > imo -Wl,-O1 should go into base
> 
> I prefer not.  Please only on profiles that use GNU binutils as linker.

That's the rule, not the exception, so I think that profiles with 
non-gnu linkers should revert it.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: When the version scheme changes

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Duncan wrote:
> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on  Sun, 29 Jun 2008
> 18:20:06 +0200:
> 
>> Why can't portage use its own variables and export these with an initial
>> value but not use them further?
> 
> One way of looking at is that these /are/ the PM's own variables, simply 
> exposed read-only to make life simpler.  There's nothing you can't do by 
> setting your own variables initially equal to the read-only vars and 
> modifying them as you wish, that you could do if the PM exported them 
> writable but ignored any rewritten values itself.  Either a read-only 
> variable works fine, or a rewritable value then ignored by the PM 
> wouldn't work either.

That would work but it would require writing ebuilds in a funny way and would
unexpectedly break when someone DID improperly use the non-writable variables
for anything else than that initial copying. It's really not a solution, because
since there are no guarantees you still have to check all the code and can't do
automatic reversioning. Also doing this would basically be the same as manually
reversioning the entire tree.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhoJzIACgkQp/VmCx0OL2x4wgCfUoPNEtFWvV/PhIlBk05Cf2FR
rwoAoMlOTrgtoujSqJB5Az1wDSCVXFMB
=I1/q
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-06-29 23h59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2008-06-29 23h59 UTC.

Removals:
xfce-extra/notification-daemon-xfce 2008-06-23 02:16:35 drac
xfce-extra/xfkc 2008-06-23 03:44:30 drac
xfce-extra/xfce4-dev-tools  2008-06-23 12:37:44 drac
media-video/cinelerra-cvs   2008-06-24 12:24:44 hanno

Additions:
x11-misc/notification-daemon-xfce   2008-06-23 02:00:17 drac
x11-misc/xfkc   2008-06-23 03:43:59 drac
media-video/cinelerra   2008-06-24 12:23:17 hanno
sci-geosciences/viking  2008-06-24 12:46:28 hanno
dev-python/optcomplete  2008-06-25 11:40:55 hawking
sys-process/iotop   2008-06-26 17:19:20 dberkholz
x11-drivers/xf86-video-r128 2008-06-27 05:14:29 dberkholz
media-gfx/pdf2svg   2008-06-27 13:05:44 drac
net-analyzer/snips  2008-06-27 15:25:00 chainsaw
media-sound/alsamixer-app   2008-06-28 05:46:35 drac
x11-plugins/wmmand  2008-06-28 06:10:23 drac
sys-auth/pam_radius 2008-06-28 06:51:40 mrness
x11-drivers/xf86-video-mach64   2008-06-28 12:18:57 swegener
dev-libs/dbxml  2008-06-28 19:27:42 dev-zero
dev-libs/poco   2008-06-29 01:20:59 dev-zero
media-sound/milkytracker2008-06-29 11:25:35 drac
app-misc/slashtime  2008-06-29 17:18:15 ken69267

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
xfce-extra/notification-daemon-xfce,removed,drac,2008-06-23 02:16:35
xfce-extra/xfkc,removed,drac,2008-06-23 03:44:30
xfce-extra/xfce4-dev-tools,removed,drac,2008-06-23 12:37:44
media-video/cinelerra-cvs,removed,hanno,2008-06-24 12:24:44
Added Packages:
x11-misc/notification-daemon-xfce,added,drac,2008-06-23 02:00:17
x11-misc/xfkc,added,drac,2008-06-23 03:43:59
media-video/cinelerra,added,hanno,2008-06-24 12:23:17
sci-geosciences/viking,added,hanno,2008-06-24 12:46:28
dev-python/optcomplete,added,hawking,2008-06-25 11:40:55
sys-process/iotop,added,dberkholz,2008-06-26 17:19:20
x11-drivers/xf86-video-r128,added,dberkholz,2008-06-27 05:14:29
media-gfx/pdf2svg,added,drac,2008-06-27 13:05:44
net-analyzer/snips,added,chainsaw,2008-06-27 15:25:00
media-sound/alsamixer-app,added,drac,2008-06-28 05:46:35
x11-plugins/wmmand,added,drac,2008-06-28 06:10:23
sys-auth/pam_radius,added,mrness,2008-06-28 06:51:40
x11-drivers/xf86-video-mach64,added,swegener,2008-06-28 12:18:57
dev-libs/dbxml,added,dev-zero,2008-06-28 19:27:42
dev-libs/poco,added,dev-zero,2008-06-29 01:20:59
media-sound/milkytracker,added,drac,2008-06-29 11:25:35
app-misc/slashtime,added,ken69267,2008-06-29 17:18:15

Done.

[gentoo-dev] Re: When the version scheme changes

[Duncan]

"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on  Sun, 29 Jun 2008
18:20:06 +0200:

> Why can't portage use its own variables and export these with an initial
> value but not use them further?

One way of looking at is that these /are/ the PM's own variables, simply 
exposed read-only to make life simpler.  There's nothing you can't do by 
setting your own variables initially equal to the read-only vars and 
modifying them as you wish, that you could do if the PM exported them 
writable but ignored any rewritten values itself.  Either a read-only 
variable works fine, or a rewritable value then ignored by the PM 
wouldn't work either.

-- 
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

Re: [gentoo-dev] When the version scheme changes

[Rémi Cardona]

Hi Marijn,

Marijn Schouten (hkBst) wrote:

PV=${PV/0./}


MY_PV=...

As others have said, PV is read only.


to that new ebuild. This is the cleanest way to do it and doesn't require any
variable name changes or any other changes to the ebuild regardless of what it
does. Unfortunately it is also illegal per current PMS as PV is a read-only
variable. Right now I feel that the gain of having PV read-only (catch a few
bugs?) is much lower than the pain (extensive ebuild-dependend changes when the
version scheme changes). Please comment.


It's a pain, but then again, your old ebuilds are likely to go away as 
time passes, and the various hacks you've put in them will be long 
forgotten :)


There are only a couple cases were having PV writeable is a good idea. 
But let's keep this part of our ebuilds simple.


Right now, the section in devmanual that talks about PV is really short. 
Keeping it that way seems a good idea for potential new comers and old 
timers (that may forget stuff as time goes on) alike.


My 2 euro ¢

Cheers

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

Re: [gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"

[Fabian Groffen]

On 29-06-2008 07:29:57 -0400, Mike Frysinger wrote:
> On Saturday 28 June 2008, Petteri Räty wrote:
> > Arfrever Frehtes Taifersar Arahesis kirjoitti:
> > > I would like to suggest that default LDFLAGS in Gentoo contain the
> > > following flags: "-Wl,-O1,--hash-style=gnu,--sort-common".
> > >
> > > -O1 enables some basic optimizations.
> >
> > At least adding -O1 should not be problematic. I think vapier was
> > already suggesting this quite a while ago.
> 
> imo -Wl,-O1 should go into base

I prefer not.  Please only on profiles that use GNU binutils as linker.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: When the version scheme changes

[Ryan Hill]

"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:

> Marius Mauch wrote:

> > "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:

> >> Marius Mauch wrote:

> > I don't really see how making PV not read-only is any easier
> > than using MY_PV. Did you expect changing PV to magically
> > change P, PVR and PF too?

>  If we can agree to have those values writable we could define a
>  function that will handle resetting all those too.

> >>> Not going to happen. These variables are used internally by
> >>> portage in various ways, and making their content inconsistent
> >>> with the version in the filename is likely to cause subtle bugs
> >>> and/or weird behavior. Besides, you've yet to explain the benefit
> >>> of it, short of avoiding a simple replace operation in an ebuild,
> >>> and the given use case isn't all that common anyway.

> >> Why can't portage use its own variables and export these with an
> >> initial value but not use them further?

> > Because there is no need to create even more variables when there is
> > absolutely no benefit.

> The benefit is being able to automatically reversion an ebuild.
> Reversioning may not be necessary very often, but it's annoying when
> it is and there is no good reason that it should. There is no benefit
> in keeping the version variables read-only.

What is so hard about using MY_PV that you want portage to change how
it uses versioning internally?  It's one assignment and a sed.


-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

Re: [gentoo-dev] When the version scheme changes

[Santiago M. Mola]

On Sun, Jun 29, 2008 at 9:41 PM, Marijn Schouten (hkBst)
<[EMAIL PROTECTED]> wrote:
>
> The benefit is being able to automatically reversion an ebuild. Reversioning 
> may
> not be necessary very often, but it's annoying when it is and there is no good
> reason that it should. There is no benefit in keeping the version variables
> read-only.
>
> Marijn
>

I think that doing "PV=${PV/0./}" is asking for trouble, even if we
had a function for reseting it after the change. In any case it should
be a function like reset_pv ${PV/0./} which keeps other variables (P,
S...) consistent. Also, this would imply an EAPI bump.

I doubt this change is worth the trouble.

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

Re: [gentoo-dev] When the version scheme changes

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
> On Sun, 29 Jun 2008 18:20:06 +0200
> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Marius Mauch wrote:
>>> On Sun, 29 Jun 2008 15:52:37 +0200
>>> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Bo Ørsted Andresen wrote:
> On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
>> PV=${PV/0./}
>>
>> to that new ebuild. This is the cleanest way to do it and doesn't
>> require any variable name changes or any other changes to the
>> ebuild regardless of what it does. Unfortunately it is also
>> illegal per current PMS as PV is a read-only variable. Right now
>> I feel that the gain of having PV read-only (catch a few bugs?)
>> is much lower than the pain (extensive ebuild-dependend changes
>> when the version scheme changes). Please comment.
> I don't really see how making PV not read-only is any easier than
> using MY_PV. Did you expect changing PV to magically change P, PVR
> and PF too?
 If we can agree to have those values writable we could define a
 function that will handle resetting all those too.
>>> Not going to happen. These variables are used internally by portage
>>> in various ways, and making their content inconsistent with the
>>> version in the filename is likely to cause subtle bugs and/or weird
>>> behavior. Besides, you've yet to explain the benefit of it, short
>>> of avoiding a simple replace operation in an ebuild, and the given
>>> use case isn't all that common anyway.
>> Why can't portage use its own variables and export these with an
>> initial value but not use them further?
> 
> Because there is no need to create even more variables when there is
> absolutely no benefit.

The benefit is being able to automatically reversion an ebuild. Reversioning may
not be necessary very often, but it's annoying when it is and there is no good
reason that it should. There is no benefit in keeping the version variables
read-only.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhn5XkACgkQp/VmCx0OL2xBgwCfbOtDaJ27kj1A2CbO95dkrkZb
x0MAn1usfmfaktYA83MoiukBvlXIuuUN
=BQs/
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] When the version scheme changes

[Marius Mauch]

On Sun, 29 Jun 2008 18:20:06 +0200
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Marius Mauch wrote:
> > On Sun, 29 Jun 2008 15:52:37 +0200
> > "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
> > 
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> Bo Ørsted Andresen wrote:
> >>> On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
>  PV=${PV/0./}
> 
>  to that new ebuild. This is the cleanest way to do it and doesn't
>  require any variable name changes or any other changes to the
>  ebuild regardless of what it does. Unfortunately it is also
>  illegal per current PMS as PV is a read-only variable. Right now
>  I feel that the gain of having PV read-only (catch a few bugs?)
>  is much lower than the pain (extensive ebuild-dependend changes
>  when the version scheme changes). Please comment.
> >>> I don't really see how making PV not read-only is any easier than
> >>> using MY_PV. Did you expect changing PV to magically change P, PVR
> >>> and PF too?
> >> If we can agree to have those values writable we could define a
> >> function that will handle resetting all those too.
> > 
> > Not going to happen. These variables are used internally by portage
> > in various ways, and making their content inconsistent with the
> > version in the filename is likely to cause subtle bugs and/or weird
> > behavior. Besides, you've yet to explain the benefit of it, short
> > of avoiding a simple replace operation in an ebuild, and the given
> > use case isn't all that common anyway.
> 
> Why can't portage use its own variables and export these with an
> initial value but not use them further?

Because there is no need to create even more variables when there is
absolutely no benefit.

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

Re: [gentoo-dev] When the version scheme changes

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
> On Sun, 29 Jun 2008 15:52:37 +0200
> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Bo Ørsted Andresen wrote:
>>> On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
 PV=${PV/0./}

 to that new ebuild. This is the cleanest way to do it and doesn't
 require any variable name changes or any other changes to the
 ebuild regardless of what it does. Unfortunately it is also
 illegal per current PMS as PV is a read-only variable. Right now I
 feel that the gain of having PV read-only (catch a few bugs?) is
 much lower than the pain (extensive ebuild-dependend changes when
 the version scheme changes). Please comment.
>>> I don't really see how making PV not read-only is any easier than
>>> using MY_PV. Did you expect changing PV to magically change P, PVR
>>> and PF too?
>> If we can agree to have those values writable we could define a
>> function that will handle resetting all those too.
> 
> Not going to happen. These variables are used internally by portage in
> various ways, and making their content inconsistent with the version in
> the filename is likely to cause subtle bugs and/or weird behavior.
> Besides, you've yet to explain the benefit of it, short of avoiding a
> simple replace operation in an ebuild, and the given use case isn't all
> that common anyway.

Why can't portage use its own variables and export these with an initial value
but not use them further?

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhntjYACgkQp/VmCx0OL2yxdgCght6buiC3nTWqQiaADBOVR2Xw
ezYAnA57T74GJ6izX2mk8XuOX/c8MyL4
=zW3N
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] When the version scheme changes

[Marius Mauch]

On Sun, 29 Jun 2008 15:52:37 +0200
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Bo Ørsted Andresen wrote:
> > On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
> >> PV=${PV/0./}
> >>
> >> to that new ebuild. This is the cleanest way to do it and doesn't
> >> require any variable name changes or any other changes to the
> >> ebuild regardless of what it does. Unfortunately it is also
> >> illegal per current PMS as PV is a read-only variable. Right now I
> >> feel that the gain of having PV read-only (catch a few bugs?) is
> >> much lower than the pain (extensive ebuild-dependend changes when
> >> the version scheme changes). Please comment.
> > 
> > I don't really see how making PV not read-only is any easier than
> > using MY_PV. Did you expect changing PV to magically change P, PVR
> > and PF too?
> 
> If we can agree to have those values writable we could define a
> function that will handle resetting all those too.

Not going to happen. These variables are used internally by portage in
various ways, and making their content inconsistent with the version in
the filename is likely to cause subtle bugs and/or weird behavior.
Besides, you've yet to explain the benefit of it, short of avoiding a
simple replace operation in an ebuild, and the given use case isn't all
that common anyway.

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

Re: [gentoo-dev] When the version scheme changes

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bo Ørsted Andresen wrote:
> On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
>> PV=${PV/0./}
>>
>> to that new ebuild. This is the cleanest way to do it and doesn't require
>> any variable name changes or any other changes to the ebuild regardless of
>> what it does. Unfortunately it is also illegal per current PMS as PV is a
>> read-only variable. Right now I feel that the gain of having PV read-only
>> (catch a few bugs?) is much lower than the pain (extensive ebuild-dependend
>> changes when the version scheme changes). Please comment.
> 
> I don't really see how making PV not read-only is any easier than using 
> MY_PV. 
> Did you expect changing PV to magically change P, PVR and PF too?

If we can agree to have those values writable we could define a function that
will handle resetting all those too.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhnk6UACgkQp/VmCx0OL2xJPgCghPdttL5ruS/qkoZzsrKn8WL7
9OAAn3FGZrQMRsRGHlmAgdf1uiyjuJH9
=EmW/
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"

[Mike Frysinger]

On Tuesday 24 June 2008, Diego 'Flameeyes' Pettenò wrote:
> Fabian Groffen <[EMAIL PROTECTED]> writes:
> > as long as it doesn't go in /base, but in the linux/freebsd profiles
> > instead, it's fine with me.
>
> --has-style=gnu should not be used on non-GLIBC systems (I'm unsure
> about uclibc, but I'd be surprised if they do implement the GNU style
> hash).

why would you be surprised ?  the GNU hash style addresses a lot of issues 
with the SYSV one.  uClibc (well not the version in the tree) contains 
optional support for it.
-mike


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

Re: [gentoo-dev] Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"

[Mike Frysinger]

On Saturday 28 June 2008, Petteri Räty wrote:
> Arfrever Frehtes Taifersar Arahesis kirjoitti:
> > I would like to suggest that default LDFLAGS in Gentoo contain the
> > following flags: "-Wl,-O1,--hash-style=gnu,--sort-common".
> >
> > -O1 enables some basic optimizations.
>
> At least adding -O1 should not be problematic. I think vapier was
> already suggesting this quite a while ago.

imo -Wl,-O1 should go into base
-mike


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

Re: [gentoo-dev] When the version scheme changes

[Bo Ørsted Andresen]

On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
> PV=${PV/0./}
>
> to that new ebuild. This is the cleanest way to do it and doesn't require
> any variable name changes or any other changes to the ebuild regardless of
> what it does. Unfortunately it is also illegal per current PMS as PV is a
> read-only variable. Right now I feel that the gain of having PV read-only
> (catch a few bugs?) is much lower than the pain (extensive ebuild-dependend
> changes when the version scheme changes). Please comment.

I don't really see how making PV not read-only is any easier than using MY_PV. 
Did you expect changing PV to magically change P, PVR and PF too?

-- 
Bo Andresen
Gentoo KDE Dev


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