| www.delorie.com/archives/browse.cgi | search |
Gerrit P. Haase wrote: >>Okay, *two* more things: you may want to package this "the right way" >>from the beginning -- and avoid the pain I (and everyone else by proxy) >>went thru. Split out your DLLs from everything else and have two >>packages...'netpbm' and 'libpnmXX'. That way, when user bob builds >> > > Ohoh, that makes me nervous... > > If a new perl package gets released I probably should also release a > 'libperl-5.6.1' package which contains only the libperl-5.6.1.dll ? > Probably not - and here's why: (1) the DLLs are already versioned down to the micro level (2) anybody cluefull enough to actually build something against the perl DLL is cluefull enough to save the DLL version they need for their private package 'foo' before upgrading perl. Actually, given the interdependencies in /usr/lib/perl5/5.6.1/... I don't think the DLL is much use, without all the other stuff under /usr/lib/perl5/5.6.1/... So, in the case of perl, I don't think it makes much sense to split the DLL from the rest of the package. OTOH, allowing two perls to coexist might be a reasonable thing...perhaps the parrot should be released as 'perl6-6.x.y' and not 'perl-6.x.y'. --Chuck
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |