Re: Triggers on file patterns (similar to bug #553266)
On Wed, 10 Aug 2011 15:31:20 0200, Raphael Hertzog wrote:
Hi,
>
> On Wed, 10 Aug 2011, Sjors Gielen wrote:
> > But there's one piece missing: Mac OS X has its own solution for the
> > linking of libraries, which conflicts with libtool's "dependency_libs"
> > in all .la files (I don't completely know the internals). This has
> > always been solved by modifying all .la files that packages install and
> > clearing the dependency_libs statement before actually installing the
> > .la files. We can't simply patch libtool either, because it's installed
> > on the system, not by Fink itself.
>
> Then you will be glad to learn that Debian is dropping .la files when
> possible and emptying dependency_libs when not possible.
>
> http://wiki.debian.org/ReleaseGoals/LAFileRemoval
>
> In any case, I don't agree that the modification of those .la files
> should happen at installation time with a trigger. It's something
> that should be done at build time.
>
> To avoid having to modify all packages, I would much prefer that
> you provide a patch for http://bugs.debian.org/570934 and decide
> to use that new feature to clear dependency_libs in the remaining .la
> files.
>
> That way we're not introducing a discrepancy between the installed file
> and the checksum recorded in the md5sums file, and we're not pushing the
> cost of doing the modification to all users.
>
> Would this work for you? I guess so since you have to rebuild the packages
> anyway, isn't it?
Bit of history/context for the current feature in fink (which I
wrote)--rationale for current implementation and why the Debian
approaches (file removal and build-system magic) aren't suitable.
First, fink doesn't have periodic system-wide release-levels the way
Debian does, so we don't have an opportunity to push out a whole new
set of packages (rebuild across-the-board) with a self-consistent new
policy or release a full binary collection built to a specific
point-distro policy. Rather, users update packages on their own
schedule and may be running (within the limits of Depends) specs a wide
mix of latest release of a library but year-old reverse-dependencies
still present). As a result, we use the current implementation to avoid
causing breakage for users and maintain control over the .deb contents
(at the expense
of installed files not matching the .deb). It's a fatal error if a .la
disappears but another still points to it via dependency_libs , so we
took the data-cleaning approach rather than deleting the files
themselves.
Doing it at build-time would entail bumping the Revision (fink takes a
strong policy stand on "same name-version-revision sound gives same
.deb binary" consistency). Altering the build system would be
technically easy but break that policy, and we couldn't be assured by
*any* technical means that a user would have the "improved" .deb
installed. The change would therefore have to be done on a per-package
("opt-in") basis by adding some explicit token to the source package
build recipe. The rev-up would cause all users to do lots of rebuilding
(fink is largely build-from-source by end-users not binary distro) for
no gain (from their perspective). The change had to happen for all (or
at least many hundreds of) packages "soon" because having all that .la
data was holding up a bunch of other development. So the automatic
PostInst (pushed out before dpkg had stabilized the actual "triggers"
feature IIRC, but we'd love to use an upstream feature instead of local
tricks!) handled it all cleanly: guaranteed system-wide removal of .la data
without requiring rebuilding.
We could easily add a build-recipe control, which maintainers could add
when packages are being updated for other reasons (i.e., users are
rebuilding anyway) and maybe even could hurry this out for the fresh
packages being added to the 10.7 collection, but we're still years away
from dropping older systems' collections that are relying on having .la
but having an easy automatic way to clear their data.
dan
--
Daniel Macks
dmacks@netspace.org
Reply to: