Another idea, if I may interject. A problem that I have had, and others have had, is that apt-get requires certain perl modules which must be loaded to handle certain things. Would it be too much to have these in perl-<version>-base? That way, if install problems do happen, and /usr/bin/perl gets overwritten with a new version, then apt will function properly as well.
APT could still provide a version for it's own upgrades, to maintain compatibility with it's own tree, but since perl is relied on so heavily by the package management system this would be a good thing(tm). Even better, perhaps these could be set as symlinks and perl could install it's own, 'stable' version of them in one outside directory, and apt-get could install it's own versions somewhere else, updating symlinks as nessicary? Are these updated often enough to deem this nessicary? I know this is a bit of an annoyance but it is the package management system after all. -- Erik Hollensbe <[EMAIL PROTECTED]> Programmer, Powells Internet Division "I respect a man who lets me know where he stands, even if he is wrong." - Malcolm X On Fri, 12 Jan 2001, Brendan O'Dea wrote: > On Thu, Jan 11, 2001 at 02:55:42PM +0100, J?r?me Marant wrote: > >Brendan O'Dea <[EMAIL PROTECTED]> writes: > > > >> I'm currently working on new 5.004 and 5.005 packages without > >> alternatives, and a new 5.6 which will conflict with the earlier > >> versions. > > > >Are tou going to reorganize perl 5.6 the way you proposed months ago ? > > Yes. I intend for the ``perl'' and subsidiary packages to provide the > current Perl version. > > Previous versions (5.004, 5.005 and presumably at some stage 5.6) will > have a version in the package name. > > I hope to upload the lot to a staging area in the next day or so. > > Regards, >
