[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Samuli Suominen]

On 10/23/2011 03:00 PM, Tomas Chvatal (scarabeus) wrote:
> scarabeus    11/10/23 12:00:55
> 
>   Modified:             ChangeLog cdparanoia-3.10.2-r3.ebuild
>   Log:
>   Bump to eapi4 and punt static libs.

Time to revert this commit as I don't see anything in the ebuild that
disables building the static archives at compile phase.

This is same as hiding the problem, not solving it. Not the way we do
things at sound@.

>   
>   (Portage version: 2.2.0_alpha70/cvs/Linux x86_64)
> 
> Revision  Changes    Path
> 1.103                media-sound/cdparanoia/ChangeLog
> 
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/cdparanoia/ChangeLog?rev=1.103&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/cdparanoia/ChangeLog?rev=1.103&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/cdparanoia/ChangeLog?r1=1.102&r2=1.103
> 
> Index: ChangeLog
> ===================================================================
> RCS file: /var/cvsroot/gentoo-x86/media-sound/cdparanoia/ChangeLog,v
> retrieving revision 1.102
> retrieving revision 1.103
> diff -u -r1.102 -r1.103
> --- ChangeLog	21 Jan 2010 22:46:49 -0000	1.102
> +++ ChangeLog	23 Oct 2011 12:00:55 -0000	1.103
> @@ -1,6 +1,10 @@
>  # ChangeLog for media-sound/cdparanoia
> -# Copyright 1999-2010 Gentoo Foundation; Distributed under the GPL v2
> -# $Header: /var/cvsroot/gentoo-x86/media-sound/cdparanoia/ChangeLog,v 1.102 2010/01/21 22:46:49 abcd Exp $
> +# Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
> +# $Header: /var/cvsroot/gentoo-x86/media-sound/cdparanoia/ChangeLog,v 1.103 2011/10/23 12:00:55 scarabeus Exp $
> +
> +  23 Oct 2011; Tomáš Chvátal <scarabeus@gentoo.org>
> +  cdparanoia-3.10.2-r3.ebuild:
> +  Bump to eapi4 and punt static libs.
>  
>    21 Jan 2010; Jonathan Callen <abcd@gentoo.org>
>    cdparanoia-3.10.2-r3.ebuild:
> 
> 
> 
> 1.11                 media-sound/cdparanoia/cdparanoia-3.10.2-r3.ebuild
> 
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/cdparanoia/cdparanoia-3.10.2-r3.ebuild?rev=1.11&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/cdparanoia/cdparanoia-3.10.2-r3.ebuild?rev=1.11&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/cdparanoia/cdparanoia-3.10.2-r3.ebuild?r1=1.10&r2=1.11
> 
> Index: cdparanoia-3.10.2-r3.ebuild
> ===================================================================
> RCS file: /var/cvsroot/gentoo-x86/media-sound/cdparanoia/cdparanoia-3.10.2-r3.ebuild,v
> retrieving revision 1.10
> retrieving revision 1.11
> diff -u -r1.10 -r1.11
> --- cdparanoia-3.10.2-r3.ebuild	21 Jan 2010 22:46:49 -0000	1.10
> +++ cdparanoia-3.10.2-r3.ebuild	23 Oct 2011 12:00:55 -0000	1.11
> @@ -1,8 +1,9 @@
> -# Copyright 1999-2010 Gentoo Foundation
> +# Copyright 1999-2011 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/media-sound/cdparanoia/cdparanoia-3.10.2-r3.ebuild,v 1.10 2010/01/21 22:46:49 abcd Exp $
> +# $Header: /var/cvsroot/gentoo-x86/media-sound/cdparanoia/cdparanoia-3.10.2-r3.ebuild,v 1.11 2011/10/23 12:00:55 scarabeus Exp $
> +
> +EAPI=4
>  
> -EAPI=2
>  inherit autotools eutils flag-o-matic libtool toolchain-funcs versionator
>  
>  MY_P=${PN}-III-$(get_version_component_range 2-3)
> @@ -14,7 +15,7 @@
>  LICENSE="GPL-2 LGPL-2.1"
>  SLOT="0"
>  KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~amd64-linux ~x86-linux"
> -IUSE=""
> +IUSE="static-libs"
>  
>  S=${WORKDIR}/${MY_P}
>  
> @@ -37,10 +38,10 @@
>  }
>  
>  src_compile() {
> -	emake OPT="${CFLAGS}" || die "emake failed"
> +	emake OPT="${CFLAGS}"
>  }
>  
>  src_install() {
> -	emake DESTDIR="${D}" install || die "emake install failed"
> -	dodoc README
> +	default
> +	use static-libs || find "${ED}" -name '*.a' -exec rm -f {} +
>  }
> 
> 
> 
> 

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Rich Freeman]

