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 10-04-2010, 12:42 AM
Luca Barbato
 
Default .la files and their future on Gentoo

On 10/04/2010 12:00 AM, Rémi Cardona wrote:

Using libltdl (libtool's dlopen wrapper) is a*legitimate* use of .la
files. Those programs do not need to be fixed as they are not broken.


To my knowledge ltdl would load just fine the .so if the .la isn't found.

lu

--

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
 
Old 10-04-2010, 12:48 AM
Luca Barbato
 
Default .la files and their future on Gentoo

On 10/03/2010 06:57 PM, Angelo Arrifano wrote:

<joke>
Was libtool deprecated or something? Judging by your reply, it really
made me think so.
</joke>


<joke>
once everybody moves to scons/ffconf/whatever sure
</joke>


The farther we walk from upstream, the greater is the quantity of work
we have to do to maintain their packages.


Well I consider the .la sort of legacy byproduct of libtool and not
something useful, probably in the future I'll send a patch to have the
.la put as last item in search order for both libtool and libltdl to
make it a non issue for everybody =P


lu

--

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
 
Old 10-04-2010, 01:26 AM
Duncan
 
Default .la files and their future on Gentoo

David Leverton posted on Sun, 03 Oct 2010 16:39:39 +0100 as excerpted:

> Also, not every piece of software that people might want to use is going
> to go into the main tree - people can use Gentoo to develop their own
> software (and might have their own ideas (or their company/project's
> ideas) about what parts of libtool it's appropriate to rely on), use
> packages from overlays, compile other people's software outside the
> package management system, run precompiled binaries, etc. Again, from
> here I'm sure you can have a big discussion about whether libraries in
> the tree exist only to support applications in the tree, or whether
> they're "products" (for want of a better word) in their own right.

The problem is that "in-tree" is a reasonably bounded set of builds, while
"out-of-tree" is unlimited. Practically speaking, I simply don't see how
Gentoo can be concerned with "out-of-tree" in general, altho there's
arguably a case that could be made for drawing the line /somewhat/ wider,
say including official overlays as well, but even that very quickly
becomes problematic as you're now expecting every dev with a candidate
package to be familiar with every overlay it might affect.

No offense intended, and you do sort of make the point yourself with the
"minor issue" thing, but arguably, this would be an /appropriate/ use of
flameeyes' "people opposed are simply throwing up illegitimate blockages"
complaint (where the binpkgs point wasn't, because that has long been a
supported feature of Gentoo's primary PM and while breaking it may indeed
be necessary, it's a legitimate point to raise).

OTOH, you do rightfully call it a minor point, perhaps one that shouldn't
be a blocker, but one that should at least be raised. Raising the point,
minor and non-block tho it may be, in the discussion of record is a /good/
thing. But I don't see how it's practical to do more than simply
acknowledge it and say we can't let that block it (... except).

EXCEPT that the centralized controlling variable solution, via a removal
method in EUTILS or the like, DOES make sense for any of a number of
reasons, including that (a) centralizing the implementation is a good idea
anyway, (b) once centralized, the implementation cost of a controlling
variable is quite low, and (c), that makes it easy enough to control it
either per-package or globally, using existing environment control
solutions.

But beyond that, and for sub-package-level control, I simply don't see
that it's practical.

But luckily, the above seems to fit your request as-is. =:^) And as for
sub-package-level, individual maintainers are still free to do what they
believe is necessary with their packages, anyway. (And for some packages
and usages it /is/ arguably necessary.)

--
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 10-04-2010, 06:35 AM
Michał Górny
 
Default .la files and their future on Gentoo

On Mon, 04 Oct 2010 00:00:22 +0200
RĂ©mi Cardona <remi@gentoo.org> wrote:

> #2a) pkg-config is one solution (what upstream Xorg says: "if you
> want a static libX11, use pkg-config --static"), other teams/herds
> could fix their packages' .pc files to correctly list all required
> packages for proper static linking. It's not rocket science.

AFAIK more .pc files rather need fixing to list only direct
dependencies when '--static' is not used. pkg-config itself takes care
of the dependencies pretty well.

--
Best regards,
Michał Górny
 
Old 10-04-2010, 07:00 AM
RĂ©mi Cardona
 
Default .la files and their future on Gentoo

Le 04/10/2010 08:35, Michał Górny a écrit :
> On Mon, 04 Oct 2010 00:00:22 +0200
> RĂ©mi Cardona <remi@gentoo.org> wrote:
>
>> #2a) pkg-config is one solution (what upstream Xorg says: "if you
>> want a static libX11, use pkg-config --static"), other teams/herds
>> could fix their packages' .pc files to correctly list all required
>> packages for proper static linking. It's not rocket science.
>
> AFAIK more .pc files rather need fixing to list only direct
> dependencies when '--static' is not used. pkg-config itself takes care
> of the dependencies pretty well.

Right, either way, .pc files usually need a little tweaking as devs
rarely touch them unless something is really broken. Patching (in
accordance with upstream of course) may be required.

But it's definitely my preferred solution (and a cross-platform one at
that!)

Cheers,

RĂ©mi
 
Old 10-04-2010, 03:19 PM
Richard Freeman
 
Default .la files and their future on Gentoo

On 10/03/2010 09:26 PM, Duncan wrote:
> The problem is that "in-tree" is a reasonably bounded set of builds, while
> "out-of-tree" is unlimited. Practically speaking, I simply don't see how
> Gentoo can be concerned with "out-of-tree" in general.

If any other distro had that attitude Gentoo (and other source-based
distros) would be the only ones that provided packages for GCC, since no
other distro requires a functioning toolchain to install packages.

Libraries don't exist just to run packaged programs - they're also
needed to build new programs. So, this is a use case that needs to be
considered. Probably one of the reasons that Gentoo is popular among
developers is that it provides a very complete toolchain and libraries/etc.

That said, supporting this use case should not interfere with more
mainstream use of the distro. I like the USE flag proposal because it
lets us have our cake and eat it too. Those who don't need .la files
don't get them except where absolutely essential, and those who need and
are willing to live with tons of them can have it their way.

Gentoo is about choice...

Rich
 
Old 10-05-2010, 01:55 AM
Diego Elio Pettenò
 
Default .la files and their future on Gentoo

Il giorno lun, 04/10/2010 alle 11.19 -0400, Richard Freeman ha scritto:
>
> That said, supporting this use case should not interfere with more
> mainstream use of the distro. I like the USE flag proposal because it
> lets us have our cake and eat it too. Those who don't need .la files
> don't get them except where absolutely essential, and those who need
> and
> are willing to live with tons of them can have it their way.

USE flags add complexity, and in real use cases there are near to no
good reasons at all to keep .la files around.

I don't want to sound like a douchebag, but can you (or anyone else
supporting the USE flag notion) explain what .la files actually do?

