On Wed, 25 Aug 2004, Gerrit P. Haase wrote: > Igor schrieb: > > > On Tue, 24 Aug 2004, Gerrit P. Haase wrote: > > >> Christopher schrieb: > >> > >> > On Tue, Aug 24, 2004 at 03:36:33PM +0200, Gerrit P. Haase wrote: > >> >>I want to keep two prvious perl version available, now I need to know: > >> >>is more than one tag for 'prev:' or 'test:' in setup.hint files > >> >>supported and handled correct by upset? At least setup.exe seems to > >> >>have no problems with more than one [prev] tag in setup.ini. > >> > >> > I'm surprised that setup.exe has no problems with more than one prev > >> > but upset only maintains one level, so any setup.hint -> setup.ini > >> > translation will eat extra prev's. > >> > >> > Why do you think you need multiple previous versions? > >> > >> I stillkeep perl-5.6.1 at the mirrors for people who don't believe that > >> the new perl-5.8 is ok. Now I have updated to 5.8.5 and removed 5.8.2 > >> but got complaints because the postgres perl extension is linked against > >> 5.8.2 DLL. I need to rethink the package naming if it is not possible > >> to get mroe than one prev tag into setup.ini (automatically, as > >> mentioned it works well with setup.exe). > >> > >> Gerrit > > > Is there any reason why we can't have a perl561 or perl_5_6_1 package? > > It can definitely co-exist with perl-5.8.*, the library is already > > versioned, and the executables can have the 561, 5.6.1, or _5_6_1 > > suffix... > > Igor > > Yes, there is no reason to not rename the packages. I'll prepare an > update ASAP. Anyway, upset could be extended to handle several tags of > one type since setup already does it. Why not keep more than one > previous or several (different) test versions? > > Gerrit
Gerrit, Incidentally, since we're on the subject of Perl packaging, there was a question asked by someone on the main Cygwin list about the modules installed with one version of Perl being usable after upgrading. First off, since the x.y.* versions should be binary-compatible, why include the minor version number in the /usr/lib/perl5/x.y.* directory name? Same goes for the DLL name. Alternatively, a perl-migrate script could be included in the perl distribution which will migrate the modules in /usr/lib/perl5/* and /usr/lib/perl5/site-perl/* to the new directory names *if it is binary-compatible* (i.e., if upgrading from perl-5.8.0 to perl-5.8.5, but not from perl-5.6.1 to perl-5.8.2). Secondly, maybe splitting perl-5.6.* into a perl-bin-5.6.* and perl-lib-5.6.* will allow you to keep offering perl-lib-56-compat-5.6.* for those who have applications compiled using this version of perl, the way Cygwin/X kept the compat libs around? I may not be articulating these thoughts very well, but I'd be glad to clarify it down to the concrete package layouts... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw