On Tue, 30 Aug 2005, Brendan O'Dea wrote: > On Mon, Aug 29, 2005 at 04:22:38PM -0700, Don Armstrong wrote: > >Some modules don't require anything else but /usr/bin/perl, Carp, > >XSLoader, and Exporter... I can't forsee a version of perl-base that > >ever failed to include these modules (and actually included anything > >else.) > > You never know. One of these days I may get a rush of blood to the > head and intentionally remove some of the dead-wood from perl-base; > something which would be simpler if the affected package set was > small. Heh. If such a rush of blood happens, I'd be delighted if it was diverted to perl instead... ;-) > Additionally, packagers of modules are not as likely to test with > only perl-base installed, and hence not pick up problems of > additional dependencies added by new versions. The current set on > the other hand tends to be excercised fairly well by the installer > and upgrades. True; although, it really isn't all that difficult to test it in a chroot... but then again, SHIP IT!!11 > >[Of course, in the end, I and others can keep doing what we're doing > >and packaging separate versions of these packages for the thin devices > >that we deploy... it's just suboptimal.] > > Alternately, for your specific requirements you could use equivs to make > a fake perl package rather than repackaging all modules you require. Right, that's another alternative... the problem there is that modules that really do require perl will break when they're installed instead of tripling the size of the filesystem on the device like it does now.[1] Don Armstrong 1: Although, both of these could well be fatal... -- If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law http://www.donarmstrong.com http://rzlab.ucr.edu
Attachment:
signature.asc
Description: Digital signature