[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Fedora-packaging] Re: libtool(.la) archive policy proposal



On Sat, Oct 14, 2006 at 03:53:01AM -0300, Alexandre Oliva wrote:
> On Oct 13, 2006, Enrico Scholz <enrico scholz informatik tu-chemnitz de> wrote:
> 
> > aoliva redhat com (Alexandre Oliva) writes:
> >>> no; 'libbar.la' might be used by a 'libbaz.la' loadable module which
> >>> is added to the repository a year later by a different maintainer.
> >> 
> >> Not if libbar.la was not installed.
> 
> > So you suggest to avoid packaging of .la files?
> 
> I understand that was the proposal on the table, and I don't see
> reasons against that given the constraints exposed so far.  It's not
> my suggestion, and I wouldn't say I actively promote it, but I don't
> mind it, and I did mind arguments that were brought up against it, so
> I voiced my opinion against the arguments ;-)

How about fixing the issues we *think* we have with *.la files
upstream, so that we don't even have to undo what libtool does?
Alexandre seems to have the best insight of libtool and our issues
with *.la around here, so he could setup the specs of what we'd like to
see improved in libtool and open up a dialogue with the current
libtool maintainers.

The outcome for me is that the "drawback" of keeping *.la files
unconditionally is that some *.devel files get a couple too many BRs,
and a very few (like kdelibs) get a dozen too many. That doesn't break
any minimal buildroots, it simply adds a few seconds during build
time (note that the non devel parts of the dependent libs are installed
during the builds anyway).

Compared to that we have random breakage in some packages eating up
developer and user time and endless discussions on lists. So let the
build systems spend a couple of CPU seconds instead. ;)
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpQtOwkDQLx8.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]