On Sun, Oct 23, 2011 at 8:39 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 10/23/2011 03:00 PM, Tomas Chvatal (scarabeus) wrote:
>> scarabeus    11/10/23 12:00:55
>>
>>   Modified:             ChangeLog cdparanoia-3.10.2-r3.ebuild
>>   Log:
>>   Bump to eapi4 and punt static libs.
>
> Time to revert this commit as I don't see anything in the ebuild that
> disables building the static archives at compile phase.
>
> This is same as hiding the problem, not solving it. Not the way we do
> things at sound@.
>
>> +     use static-libs || find "${ED}" -name '*.a' -exec rm -f {} +

Doesn't reverting this seem a bit like shooting yourself in the foot
to remove an ingrown toenail?

Unless I'm missing something this DOES get rid of the unneeded
archives.  Now, sure, you'd save a few milliseconds of CPU if they
weren't built in the first place.  However, you're proposing replacing
an ebuild that builds but doesn't install undesired files with one
that builds them AND installs them (since the hypothetical ebuild that
does neither doesn't exist yet).

Perfection shouldn't hold us back from improvement.  By all means open
up a bug asking for the next level of improvement if it really bothers
people.

Now, if there is some subtle issue that causes issues during build if
the files are there and only removed at the last minute then clearly
that is a bigger problem.

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Samuli Suominen]

On 10/23/2011 04:27 PM, Rich Freeman wrote:
> On Sun, Oct 23, 2011 at 8:39 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> On 10/23/2011 03:00 PM, Tomas Chvatal (scarabeus) wrote:
>>> scarabeus    11/10/23 12:00:55
>>>
>>>   Modified:             ChangeLog cdparanoia-3.10.2-r3.ebuild
>>>   Log:
>>>   Bump to eapi4 and punt static libs.
>>
>> Time to revert this commit as I don't see anything in the ebuild that
>> disables building the static archives at compile phase.
>>
>> This is same as hiding the problem, not solving it. Not the way we do
>> things at sound@.
>>
>>> +     use static-libs || find "${ED}" -name '*.a' -exec rm -f {} +
> 
> Doesn't reverting this seem a bit like shooting yourself in the foot
> to remove an ingrown toenail?
> 
> Unless I'm missing something this DOES get rid of the unneeded
> archives.  Now, sure, you'd save a few milliseconds of CPU if they
> weren't built in the first place.  However, you're proposing replacing
> an ebuild that builds but doesn't install undesired files with one
> that builds them AND installs them (since the hypothetical ebuild that
> does neither doesn't exist yet).
> 
> Perfection shouldn't hold us back from improvement.  By all means open
> up a bug asking for the next level of improvement if it really bothers
> people.
> 
> Now, if there is some subtle issue that causes issues during build if
> the files are there and only removed at the last minute then clearly
> that is a bigger problem.

If you only wanted to remove these files, you are free to use
INSTALL_MASK locally instead of downgrading the quality of tree.

Do you have any idea how much time me, and aballier spent to make
cdparanoia's build system as clean as it is now? And then to coordinate
them with upstream xiph.org?
Then I see this... Not acceptable by any standards.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1014 bytes --]

On Sonntag 23 Oktober 2011 15:34:30 Samuli Suominen wrote:

> If you only wanted to remove these files, you are free to use
> INSTALL_MASK locally instead of downgrading the quality of tree.
> 
> Do you have any idea how much time me, and aballier spent to make
> cdparanoia's build system as clean as it is now? And then to coordinate
> them with upstream xiph.org?
> Then I see this... Not acceptable by any standards.

I'd like to get my standards up to speed, so may I respectfully ask- what is, 
apart from link time, the Gentoo-user-visible difference between
* removing the .a files in the ebuild
* and not building them in the first place?

(A clean build system is of course desirable, and it's great that you have 
been helping upstream with that. I just dont understand how this affects "the 
quality of the tree", compared to "the quality of upstream sources".)

TIA, 
Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Rich Freeman]

On Sun, Oct 23, 2011 at 9:34 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>
> If you only wanted to remove these files, you are free to use
> INSTALL_MASK locally instead of downgrading the quality of tree.

How is this a quality issue?  Why do we have a static-libs USE flag is
packages can't use it to determine whether the package installs static
libs?

It seems like this is only a "quality" issue in some aesthetic sense
of the word.  From an end-user point of view not installing the files
or not building them are the same thing, unless you're talking about
CPU time and tmp space usage.  Now, if the time to build those files
was actually significant then I could see an argument here, although
you haven't actually proposed an alternative that addresses this.

This doesn't really impact me much personally, but it just seems like
we nitpick stuff like this way too much when the goal should be things
that work.  By all means improve on things, but we shouldn't just be
reverting them.

Now, if in the course of making a minor change like this the committer
also rewrote half the ebuild which is something the maintainer has to
deal with that a fly-by-night visitor doesn't then I could see more of
an issue.  I don't really see this as creating any kind of maintenance
burden.

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Tomáš Chvátal]

2011/10/23 Samuli Suominen <ssuominen@gentoo.org>:
> On 10/23/2011 04:27 PM, Rich Freeman wrote:
>> On Sun, Oct 23, 2011 at 8:39 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>>> On 10/23/2011 03:00 PM, Tomas Chvatal (scarabeus) wrote:
>>>> scarabeus    11/10/23 12:00:55
>>>>
>>>>   Modified:             ChangeLog cdparanoia-3.10.2-r3.ebuild
>>>>   Log:
>>>>   Bump to eapi4 and punt static libs.
>>>
>>> Time to revert this commit as I don't see anything in the ebuild that
>>> disables building the static archives at compile phase.
>>>
>>> This is same as hiding the problem, not solving it. Not the way we do
>>> things at sound@.
>>>
>>>> +     use static-libs || find "${ED}" -name '*.a' -exec rm -f {} +
>>
>> Doesn't reverting this seem a bit like shooting yourself in the foot
>> to remove an ingrown toenail?
>>
>> Unless I'm missing something this DOES get rid of the unneeded
>> archives.  Now, sure, you'd save a few milliseconds of CPU if they
>> weren't built in the first place.  However, you're proposing replacing
>> an ebuild that builds but doesn't install undesired files with one
>> that builds them AND installs them (since the hypothetical ebuild that
>> does neither doesn't exist yet).
>>
>> Perfection shouldn't hold us back from improvement.  By all means open
>> up a bug asking for the next level of improvement if it really bothers
>> people.
>>
>> Now, if there is some subtle issue that causes issues during build if
>> the files are there and only removed at the last minute then clearly
>> that is a bigger problem.
>
> If you only wanted to remove these files, you are free to use
> INSTALL_MASK locally instead of downgrading the quality of tree.
>
> Do you have any idea how much time me, and aballier spent to make
> cdparanoia's build system as clean as it is now? And then to coordinate
> them with upstream xiph.org?
> Then I see this... Not acceptable by any standards.
>
>

So you would rather see me patch the makefile to drop the slib targets
conditionaly or alter whole src_compile to not run all but just lib on
the required options?
Both will take more space in the ebuild....
Or should I actually make the build system correct and rewrite it into
automake to use libtool?
Both take quite a lot time and since you state that you waste so much
on the build system anyway why didn't you fix it even before?
Anyway Since you are in the herd feel free to revert it as you already did so.

For that I have question, WHY THE FUCK DID YOU REVERT IT NOT USING ANY
CHANGELOG MESSAGE? If you would log this you would prevent others from
doing the same commit as me in the future, but yeah they are
developers they should use cvs log on the directory to see what samuli
had on his mind this time...

Anyway for they yajl i tried to submit patches for the build system
once and upstream is not interested so this is clear solution to solve
the issue without me having to patch half of the CMakeLists.txt.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Samuli Suominen]

On 10/23/2011 04:57 PM, Rich Freeman wrote:
> On Sun, Oct 23, 2011 at 9:34 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>>
>> If you only wanted to remove these files, you are free to use
>> INSTALL_MASK locally instead of downgrading the quality of tree.
> 
> How is this a quality issue?  Why do we have a static-libs USE flag is
> packages can't use it to determine whether the package installs static
> libs?
> 
> It seems like this is only a "quality" issue in some aesthetic sense
> of the word.  From an end-user point of view not installing the files
> or not building them are the same thing, unless you're talking about
> CPU time and tmp space usage.  Now, if the time to build those files
> was actually significant then I could see an argument here, although
> you haven't actually proposed an alternative that addresses this.

Yes, I'm talking about CPU time. That's the whole point of
USE=static-libs as per description:

global use flags (searching: static-libs)
************************************************************
[-      ] static-libs - Build static libraries
                        ^^^^^

Talks of building them, as it should. And as _a result_ it won't install
them.

The flag would be useless in favour of INSTALL_MASK if it were only for
preventing the installation.

> This doesn't really impact me much personally, but it just seems like
> we nitpick stuff like this way too much when the goal should be things
> that work.  By all means improve on things, but we shouldn't just be
> reverting them.

cdparanoia is very near top on my list on this clean up, and the only
reason why I haven't fixed it yet has been the pre-knowledge of the
crappy build system it has after spending so much time with it already

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Samuli Suominen]

On 10/23/2011 05:01 PM, Tomáš Chvátal wrote:
> 2011/10/23 Samuli Suominen <ssuominen@gentoo.org>:
>> On 10/23/2011 04:27 PM, Rich Freeman wrote:
>>> On Sun, Oct 23, 2011 at 8:39 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>>>> On 10/23/2011 03:00 PM, Tomas Chvatal (scarabeus) wrote:
>>>>> scarabeus    11/10/23 12:00:55
>>>>>
>>>>>   Modified:             ChangeLog cdparanoia-3.10.2-r3.ebuild
>>>>>   Log:
>>>>>   Bump to eapi4 and punt static libs.
>>>>
>>>> Time to revert this commit as I don't see anything in the ebuild that
>>>> disables building the static archives at compile phase.
>>>>
>>>> This is same as hiding the problem, not solving it. Not the way we do
>>>> things at sound@.
>>>>
>>>>> +     use static-libs || find "${ED}" -name '*.a' -exec rm -f {} +
>>>
>>> Doesn't reverting this seem a bit like shooting yourself in the foot
>>> to remove an ingrown toenail?
>>>
>>> Unless I'm missing something this DOES get rid of the unneeded
>>> archives.  Now, sure, you'd save a few milliseconds of CPU if they
>>> weren't built in the first place.  However, you're proposing replacing
>>> an ebuild that builds but doesn't install undesired files with one
>>> that builds them AND installs them (since the hypothetical ebuild that
>>> does neither doesn't exist yet).
>>>
>>> Perfection shouldn't hold us back from improvement.  By all means open
>>> up a bug asking for the next level of improvement if it really bothers
>>> people.
>>>
>>> Now, if there is some subtle issue that causes issues during build if
>>> the files are there and only removed at the last minute then clearly
>>> that is a bigger problem.
>>
>> If you only wanted to remove these files, you are free to use
>> INSTALL_MASK locally instead of downgrading the quality of tree.
>>
>> Do you have any idea how much time me, and aballier spent to make
>> cdparanoia's build system as clean as it is now? And then to coordinate
>> them with upstream xiph.org?
>> Then I see this... Not acceptable by any standards.
>>
>>
> 
> So you would rather see me patch the makefile to drop the slib targets
> conditionaly or alter whole src_compile to not run all but just lib on
> the required options?
> Both will take more space in the ebuild....

Setting make targets in src_compile sounds fine for this package. And
altering the build system to allow that if it already doesn't.

> Or should I actually make the build system correct and rewrite it into
> automake to use libtool?

Considering how hard it has been to make xiph.org accept patches, this
would propably be waste of time.

> Anyway for they yajl i tried to submit patches for the build system
> once and upstream is not interested so this is clear solution to solve
> the issue without me having to patch half of the CMakeLists.txt.
> 

USE=static-libs is about preventing the building of static archives, not
only about installing them, so if you don't want to patch the build
system for whatever reason, just leave it be.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Duncan]

Andreas K. Huettel posted on Sun, 23 Oct 2011 15:50:04 +0200 as excerpted:

> I'd like to get my standards up to speed, so may I respectfully ask-
> what is,
> apart from link time, the Gentoo-user-visible difference between *
> removing the .a files in the ebuild * and not building them in the first
> place?

If it was only link-time, that might be a point for simply removing them 
after link.

But if static libs are built at all, on amd64, it's not simply the link-
time at issue, but forces an actual double-build at least for the libs, 
once with -fPIC for dynamic linking, once without, for the static libs, 
(and executables if any).

Ask the mysql guys about the trouble they had with mysql-embedded on 
amd64, and the kde guys about the trouble with amarok for kde4 on amd64, 
as a result.

Interestingly enough, unless I've misunderstood, this issue would be 
affected by the recent security-based -fPIC/-fPIE on amd64 by default 
discussion as well, since if everything (including static libs) were 
built with at least -fPIC as required for dynamic linking, then a single 
build, linked once each for static and dynamic, as common on x86 (32-bit) 
would be at least arguably acceptable.  (IOW, my point here isn't to 
argue whether that'd be acceptable or not, but rather, that the forced 
double-build factor on amd64 is much more an issue than simple double-
linking would be.)

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 953 bytes --]

On Sunday 23 October 2011 09:50:04 Andreas K. Huettel wrote:
> On Sonntag 23 Oktober 2011 15:34:30 Samuli Suominen wrote:
> > If you only wanted to remove these files, you are free to use
> > INSTALL_MASK locally instead of downgrading the quality of tree.
> > 
> > Do you have any idea how much time me, and aballier spent to make
> > cdparanoia's build system as clean as it is now? And then to coordinate
> > them with upstream xiph.org?
> > Then I see this... Not acceptable by any standards.
> 
> I'd like to get my standards up to speed, so may I respectfully ask- what
> is, apart from link time, the Gentoo-user-visible difference between
> * removing the .a files in the ebuild
> * and not building them in the first place?

there is no post-emerge visible difference, but i wouldn't underestimate the 
speed of things.  for most packages, you're talking about compiling the files 
twice (once as PIC and once as not).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 964 bytes --]

