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, 04:25 PM
Ian Stakenvicius
 
Default prune_libtool_files() and pkg-config dependency

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

On 31/08/12 12:12 PM, Fabian Groffen wrote:
> 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?

deprecated libtool = deprecated the installation of libtool's .la
files unless absolutely necessary



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

iF4EAREIAAYFAlBA5YEACgkQ2ugaI38ACPBdKwD/VBUh3YujIN6gTAQD1NkWGij0
NHQbKrTeqTZV5i7S7IQBAJwCvgNuJgFRioAUMJrFfwQvNO7xEb t+hFXCtLM1zWtf
=ognq
-----END PGP SIGNATURE-----
 
Old 08-31-2012, 04:25 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 18:12:58 +0200
Fabian Groffen <grobian@gentoo.org> wrote:

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

Libtool archives, I meant.

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

Michał Górny posted on Fri, 31 Aug 2012 18:08:12 +0200 as excerpted:

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

I think I see the problem. Unsurprisingly it's a terminology definition
mismatch problem, as so many are. =:^

The reduce @system idea considers it a simple set of packages that are
treated specially, and that exists to some degree for legacy reasons
(back when gentoo was first being created, it was just easier to do it
that way). The (obviously long-term) goal would be to eliminate @system
with its currently special treatment entirely, including POSIX
components. That may not be possible, but reducing it substantially
should be.

But we're not talking actually removing packages from a default gentoo
install, just increasing the number of packages that are directly
specified depends and removing them from the @system _set_, until there's
very little if anything left to it.

Thus, not adding it to @system in no way means it's not considered
mandatory for a normal install, it just means the ultimate goal is to
have all the deps specified and nothing left in @system, and while
progress isn't fast by a long shot, the first thing is to ensure we're
not regressing!

--
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, 06:56 PM
Mike Gilbert
 
Default prune_libtool_files() and pkg-config dependency

On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Thus, not adding it to @system in no way means it's not considered
> mandatory for a normal install, it just means the ultimate goal is to
> have all the deps specified and nothing left in @system, and while
> progress isn't fast by a long shot, the first thing is to ensure we're
> not regressing!
>

If the ultimate goal is to eliminate @system entirely (which it
probably isn't), we will need to revisit the way stage building works.
If understand correctly, a stage3 contains @system and its
dependencies.

The smallest you can really make @system under that circumstance would
be a working toolchain and the utilities necessary to build any other
needed packages. I think that is the goal that most people have been
shooting for lately.
 
Old 08-31-2012, 07:07 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 14:56:06 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > Thus, not adding it to @system in no way means it's not considered
> > mandatory for a normal install, it just means the ultimate goal is
> > to have all the deps specified and nothing left in @system, and
> > while progress isn't fast by a long shot, the first thing is to
> > ensure we're not regressing!
> >
>
> If the ultimate goal is to eliminate @system entirely (which it
> probably isn't), we will need to revisit the way stage building works.
> If understand correctly, a stage3 contains @system and its
> dependencies.
>
> The smallest you can really make @system under that circumstance would
> be a working toolchain and the utilities necessary to build any other
> needed packages. I think that is the goal that most people have been
> shooting for lately.

But you are aware that this will practically mean that there could be
no stand-alone ebuild repository because fulfilling the ebuild
dependencies wouldn't be anymore possible without providing all
of the standard system components, including those specified as
required by the PMS?

That in turn will make PMS utility requirements (bash, GNU find
etcetera) completely useless because the ebuilds will have to request
them explicitly anyway. But hey, you're aware that ebuilds use some of
those tools in global scope, before DEPEND is fulfilled? Also, I don't
think we have any kind of 'build'-time dependencies for binary
packages...
--
Best regards,
Michał Górny
 
Old 08-31-2012, 07:31 PM
Alexis Ballier
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 18:03:33 +0200
Michał Górny <mgorny@gentoo.org> wrote:

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

Hu? You know, some people think pkgconfig is a poorman's workaround for
a different problem. You don't need .pc files for dynamic linking
because:
1) there is a standard include search path
2) there is a standard library path
3) elf shared objects support dependencies

You might need pkgconfig for static linking because static archives do
not support 3). Isn't it the thing that should be improved instead ?

Alike you claim a library not providing a .pc is broken, I can claim
that a library relying on it is broken because it is violating 1)
and/or 2) which are well established unix behavior.

A.
 
Old 08-31-2012, 08:01 PM
Rich Freeman
 
Default prune_libtool_files() and pkg-config dependency

