This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Perl versioning (Was Re: Can upset handle more than one prev: tag?)
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/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,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