On Sunday 23 October 2011 13:34:20 Duncan wrote:
> Interestingly enough, unless I've misunderstood, this issue would be
> affected by the recent security-based -fPIC/-fPIE on amd64 by default
> discussion as well, since if everything (including static libs) were
> built with at least -fPIC as required for dynamic linking, then a single
> build, linked once each for static and dynamic, as common on x86 (32-bit)
> would be at least arguably acceptable.  (IOW, my point here isn't to
> argue whether that'd be acceptable or not, but rather, that the forced
> double-build factor on amd64 is much more an issue than simple double-
> linking would be.)

it would be impacted, but not in the way you think.  static libs we'd compile 
with -fPIE while dynamic libs we'd compile with -fPIC.  these flags share a 
lot, but they aren't exactly the same.  -fPIE allows a few assumptions over -
fPIC which, for some code bases, improves performance.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Samuli Suominen]

On 01/18/2012 01:40 PM, Mike Frysinger wrote:
> On Sunday 23 October 2011 09:50:04 Andreas K. Huettel wrote:
>> On Sonntag 23 Oktober 2011 15:34:30 Samuli Suominen wrote:
>>> If you only wanted to remove these files, you are free to use
>>> INSTALL_MASK locally instead of downgrading the quality of tree.
>>>
>>> Do you have any idea how much time me, and aballier spent to make
>>> cdparanoia's build system as clean as it is now? And then to coordinate
>>> them with upstream xiph.org?
>>> Then I see this... Not acceptable by any standards.
>>
>> I'd like to get my standards up to speed, so may I respectfully ask- what
>> is, apart from link time, the Gentoo-user-visible difference between
>> * removing the .a files in the ebuild
>> * and not building them in the first place?
>
> there is no post-emerge visible difference, but i wouldn't underestimate the
> speed of things.  for most packages, you're talking about compiling the files
> twice (once as PIC and once as not).
> -mike

[ ... grabbing random mail from this thread ... ]

i've already fixed cdparanoid properly.
it was pretty much 2 liner, so whatever was committed before was simply 
out of laziness to investigate.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1772 bytes --]

On Wednesday 18 January 2012 06:42:37 Samuli Suominen wrote:
> On 01/18/2012 01:40 PM, Mike Frysinger wrote:
> > On Sunday 23 October 2011 09:50:04 Andreas K. Huettel wrote:
> >> On Sonntag 23 Oktober 2011 15:34:30 Samuli Suominen wrote:
> >>> If you only wanted to remove these files, you are free to use
> >>> INSTALL_MASK locally instead of downgrading the quality of tree.
> >>> 
> >>> Do you have any idea how much time me, and aballier spent to make
> >>> cdparanoia's build system as clean as it is now? And then to coordinate
> >>> them with upstream xiph.org?
> >>> Then I see this... Not acceptable by any standards.
> >> 
> >> I'd like to get my standards up to speed, so may I respectfully ask-
> >> what is, apart from link time, the Gentoo-user-visible difference
> >> between * removing the .a files in the ebuild
> >> * and not building them in the first place?
> > 
> > there is no post-emerge visible difference, but i wouldn't underestimate
> > the speed of things.  for most packages, you're talking about compiling
> > the files twice (once as PIC and once as not).
> 
> [ ... grabbing random mail from this thread ... ]
> 
> i've already fixed cdparanoid properly.
> it was pretty much 2 liner, so whatever was committed before was simply
> out of laziness to investigate.

come now, no need to jab people.  the obvious answer to you might not have 
been obvious to the committer.  we're all just doing the best we can with the 
time we have.

if you want some touch nuggets to tackle, take a look at the openssl ebuild.  
its generation of static archives are less than ideal because the build system 
creates one set of objects (all built with PIC), then produces a lib.so and 
lib.a from that single set.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild

[Samuli Suominen]

On 01/18/2012 01:56 PM, Mike Frysinger wrote:
> if you want some touch nuggets to tackle, take a look at the openssl ebuild.
> its generation of static archives are less than ideal because the build system
> creates one set of objects (all built with PIC), then produces a lib.so and
> lib.a from that single set.
> -mike

I know [1] :-)

[1] http://bugs.gentoo.org/328355