Thomas Bushnell BSG wrote: > On Mon, 2008-08-25 at 21:54 +0100, Rob Canning wrote: > >> does this mean all this is needed is a modification to the debian >> controlfile? >> this would be great as if texlive-base is not a dep then lilypond should >> be small enough to fit on our live distro :) >> > > No, we're actually using kpsewhich. I would be happy to put in a > different solution, but not to ignore the problem. > > thanks for your reply thomas,
hi, so let me see ... the debian package lilypond-data has a pre-depend of texlive though lilypond no longer has a runtime dependency on tex this is because as thomas explained : > When the package is upgraded, the old > automatically generated fonts need to be cleaned up, and we are using > kpsewhich to find them in order to delete them. i dont fully understand why this is a pre-depend and not a build-depend when a debian is upgraded is it not just removed and reinstalled? is there a difference between upgrade time and build time? when are these fonts generated? during runtime or buildtime? is it not the job of the old lilypond-data to cleanup after itself rather than the new version doing the clean up? are the consequences of not cleaning these files up significant compared with the implications of relying on what should no longer be a dependency. sorry to ask what maybe completely uninformed questions i just dont really understand what is going on :) its just that texlive-base is so huge it means lilypond cant be included on a debian based live cd - can anyone think of a way to do what kpsewhich utilising lower level tools ? or is there a way that maybe this clean up can be rendered unnecessary, perhaps whatever creates the fonts in the first place should clean up after itself? many thanks, rob > Note that it won't get into lenny regardless. sid would be great if at all possible :) _______________________________________________ lilypond-user mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-user
