FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-31-2012, 08:01 AM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 00:12:53 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Mike Frysinger posted on Thu, 30 Aug 2012 19:46:21 -0400 as excerpted:
>
> > On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
> >> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
> >>> On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
> >>> > On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
> >>> >>
> >>> >> keeping things in @system doesn't make much sense:
> >>> >> - there's a penalty (as noted in old threads)
> >>> >> - it isn't actually required at runtime, so it's bloat on
> >>> >> reduced systems
> >>> >
> >>> > I think it's practically the same as compiler.
> >>>
> >>> that isn't a bad view point, but for the purposes of this
> >>> discussion, i don't think it's relevant
> >>
> >> Will it be a better view point if I opened a separate discussion
> >> about putting pkg-config in @system? It could get more attention
> >> probably.
> >
> > my answer would still be a very strong no
>
> Agreed.
>
> Various people have in fact expressed a desire to REDUCE the number
> of packages in @system, for various reasons including both the
> parallel merge penalty and the bloat on reduced systems. In
> practice, there's not a lot of positive movement on actually reducing
> @system, but at minimum, unless there's *NO* other choice and in this
> case there clearly is, we shouldn't be ADDING packages to @system.
>
> For that reason, while I do see the reason why some would like
> pkg-config added to @system, the whole idea's pretty much a
> non-starter, as it WILL get a lot of push-back. In theory it /might/
> be forceable, but I just don't see how the cost, political, in time
> to push thru, and technical (given the technical reasons listed
> above), makes it worth pursuing in the slightest. It's just not
> worth going there.

But you're aware that cost of pkgconf is very little?

--
Best regards,
Michał Górny
 
Old 08-31-2012, 10:06 AM
Duncan
 
Default prune_libtool_files() and pkg-config dependency

Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted:

> On Fri, 31 Aug 2012 00:12:53 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>> Various people have in fact expressed a desire to REDUCE the number of
>> packages in @system, for various reasons including both the parallel
>> merge penalty and the bloat on reduced systems. In practice, there's
>> not a lot of positive movement on actually reducing @system, but at
>> minimum, unless there's *NO* other choice and in this case there
>> clearly is, we shouldn't be ADDING packages to @system.
>>
>> For that reason, while I do see the reason why some would like
>> pkg-config added to @system, the whole idea's pretty much a
>> non-starter

> But you're aware that cost of pkgconf is very little?

Not really, when it's a step in the opposite direction from an intended
goal. The first step toward any goal is to stop going backward, and
that's exactly what this would be. We need a smaller @system, not a
larger one, and while the add would be easy, undoing it years later when
it's yet another bit of the tangled web woven, would be *MUCH* more
difficult. Just don't do it; don't go backward; don't add to the problem
instead of reducing it.

--
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
 
Old 08-31-2012, 10:42 AM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 10:06:06 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted:
>
> > On Fri, 31 Aug 2012 00:12:53 +0000 (UTC)
> > Duncan <1i5t5.duncan@cox.net> wrote:
> >
> >> Various people have in fact expressed a desire to REDUCE the
> >> number of packages in @system, for various reasons including both
> >> the parallel merge penalty and the bloat on reduced systems. In
> >> practice, there's not a lot of positive movement on actually
> >> reducing @system, but at minimum, unless there's *NO* other choice
> >> and in this case there clearly is, we shouldn't be ADDING packages
> >> to @system.
> >>
> >> For that reason, while I do see the reason why some would like
> >> pkg-config added to @system, the whole idea's pretty much a
> >> non-starter
>
> > But you're aware that cost of pkgconf is very little?
>
> Not really, when it's a step in the opposite direction from an
> intended goal. The first step toward any goal is to stop going
> backward, and that's exactly what this would be. We need a smaller
> @system, not a larger one, and while the add would be easy, undoing
> it years later when it's yet another bit of the tangled web woven,
> would be *MUCH* more difficult. Just don't do it; don't go backward;
> don't add to the problem instead of reducing it.

So please introduce virtual/compiler, virtual/linker,
virtual/posix-system, virtual/sratatata and add them to DEPEND of every
single ebuild.

I believe that the more important direction here is to make development
*easier*, not harder. Adding the same DEPENDs over and over again to
every single package is at least frustrating. Similarly frustrating
would be if those 'reduced systems' had to rebuild gcc every time they
wanted to compile something... oh wait, they would have to bootstrap it
every time.

--
Best regards,
Michał Górny
 
Old 08-31-2012, 11:48 AM
Rich Freeman
 
Default prune_libtool_files() and pkg-config dependency

