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, 11:05 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Fri, 31 Aug 2012 17:49:34 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> 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

Gentoo != elf only.

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

Eh, the world would be so much better if boost provided pkg-config
files.

For example, boost.m4 (provided by boost-m4) uses some wall-dumb
stubborn heuristics which always grabs newest boost and doesn't provide
any sane way to provide it with an older one...

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

But these some cases where there are needed result in the necessity
of installing them, and making the build systems aware of them. I don't
see much point in adding a 'backwards compatibility' to it as well.

Ah, while we're at it. If a library has macros referring
to the functions of another library (or just types) in its public API,
it needs a pkg-config file. ELF dependencies are not enough,
and the gold linker will refuse to work because of a missing explicit
dependency.

--
Best regards,
Michał Górny
 
Old 08-31-2012, 11:13 PM
"Gregory M. Turner"
 
Default prune_libtool_files() and pkg-config dependency

On 8/31/2012 4:48 AM, Rich Freeman 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.


My 2c on this:

I'm reluctant to make "sweeping statements" like this, for any number of
reasons, but -- well, I'm gonna.


IMO, getting there by slow evolution is not the right way. At some
point, @system becomes so primitive that bootstrapping must come to
depend on more than @system, or we have to add add more "phases" to the
bootstrap process, or split @system up into smaller sets or something.


The point is, we can't gradually reach a goal that's incompatible with
the fundamental premise. It's all well and good to say "let's not put
more stuff into @system because we want it to shrink," but, as it
stands, there's a de-facto policy that @system includes everything
needed to have a reasonably functional Gentoo, including all of the
compilers, development tools and interpreters portage, gcc, and your rc
system of choice rely on. Until that fundamentally changes, IMO what
belongs in @system is whatever best suits its current purpose.


For the record, I'm not saying we need to put pkgconfig in - I'm totally
agnostic about that, as I am about whether it should be brought in as a
dependency.


I just mean, probably the best way to fix the fat-@system problem is to
create some kind of vision for a more-modular "Gentoo of the Future"
first, and create a roadmap for getting there, second.


Its possible, perhaps even likely, that if we try to go the incremental
route towards @system reduction, we will find, along the way, creative
solutions to the various issues that have kept it fat-ish so far. But
that's likely to lead to a fairly ad-hoc patchwork of hacks, which imo
would most likely be inferior to what could be achieved with some kind
of destination in mind (even if that destination is subject to major
revision as Gentoo progress toward it).


-gmt
 
Old 08-31-2012, 11:59 PM
Duncan
 
Default prune_libtool_files() and pkg-config dependency

Gregory M. Turner posted on Fri, 31 Aug 2012 16:13:20 -0700 as excerpted:

> For the record, I'm not saying we need to put pkgconfig in - I'm totally
> agnostic about that, as I am about whether it should be brought in as a
> dependency.

[Just replying here as it's handy.]

I don't believe the following bit has been explicitly stated yet. I'm
not sure if it's sufficiently implicit that it doesn't need stated for
not, but in case it helps:

The effect of adding pkgconfig to @system is just this: Currently, we
have an explicit list of all packages that need it (barring missing
dependency bugs, of course). If it gets added to @system, that list
immediately gets decimated, and while its historical value can always be
dug out of the VCS (as long as the git upgrade or whatever doesn't lose
that information, anyway), it's no longer being updated and will quickly
go stale, so when the time comes and we DO decide to finally seriously
tackle @system removal, that's one more dependency that we have to go to
(excuse the shouting) ALL THE WORK OF RECREATING THE DATA WE CURRENTLY
HAVE, ALL OVER AGAIN.

We have that data for pkgconfig now, and currently, it must be maintained
in at least a semi-reasonable state. If we ever DO get serious about
@system removal, we'll definitely need that data. So let's not go
voluntarily dumping it down the toilet, which is what adding pkgconfig to
@system would amount to, only to decide we actually need that data after
all, but by then it'll be gone, so we'll have to recreate it from
scratch. That's what all this is about, not adding yet another package
to the list of packages we don't HAVE proper dependency data for, data
that we'll have to create from scratch if we ever do decide to move on
the @system removal thing, when for this package at least, we already HAD
it, and will have deliberately thrown it away by adding the package to
@system.


If it was as simple as just adding it to the list, and we weren't
throwing away a quite valuable bunch of already accumulated dependency
data as a result, sure, no problem, go right ahead. Unfortunately...

--
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 09-01-2012, 12:14 AM
Alexis Ballier
 
Default prune_libtool_files() and pkg-config dependency

On Sat, 1 Sep 2012 01:05:39 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 31 Aug 2012 17:49:34 -0400
> Alexis Ballier <aballier@gentoo.org> wrote:
>
> > 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
>
> Gentoo != elf only.

Prefix? Come on, some usecases do not make pkgconfig so vital for every
gentoo install that it should be in @system.

> > > 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
>
> Eh, the world would be so much better if boost provided pkg-config
> files.
>
> For example, boost.m4 (provided by boost-m4) uses some wall-dumb
> stubborn heuristics which always grabs newest boost and doesn't
> provide any sane way to provide it with an older one...

Yes, pkgconfig can be useful, sometimes...

> > 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'
>
> But these some cases where there are needed result in the necessity
> of installing them, and making the build systems aware of them. I
> don't see much point in adding a 'backwards compatibility' to it as
> well.

If the build system needs pkgconfig then the ebuild should depend on
it, whats wrong with that ? I dont need pkgconfig to run the package
after its built. For the same reason people have been working to
_remove_ flex, m4, bison, autoconf, automake from @system, pkgconfig
does not belong there either...

> Ah, while we're at it. If a library has macros referring
> to the functions of another library (or just types) in its public API,
> it needs a pkg-config file. ELF dependencies are not enough,
> and the gold linker will refuse to work because of a missing explicit
> dependency.

Eh, straight to the point where pkgconfig is not the solution to
everything: a binary not using said macros but trusting pkgconfig will
get overlinked. Documentation stating that when using these
macros/functions one should link to the other lib would make things
even better.

A.
 
Old 09-01-2012, 03:50 AM
Ryan Hill
 
Default prune_libtool_files() and pkg-config dependency

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

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

"Gentoo" is actually an old Navaho word meaning "some assembly required,
batteries not included". You thought it was a penguin?

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

I don't understand your stance here, because to me 'good enough but
realistic' means ignoring standards when they're stupid, embracing them when
they're not, and forging your own where they don't yet exist. Perfection, by
definition, requires an existing standard to hold yourself up against.


--
gcc-porting
toolchain, wxwidgets we were never more here, expanse getting broader
@ gentoo.org but bigger boats been done by less water
 
Old 09-01-2012, 07:40 AM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

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

> > Ah, while we're at it. If a library has macros referring
> > to the functions of another library (or just types) in its public
> > API, it needs a pkg-config file. ELF dependencies are not enough,
> > and the gold linker will refuse to work because of a missing
> > explicit dependency.
>
> Eh, straight to the point where pkgconfig is not the solution to
> everything: a binary not using said macros but trusting pkgconfig will
> get overlinked. Documentation stating that when using these
> macros/functions one should link to the other lib would make things
> even better.

The macros/types can change over time. Maintaining all indirect
dependencies is not friendly nor useful.

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

On Sat, 1 Sep 2012 09:40:47 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 31 Aug 2012 20:14:43 -0400
> Alexis Ballier <aballier@gentoo.org> wrote:
>
> > > Ah, while we're at it. If a library has macros referring
> > > to the functions of another library (or just types) in its public
> > > API, it needs a pkg-config file. ELF dependencies are not enough,
> > > and the gold linker will refuse to work because of a missing
> > > explicit dependency.
> >
> > Eh, straight to the point where pkgconfig is not the solution to
> > everything: a binary not using said macros but trusting pkgconfig
> > will get overlinked. Documentation stating that when using these
> > macros/functions one should link to the other lib would make things
> > even better.
>
> The macros/types can change over time. Maintaining all indirect
> dependencies is not friendly nor useful.
>

So in this hypothetic case where your lib changes its ABI and API, it
is not friendly and seen useless by consumers, I think I agree
 
Old 09-01-2012, 12:29 PM
Rich Freeman
 
Default prune_libtool_files() and pkg-config dependency

On Fri, Aug 31, 2012 at 11:50 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Fri, 31 Aug 2012 22:51:08 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>> 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.
>
> I don't understand your stance here, because to me 'good enough but
> realistic' means ignoring standards when they're stupid, embracing them when
> they're not, and forging your own where they don't yet exist. Perfection, by
> definition, requires an existing standard to hold yourself up against.

In any case, I wasn't suggesting that a typical user would run without
POSIX. I just think that we'd be better off if our dependencies were
fully specified which will aid those doing unusual things with Gentoo.

Keep in mind that unusual unix-like implementations are all around us.
I doubt a Tivo even has a shell installed, and a typical Android
phone has a very non-traditional set of tools available.

I think the default Gentoo install should be pretty similar to what it
is today. However, more flexibility to deviate isn't a bad thing.

That said, having fully specified dependencies without giving
headaches to maintainers is also a good goal. I think that absent
better tools @system is always going to have to be a compromise.

Rich
 

Thread Tools




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

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