What I'm quite sure of is that about half the people who express their
opinion regarding .la files have no idea what they are used for, they
expect them to be some kind of magic problem-solving fairy dust. They
are not.

They are a legacy of older operating system and static linking notions;
they are also not magical enough as they are only consumed back by
libtool. And not all the packages out there use libtool to link the
final application even if they were to use autotools.


--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
 
Old 10-05-2010, 02:13 AM
Diego Elio Pettenò
 
Default .la files and their future on Gentoo

Il giorno sab, 02/10/2010 alle 19.54 +0000, Jorge Manuel B. S. Vicetto
ha scritto:
>
> With that goal in mind, I'd like to ask anyone with arguments about
> this
> issue to present them as a reply to this thread.

I'm going instead to link my latest blog post on the matter where I
summarised most of the points. Why a blog post? Because so I have it
available as reference for the future together with all the others.
Don't like that? Sorry, I don't care; I'm presenting information, if you
choose to not even look at it because I serve it via HTTP rather than a
mailing list, do state so; I'll make sure to ignore any of your opinions
in the future.

Now, stop with the less-than-friendly remarks, the content is at

http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points

Also, I would like to ask again that if you're going to argue "you never
know who might use them", you're going to have to actually understand
_what_ the files are used for, _which_ software uses them, and come up
with a use case for them, not a vague "oh there might be a project that
use them".

I might disagree with Nirbheek's assessment with the severity of the hit
on users (or rather, on the relative severity of it compared with the
alternative), but his reasoning is at least sound and based on real
concerns. Things like "taking in account what isn't in the
tree" (without actually having a clue on what .la files are for),
looking for "alternative approaches" (to do what, exactly?), or "fixing
what needs .la files" (why? if the package needs its own .la files to be
around and nothing else, just leave it be!) are not concerns that I care
about because they are not based on actual usefulness of .la files but
on vague ideas of either fending off the finding of a solution (I don't
want to know why, sincerely) or the idea that .la files are a binary
situation where you shouldn't have any at all.

From my point of view, the only points worth to be raised are Nirbheek's
(even though I disagree, as I said), RĂ©mi's (which I don't think he
either considers showstoppers at this point) and those not-yet-spoken
off by Prefix (they might support architectures where .la files are
worth something).

Other than that, do we really have a problem here? Nirbheek's point
about stable will become moot next month; since we shouldn't revert the
changes that did go to stable, we're left with two main issues here:

- is it okay to drop them from stable? my personal opinion here is to
side with Samuli and say "yes"; on the other hand, since by the looks of
it, and the status report Zac gave us, we're going to need just one
extra month before just telling users "install lafilefixer and update to
stable portage 2.1.9.13", I think we can avoid doing any more of those
changes till then — in stable that is; this includes both non-revbumps
and stable requests of packages dropping them;
- what about RĂ©mi's 2b concern? Sincerely I have worked for a long time
with static linking on my job and I don't see libtool files being so
excessively necessary; the only problem comes with transitive
dependencies, but most packages already take care of that; even if you
do not use pkg-config, you have other means to recover it.

On the other hand, I propose that if somebody have time on their hands
(I sincerely don't, unless somebody's going to hire me to, and I'm dead
serious), lafilefixer could be improved, and quick-stabled together with
the new portage in case, so that it saves the modified metadata in the
VDB.

--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
 
Old 10-05-2010, 04:58 AM
Duncan
 
Default .la files and their future on Gentoo

Richard Freeman posted on Mon, 04 Oct 2010 11:19:29 -0400 as excerpted:

> On 10/03/2010 09:26 PM, Duncan wrote:
>> The problem is that "in-tree" is a reasonably bounded set of builds,
>> while "out-of-tree" is unlimited. Practically speaking, I simply don't
>> see how Gentoo can be concerned with "out-of-tree" in general.
>
> If any other distro had that attitude Gentoo (and other source-based
> distros) would be the only ones that provided packages for GCC, since no
> other distro requires a functioning toolchain to install packages.

Interesting viewpoint. But I disagree that it is so. Rather, for binary
distros, while gcc and the rest of the toolchain may not be /required/ for
user-side maintenance of the distribution itself, they're certainly
packages that provide a specific set of functionality. As such, they're
included in general distributions where such functionality may be desired,
for much the same reason KDE or LAMP are included -- they are useful
enough for a wide enough segment of the userbase to justify inclusion.
OTOH, more specialized distributions may not include them, because they're
simply not needed for the designated target usage.

In gentoo-speak, binary distributions include toolchain packages not as
part of @system, but for those who wish to use them in their @world.

If Gentoo were therefore to take a binary distro approach, we'd do split-
packages. Much as the binary distros have package-x and package-x-dev
(which I'd guess include the *.la files, BTW), we'd have package-x and
package-x-la, or some such.

Of course, the gentoo version of that is USE flags, FEATURES, etc. Which
means we're "in violent agreement!" =:^) and brings us back to...

> I like the USE flag proposal because it lets us have our cake and eat it
> too. Those who don't need .la files don't get them except where
> absolutely essential, and those who need and are willing to live with
> tons of them can have it their way.
>
> Gentoo is about choice...

The key-variable (whether USE flag, FEATURE, or a bit more hidden) based
trigger does seem the pragmatic solution here.

Flameeyes, yes, I understand your objection to it on technical grounds as
unnecessary complexity. And I freely admit I'm not technically astute
enough (in reality, probably few Gentoo devs are, with certain noted
exceptions, of course) to debate you on the merits, there. On the
technical side, AFAIAC [1] you win by stipulation.

But there's more to life than being technically correct. A centralized
la-file-stripper implementation seems to make sense in any case, and once
it's centralized, exposing a control variable for it is little additional
trouble. Given the choice between allowing for the control variable in
ordered to establish the necessary consensus and getting it deployed in
months, vs either continuing to debate it for years or simply steamrolling
it thru without that option, whatever the technical merits, I agree with
rich0, the control variable seems the /clear/ winner, here.

Assuming that's the way it ultimately goes, what remains is to settle on
the nature of the control variable. There are merits in something
slightly hidden, but OTOH, the USE flag idea has merits of its own. It
seems to me that the usual solution in similar cases is a USE flag, but
masked. So count this as a vote for a masked USE flag. =:^)

---
[1] AFAIAC: As Far as I am concerned:
http://www.onelook.com/cgi-bin/cgiwrap/bware/dofind.cgi?word=AFAIAC

--
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 10-05-2010, 06:18 AM
Ciaran McCreesh
 
Default .la files and their future on Gentoo

On Tue, 05 Oct 2010 04:13:04 +0200
Diego Elio Pettenň <flameeyes@gmail.com> wrote:
> I'm going instead to link my latest blog post on the matter where I
> summarised most of the points. Why a blog post? Because so I have it
> available as reference for the future together with all the others.
> Don't like that? Sorry, I don't care; I'm presenting information, if
> you choose to not even look at it because I serve it via HTTP rather
> than a mailing list, do state so

I believe one of the larger objections to you providing information via
blog posts is that comments with constructive criticism or tricky
questions have a mysterious habit of not showing up there.

> I'll make sure to ignore any of your opinions in the future.

Unfortunately for Gentoo, many of the opinions you routinely ignore
happen to be useful ones.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 03:12 AM.

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