On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> So please introduce virtual/compiler, virtual/linker,
> virtual/posix-system, virtual/sratatata and add them to DEPEND of every
> single ebuild.

Every ebuild doesn't need all of those - that is the whole point. As
Duncan already pointed out, reducing @system is a goal, but it doesn't
mean that we need to get there overnight. However, we'll never get
there if we keep going backwards.

>
> I believe that the more important direction here is to make development
> *easier*, not harder. Adding the same DEPENDs over and over again to
> every single package is at least frustrating.

This isn't needed by every single package either. I'm all for tools
that help automate DEPEND population, and I'm fine with having an
ebuild template that includes "gotcha" depends pre-populated so that
devs give them consideration (and deleting lines is easier than adding
them).

> Similarly frustrating
> would be if those 'reduced systems' had to rebuild gcc every time they
> wanted to compile something... oh wait, they would have to bootstrap it
> every time.
>

I would think that somebody running a reduced system would be likely
to be installing binary packages, or use a binary package of gcc, etc.
Presumably they knew what they're getting into and for whatever
reason the balance was considered acceptable for them. I would think
that the sorts of people who would run reduced systems would probably
not be updating them frequently anyway.

There are also other benefits of reduced @system besides running a
reduced system.

Rich
 
Old 08-31-2012, 02:56 PM
Alexis Ballier
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 12:42:10 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 31 Aug 2012 10:06:06 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
> > Michał Górny posted on Fri, 31 Aug 2012 10:01:09 +0200 as excerpted:
> >
> > > On Fri, 31 Aug 2012 00:12:53 +0000 (UTC)
> > > Duncan <1i5t5.duncan@cox.net> wrote:
> > >
> > >> Various people have in fact expressed a desire to REDUCE the
> > >> number of packages in @system, for various reasons including both
> > >> the parallel merge penalty and the bloat on reduced systems. In
> > >> practice, there's not a lot of positive movement on actually
> > >> reducing @system, but at minimum, unless there's *NO* other
> > >> choice and in this case there clearly is, we shouldn't be ADDING
> > >> packages to @system.
> > >>
> > >> For that reason, while I do see the reason why some would like
> > >> pkg-config added to @system, the whole idea's pretty much a
> > >> non-starter
> >
> > > But you're aware that cost of pkgconf is very little?
> >
> > Not really, when it's a step in the opposite direction from an
> > intended goal. The first step toward any goal is to stop going
> > backward, and that's exactly what this would be. We need a smaller
> > @system, not a larger one, and while the add would be easy, undoing
> > it years later when it's yet another bit of the tangled web woven,
> > would be *MUCH* more difficult. Just don't do it; don't go
> > backward; don't add to the problem instead of reducing it.
>
> So please introduce virtual/compiler, virtual/linker,
> virtual/posix-system, virtual/sratatata and add them to DEPEND of
> every single ebuild.
>
> I believe that the more important direction here is to make
> development *easier*, not harder. Adding the same DEPENDs over and
> over again to every single package is at least frustrating. Similarly
> frustrating would be if those 'reduced systems' had to rebuild gcc
> every time they wanted to compile something... oh wait, they would
> have to bootstrap it every time.
>

you would achieve it better by adding pkgconfig to DEPEND in
eutils.eclass than putting it in @system since in the latter case it
would also be a RDEPEND of everything basically

this doesnt really compare to gcc since its a RDEPEND for everything c++
and maybe more (i didnt check when libgcc_s is linked in or not)

A.
 
Old 08-31-2012, 03:05 PM
Ian Stakenvicius
 
Default prune_libtool_files() and pkg-config dependency

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 31/08/12 10:56 AM, Alexis Ballier wrote:
> Michał Górny <mgorny@gentoo.org> wrote:
>>
>> I believe that the more important direction here is to make
>> development *easier*, not harder. Adding the same DEPENDs over
>> and over again to every single package is at least frustrating.
>> Similarly frustrating would be if those 'reduced systems' had to
>> rebuild gcc every time they wanted to compile something... oh
>> wait, they would have to bootstrap it every time.
>>
>
> you would achieve it better by adding pkgconfig to DEPEND in
> eutils.eclass than putting it in @system since in the latter case
> it would also be a RDEPEND of everything basically
>

And realistically that's where the DEPEND should be anyways, IMO --
appended by the eclass where the function is that uses it. If this
means prune_libtool_files() gets separated out of eutils and put in
its own eclass (so that all the eutils inheritors don't suddenly need
virtual/pkgconfig unnecessarily), then so be it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBA0rMACgkQ2ugaI38ACPB8dgD8CsXPJvPDjI 3111dXT/z+gGUM
q8wTmMYqR2zVJasZMJQA/25de5bSofnwk4fXlCwPEFJ3Tu9rtCFRAx+q95oGFkad
=GWHe
-----END PGP SIGNATURE-----
 
