As those who _did_ ask me directly why I decided to do this did not think it was worth mailing - as they didn't - I suppose I should chime in now.
Leaving alone what Petteri already said, this was intended to be a change on a series of single packages, the domino effect that happened I didn't foresee, on my system it was just a matter of five packages and a quick look at the revdeps didn't show _such_ an effect. Well maybe I expected a few problems with libogg, but yeah that doesn't seem to be the problem here, the problem seems to be with popt. For what popt is used (parsing of command-line options) I didn't expect it to creep in in so many libraries. And as the problem does not break any system - systems will still run perfectly - and can be solved with ease - just run a revdep-rebuild - I did consider this a pretty minor drawback on the whole. libogg and popt are now masked, and they'll wait a bit before return to ~arch that way. libmpcdec, libmad have very few library users so I don't expect major problems with those and I left them untouched. Same for libpam which should really _not_ be used by libraries beside a few very rare cases, if it was there is something _very_ broken. Probably the best thing would be to get a better tool than revdep-rebuild to handle broken .la files, as revdep-rebuild forces a timewasting rebuild, while a good fix could be just a sed -i -e 's:/usr/lib\(64\)\?/lib\(.*\).la:-l\2:' on all the .la files, installed and being-installed. By the way, asking a question is not poisonous. "Wulf C. Krueger" <[EMAIL PROTECTED]> writes: > Especially since even though removing .la files might make sense (with > exceptions, of course) we should think about either doing it > distribution-wide or not at all. Can't be done distribution-wide, as stuff would break way worse than this for sure (stuff is not going to link, or will fail at runtime). You _have_ to do it on a case-by-case basis. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/
pgpA75CPKwsyT.pgp
Description: PGP signature