On Fri, Aug 31, 2012 at 2:56 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Thus, not adding it to @system in no way means it's not considered
>> mandatory for a normal install, it just means the ultimate goal is to
>> have all the deps specified and nothing left in @system, and while
>> progress isn't fast by a long shot, the first thing is to ensure we're
>> not regressing!
>>
>
> If the ultimate goal is to eliminate @system entirely (which it
> probably isn't), we will need to revisit the way stage building works.
> If understand correctly, a stage3 contains @system and its
> dependencies.

The goal would be to eliminate @system entirely.

The solution to stage3 would be to have a set like @system of default
starting packages. It might even be a defined set that users could
make use of (emerge @default), but ebuilds could not assume that they
are present.

To build them you just start with a working Gentoo system and emerge them.

>
> The smallest you can really make @system under that circumstance would
> be a working toolchain and the utilities necessary to build any other
> needed packages. I think that is the goal that most people have been
> shooting for lately.

Nobody is suggesting that a system containing no packages whatsoever
should be bootable, let alone usable to bootstrap everything else.
There would be some minimal set of packages needed to bootstrap the
rest. However, ebuilds would need to explicitly declare their need
for them rather than assuming they are present. Virtuals could be
used to simplify this.

In fact, there is a simple way to transition to such a system. Start
by defining a virtual that contains everything that is in @system
(setting aside the issue that this is profile-dependent), and adding
that as a DEPEND and RDEPEND to every ebuild. Then start paring it
down per-ebuild.

The goal is not to have working Gentoo systems that contain nothing on
their hard drives, but rather to eliminate the arbitrary collection of
packages that must be present everywhere, because some software that
might or might not even be installed could need them.

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

On Fri, 31 Aug 2012 16:01:01 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Aug 31, 2012 at 2:56 PM, Mike Gilbert <floppym@gentoo.org>
> wrote:
> > On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@cox.net>
> > wrote:
> >> Thus, not adding it to @system in no way means it's not considered
> >> mandatory for a normal install, it just means the ultimate goal is
> >> to have all the deps specified and nothing left in @system, and
> >> while progress isn't fast by a long shot, the first thing is to
> >> ensure we're not regressing!
> >>
> >
> > If the ultimate goal is to eliminate @system entirely (which it
> > probably isn't), we will need to revisit the way stage building
> > works. If understand correctly, a stage3 contains @system and its
> > dependencies.
>
> The goal would be to eliminate @system entirely.
>
> The solution to stage3 would be to have a set like @system of default
> starting packages. It might even be a defined set that users could
> make use of (emerge @default), but ebuilds could not assume that they
> are present.
>
> To build them you just start with a working Gentoo system and emerge
> them.
>
> >
> > The smallest you can really make @system under that circumstance
> > would be a working toolchain and the utilities necessary to build
> > any other needed packages. I think that is the goal that most
> > people have been shooting for lately.
>
> Nobody is suggesting that a system containing no packages whatsoever
> should be bootable, let alone usable to bootstrap everything else.
> There would be some minimal set of packages needed to bootstrap the
> rest. However, ebuilds would need to explicitly declare their need
> for them rather than assuming they are present. Virtuals could be
> used to simplify this.
>
> In fact, there is a simple way to transition to such a system. Start
> by defining a virtual that contains everything that is in @system
> (setting aside the issue that this is profile-dependent), and adding
> that as a DEPEND and RDEPEND to every ebuild. Then start paring it
> down per-ebuild.
>
> The goal is not to have working Gentoo systems that contain nothing on
> their hard drives, but rather to eliminate the arbitrary collection of
> packages that must be present everywhere, because some software that
> might or might not even be installed could need them.

That arbitrary collection of packages is called a system. I don't think
the goal for Gentoo should be to abandon standards like POSIX in favor
of 'design system yourself but don't come crying to us if you forget
some vital component which will make your system unbootable'.

Such a goals may be good for distributions like Exherbo which aim to
make everything perfect. I believe that Gentoo aims more around 'good
enough but at least realistic', instead of running for some kind of
utopia which simply does not work.

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

On Fri, 31 Aug 2012 15:31:43 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> On Fri, 31 Aug 2012 18:03:33 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > 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.
> >
>
> Hu? You know, some people think pkgconfig is a poorman's workaround
> for a different problem. You don't need .pc files for dynamic linking
> because:
> 1) there is a standard include search path
> 2) there is a standard library path
> 3) elf shared objects support dependencies
>
> You might need pkgconfig for static linking because static archives do
> not support 3). Isn't it the thing that should be improved instead ?
>
> Alike you claim a library not providing a .pc is broken, I can claim
> that a library relying on it is broken because it is violating 1)
> and/or 2) which are well established unix behavior.

I'm not sure if you're aware of it but Gentoo doesn't aim at supporting
solely Linux and no other system.

Also, please tell me how to handle multiple slots sanely without
pkg-config in a package like Boost, for example.

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

On Fri, 31 Aug 2012 22:53:35 +0200
Michał Górny <mgorny@gentoo.org> wrote:

[...]
> I'm not sure if you're aware of it but Gentoo doesn't aim at
> supporting solely Linux and no other system.

elf != linux

>
> Also, please tell me how to handle multiple slots sanely without
> pkg-config in a package like Boost, for example.
>

You should know since you are proposing a boost-utils.eclass

Anyway, my point was just to go from 'not providing a .pc is broken' to
'.pc are useful and needed in some cases but not all'

A.
 

Thread Tools




All times are GMT. The time now is 02:36 PM.

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