Old 08-31-2012, 03:08 PM
Jeff Horelick
 
Default prune_libtool_files() and pkg-config dependency

On 31 August 2012 11:05, Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 31/08/12 10:56 AM, Alexis Ballier wrote:
>> Michał Górny <mgorny@gentoo.org> wrote:
>>>
>>> I believe that the more important direction here is to make
>>> development *easier*, not harder. Adding the same DEPENDs over
>>> and over again to every single package is at least frustrating.
>>> Similarly frustrating would be if those 'reduced systems' had to
>>> rebuild gcc every time they wanted to compile something... oh
>>> wait, they would have to bootstrap it every time.
>>>
>>
>> you would achieve it better by adding pkgconfig to DEPEND in
>> eutils.eclass than putting it in @system since in the latter case
>> it would also be a RDEPEND of everything basically
>>
>
> And realistically that's where the DEPEND should be anyways, IMO --
> appended by the eclass where the function is that uses it. If this
> means prune_libtool_files() gets separated out of eutils and put in
> its own eclass (so that all the eutils inheritors don't suddenly need
> virtual/pkgconfig unnecessarily), then so be it.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iF4EAREIAAYFAlBA0rMACgkQ2ugaI38ACPB8dgD8CsXPJvPDjI 3111dXT/z+gGUM
> q8wTmMYqR2zVJasZMJQA/25de5bSofnwk4fXlCwPEFJ3Tu9rtCFRAx+q95oGFkad
> =GWHe
> -----END PGP SIGNATURE-----
>

Also, I think that before many of these large changes happen, pkgconf
should become the default choice for the virtual. I'm sure embedded or
server users don't need/want Glib on their systems.
 
Old 08-31-2012, 04:03 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 11:05:23 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 31/08/12 10:56 AM, Alexis Ballier wrote:
> > Michał Górny <mgorny@gentoo.org> wrote:
> >>
> >> I believe that the more important direction here is to make
> >> development *easier*, not harder. Adding the same DEPENDs over
> >> and over again to every single package is at least frustrating.
> >> Similarly frustrating would be if those 'reduced systems' had to
> >> rebuild gcc every time they wanted to compile something... oh
> >> wait, they would have to bootstrap it every time.
> >>
> >
> > you would achieve it better by adding pkgconfig to DEPEND in
> > eutils.eclass than putting it in @system since in the latter case
> > it would also be a RDEPEND of everything basically
> >
>
> And realistically that's where the DEPEND should be anyways, IMO --
> appended by the eclass where the function is that uses it. If this
> means prune_libtool_files() gets separated out of eutils and put in
> its own eclass (so that all the eutils inheritors don't suddenly need
> virtual/pkgconfig unnecessarily), then so be it.

I wasn't referring to the function at the moment but at the overall
fact that practically any C/C++ package depending on any non-standard
library practically should depend on pkg-config. A library not
providing pkg-config file is simply broken.

--
Best regards,
Michał Górny
 
Old 08-31-2012, 04:08 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 07:48:23 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> >
> > So please introduce virtual/compiler, virtual/linker,
> > virtual/posix-system, virtual/sratatata and add them to DEPEND of
> > every single ebuild.
>
> Every ebuild doesn't need all of those - that is the whole point. As
> Duncan already pointed out, reducing @system is a goal, but it doesn't
> mean that we need to get there overnight. However, we'll never get
> there if we keep going backwards.

Reducing @system may be a goal but it should be a *reasonable* goal.
Not reducing because we can reduce but because it is bloated with
unneeded software.

We shouldn't even try to go below POSIX system requirements; we
shouldn't remove standard Linux stuff (from Linux profiles, at least)
either. And I believe toolchain belongs to @system as well; or at least
the C99 compiler.

And for a reasonable Gentoo toolchain, pkg-config is a must-have. At
least since we deprecated and are seriously fighting libtool.

--
Best regards,
Michał Górny
 
Old 08-31-2012, 04:12 PM
Fabian Groffen
 
Default prune_libtool_files() and pkg-config dependency

On 31-08-2012 18:08:12 +0200, Michał Górny wrote:
> And for a reasonable Gentoo toolchain, pkg-config is a must-have. At
> least since we deprecated and are seriously fighting libtool.

what?


--
Fabian Groffen
Gentoo on a different level
 

Thread Tools




All times are GMT. The time now is 10:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org