This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Perl versioning (Was Re: Can upset handle more than one prev: tag?)


Igor schrieb:

> 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

5.8.0 was not threaded and the 5.8.0 package that was distributed is not
binary compatible with the 5.8.2 or later packages.  He upgraded from
5.8.0 to 5.8.5 where it is needed to rebuild the modules with threads
enabled.  Others like perl-libwin32 should work, just move the contents
around or add the path to perls @INC path settings.


> 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).

You are free to install your private modules whereever you want and add
the path to your specs.  Since private modules (site_perl path) are not
removed when uninstallling, it should be no problem to get perl to look
in the old paths too.  Read the docs how to do this.  I'm not a perl
teacher && all the magic is builtin in perl but not in my packages.

> 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?

No.  Perl 5.6.1 is stable (dead), it is not possible to rebuild it with
a modern compiler and modern Cygwin releases and I am not sure that
building modules for the old 5.6.1 with a 3.x compiler is working.

After all this discussion, I'm getting tired, I will remove the 5.6.1
tarball sooner or later, if your package depends on perl being 5 years
old, then your package is broken and needs to be fixed.

Older versions should be removed sooner, not later.

> I may not be articulating these thoughts very well, but I'd be glad to
> clarify it down to the concrete package layouts...

If you need more than one perl, build your own;)  It is possible to
build it with all the default settings and host it under /usr/local, you
may have several versions there, all is possible.  It lasts less than an
hour to build perl (including running the testsuite).  Just type
./Configure && make && make install and you are done in 30 minutes.


Another point is to use another name for the DLL in future (e.g.
cygperl-58.dll) so there would be no action needed for some package
maintainers if perl is upgraded from say 5.8.6 to 5.8.7.


Gerrit
-- 
=^..^=


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]