On Tue, Aug 11, 2009 at 08:05:00AM +1000, Erik de Castro Lopo wrote: > Peter Samuelson wrote: > > > [Erik de Castro Lopo] > > > I'm think I'm coming in rather late on this, but why were these .la > > > files removed? I've read through bug#539687 and its still not clear. > > > > I can't speak for Ron,
Sorry Peter, I trimmed the cc list on my reply to Erik about this, I figured that nobody on -release actually needed this explained to them and it would just be noise there. > > but in general, the reason to remove .la files > > is that pkg-config (and the .pc files in /usr/lib/pkgconfig) offers the > > same functionality, and more, with considerably less brokenness. > > I'm a big fan of pkg-config. Its a good solution to the problem. Just to be clear, this has nothing to do with pkg-config at all. Using pkg-config isn't an "alternate solution" to "the problem", since there is no problem that the .la are solving for us here. I could remove the .pc files for this lib too, and it would still be perfectly functional, but that could be genuinely disruptive and may require some people to edit their source, so I'm not currently planning that. Even if I do think it's a gross overkill for this particular package to be using it in the first place. > > We'd > > like to encourage upstreams to ship .pc files and use pkg-config in > > their configure.ac scripts as the primary means of detecting the > > presence of other libraries and how to use them. > > And libsndfile has been using pkg-config for detecting all the libraries > it uses for at least three years. On any system with a functional linker and properly installed libraries (ie. every Debian system), ALL you need for this library is '-logg'. That's it. If you want to use Big Hammer infrastructure, designed for horrors like gtk dependencies, and a more complex incantation to get that, then that's your choice. But you don't _need_ any of those things to use this library. > The problem is that using the default pkg-config/autoconf/automake/libtool > behaviour to detect libxyz that ships libxyz.la file will create a > (probably unnecessary) dependency on that libxyz.la file. Definitely unnecessary, and its only libtool doing that. It will however also work perfectly fine if it doesn't find a libxyz.la -- it's only when it _does_ find one that the problems begin. > I know this is 20/20 hindsight, but this could have been handled much > better by raising bugs against and fixing all the client libraries > *before* removing the libogg.la. Given that a good proportion of them seem to be abandoned/unmaintained at present, that wasn't going to work very well at all. This however is going to shake those out relatively quickly and hopefully we can correct that for a while again. Sorry if we erred on the side of including your package in that group but looking through some of the bug reports did give the impression that you were much more active on it than its listed maintainer, and that patches and suggestions from you and others weren't being acted on, in a timely manner or at all. It's also not entirely necessary for all client libraries to have their own .la files removed, however much we may recommend this, and there may even be some extremely rare case where it is actually needed for one of them. As a minimal fix, they just need to be rebuilt with no libogg.la present -- and that can't really be done _before_ libogg.la is removed. > It would probably also be a good idea > to discourage the shipping .la files in the debian policy manual and > adding it as a lintian warning. I'd agree with that. I don't know why it's never been done, this has been "common knowledge" among a lot of people for a very long time now (ie. since before the turn of the century). But that said, I don't see a particular urgency in forcing people to do this, and indeed I've no intention of forcing you to remove yours if you don't want to. But I would recommend that you do, and I'm removing them from any packages that I maintain, so that when they do cause problems, they are someone else's problem, not mine. I'm accepting responsibility for coordinating this transition, since that is of my doing, but that's a one-off, not something that is going to come out of nowhere and bite me later. Ron -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
