On Sun, Apr 19, 2015 at 02:25:55PM +0200, Axel Beckert wrote: > Niko Tyni wrote: > > Cons: > > E increased memory usage on systems running multiple perl processes > > F possibly increased startup time for short perl scripts > > (but that may be a non-issue due to caching anyway?) > > This sounds rather concerning to me. The again, I've never noticed any > issues on i386 and kfreebsd-i386.
Right. I suspect the choice between static and dynamic linking doesn't matter much on most systems in the real world, but I'd be interested in arguments to the contrary. > Since you wrote in #781476 that both, statically and dynamically > linked perl binaries are built anyways and then one is thrown away > depending on the architecture, what about letting the user > respectively administrator choose? I think this is overkill and we don't need more choice here. > Either by > > * shipping both in the perl package and using /etc/alternatives/perl > to choose between the two (perl-dynamic and perl-static) for > /usr/bin/perl, or Even though update-alternatives is nowadays written in C and not Perl, I still wouldn't trust the alternatives system enough to handle Essential:yes functionality. > * by providing two conflicting packages perl-base and > perl-base-static. dpkg cries loudly (and rightly so) if you try to remove an Essential:yes package like perl-base. What I could do is to ship the dynamically linked binary separately as something else than /usr/bin/perl, as it's basically just a tiny wrapper for libperl. It's a bit tempting to put it in libperl5.20 and anticipate future Multi-Arch:same libperl packages by naming it /usr/bin/perl-x86_64-linux-gnu or something like that... -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150420183217.GA13981@estella.local.invalid
