Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
As long as we're going through all FC4 perl modules, we might as well add this to all packages too. Just confirming, is this wanted in *ALL* packages that need perl, both regular arch and noarch?
Warren Togami wtogami@redhat.com
On Wed, 30 Mar 2005 23:07:55 -1000, Warren Togami wrote:
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
As long as we're going through all FC4 perl modules, we might as well add this to all packages too. Just confirming, is this wanted in *ALL* packages that need perl, both regular arch and noarch?
Certainly for all Perl module packages which install files into versioned Perl vendor lib locations (or site lib, although that should not be done). That's the only way to ensure that the main "perl" actually supports loading from those versioned directories.
On Thu, 31 Mar 2005, Michael Schwendt wrote:
On Wed, 30 Mar 2005 23:07:55 -1000, Warren Togami wrote:
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
As long as we're going through all FC4 perl modules, we might as well add this to all packages too. Just confirming, is this wanted in *ALL* packages that need perl, both regular arch and noarch?
Certainly for all Perl module packages which install files into versioned Perl vendor lib locations (or site lib, although that should not be done). That's the only way to ensure that the main "perl" actually supports loading from those versioned directories.
One important point, you are (or have been) effectively dropping support for every distro prior to FC1. Also perl offers compatibility with multiple versions, I guess that's why you want this (so a perl security bug allows you to ship a newer perl instead of backporting the fix).
I'm not sure if the advantage of this strict/loose dependency weighs up against the disadvantage of dropping everything that came before FC1.
I don't see a problem with no versioned dependency, since the only case where this really is a problem is when people install a package from another place (you don't have control over that anyway) or Fedora Extras ships suddenly without some perl module.
If there was no disadvantage I would probably embrace this as much as the next guy.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Thu, 31 Mar 2005 15:02:19 +0200 (CEST), Dag Wieers wrote:
On Thu, 31 Mar 2005, Michael Schwendt wrote:
On Wed, 30 Mar 2005 23:07:55 -1000, Warren Togami wrote:
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
As long as we're going through all FC4 perl modules, we might as well add this to all packages too. Just confirming, is this wanted in *ALL* packages that need perl, both regular arch and noarch?
Certainly for all Perl module packages which install files into versioned Perl vendor lib locations (or site lib, although that should not be done). That's the only way to ensure that the main "perl" actually supports loading from those versioned directories.
One important point, you are (or have been) effectively dropping support for every distro prior to FC1.
No. That's what the perl-forward-compat package has been for:
http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-co...
On Thu, 2005-03-31 at 15:12 +0200, Michael Schwendt wrote:
On Thu, 31 Mar 2005 15:02:19 +0200 (CEST), Dag Wieers wrote:
One important point, you are (or have been) effectively dropping support for every distro prior to FC1.
No. That's what the perl-forward-compat package has been for: http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-co...
There's also http://bugzilla.fedora.us/show_bug.cgi?id=1498 for RH 7.3, but nobody has been interested enough to import it to Legacy.
On Thu, 31 Mar 2005, Michael Schwendt wrote:
On Thu, 31 Mar 2005 15:02:19 +0200 (CEST), Dag Wieers wrote:
On Thu, 31 Mar 2005, Michael Schwendt wrote:
On Wed, 30 Mar 2005 23:07:55 -1000, Warren Togami wrote:
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
As long as we're going through all FC4 perl modules, we might as well add this to all packages too. Just confirming, is this wanted in *ALL* packages that need perl, both regular arch and noarch?
Certainly for all Perl module packages which install files into versioned Perl vendor lib locations (or site lib, although that should not be done). That's the only way to ensure that the main "perl" actually supports loading from those versioned directories.
One important point, you are (or have been) effectively dropping support for every distro prior to FC1.
No. That's what the perl-forward-compat package has been for:
http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-co...
Seems reasonable, only that it is yet again different than how it is handled with python. I know the situation is a bit different, but the implementation is completely different. (naming and how versioning works)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Sat, 2 Apr 2005 05:26:40 +0200 (CEST), Dag Wieers wrote:
One important point, you are (or have been) effectively dropping support for every distro prior to FC1.
No. That's what the perl-forward-compat package has been for:
http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-co...
Seems reasonable, only that it is yet again different than how it is handled with python. I know the situation is a bit different, but the implementation is completely different. (naming and how versioning works)
Yes, it's different, but it was subject to public discussion [1], and none of the few people who had comments disagreed strongly.
With the new and automated 'python(abi) = ...' dependency in FC4 devel, the solution on the Python side has become even more different, btw.
Michael Schwendt wrote:
On Sat, 2 Apr 2005 05:26:40 +0200 (CEST), Dag Wieers wrote:
One important point, you are (or have been) effectively dropping support for every distro prior to FC1.
No. That's what the perl-forward-compat package has been for:
http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-co...
Seems reasonable, only that it is yet again different than how it is handled with python. I know the situation is a bit different, but the implementation is completely different. (naming and how versioning works)
Yes, it's different, but it was subject to public discussion [1], and none of the few people who had comments disagreed strongly.
With the new and automated 'python(abi) = ...' dependency in FC4 devel, the solution on the Python side has become even more different, btw.
MODULE_COMPAT was designed to allow for distinctions of more than just the version (which is all python-abi does). This is necessary for perl and not python because it is possible to rebuild perl in different ways that breaks ABI compat, while python is almost entirely noarch. This happened with the perl package IIRC in the RH8-RH9-RHEL3 timeframe.
Since then however perl has not broken ABI (?), so it seems that we have this seemingly overcomplicated construct. But if we do break ABI again like in FC5 because we recompile the same version of FC4 perl with some new flag, MODULE_COMPAT can enforce exact deps and prevent incompatible FC4 packages from being installed on FC5.
Chip put a lot of thought into designing this.
Warren Togami wtogami@redhat.com
On Sun, 03 Apr 2005 02:04:44 -1000, Warren Togami wrote:
MODULE_COMPAT was designed to allow for distinctions of more than just the version (which is all python-abi does). This is necessary for perl and not python because it is possible to rebuild perl in different ways that breaks ABI compat, while python is almost entirely noarch. This happened with the perl package IIRC in the RH8-RH9-RHEL3 timeframe.
Since then however perl has not broken ABI (?), so it seems that we have this seemingly overcomplicated construct. But if we do break ABI again like in FC5 because we recompile the same version of FC4 perl with some new flag, MODULE_COMPAT can enforce exact deps and prevent incompatible FC4 packages from being installed on FC5.
Chip put a lot of thought into designing this.
I've thought the perl(:WITH_FOO) virtual provides define the Perl ABI requirements and not perl(:MODULE_COMPAT_...).
Warren Togami wrote:
Since then however perl has not broken ABI (?), so it seems that we have this seemingly overcomplicated construct. But if we do break ABI again like in FC5 because we recompile the same version of FC4 perl with some new flag, MODULE_COMPAT can enforce exact deps and prevent incompatible FC4 packages from being installed on FC5.
[root@fedora64 perl5]# ls 5.8.0 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.8.6 site_perl vendor_perl [root@fedora64 perl5]# pwd /usr/lib64/perl5
Hmm, FC4 still continues to have symlinks going back to 5.8.0 (RHEL3). I think this is a mistake. We haven't maintained ABI compat that long right?
Dirs should have been removed when they are known to be incompatible.
Warren Togami wtogami@redhat.com
On Sun, 2005-04-03 at 15:19 -1000, Warren Togami wrote:
[root@fedora64 perl5]# ls 5.8.0 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.8.6 site_perl vendor_perl [root@fedora64 perl5]# pwd /usr/lib64/perl5
Hmm, FC4 still continues to have symlinks going back to 5.8.0 (RHEL3). I think this is a mistake. We haven't maintained ABI compat that long right?
What makes you think so?
Dirs should have been removed when they are known to be incompatible.
Yes, but do we _know_ some of the above are incompatible?
Ville Skyttä wrote:
On Sun, 2005-04-03 at 15:19 -1000, Warren Togami wrote:
[root@fedora64 perl5]# ls 5.8.0 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.8.6 site_perl vendor_perl [root@fedora64 perl5]# pwd /usr/lib64/perl5
Hmm, FC4 still continues to have symlinks going back to 5.8.0 (RHEL3). I think this is a mistake. We haven't maintained ABI compat that long right?
What makes you think so?
Dirs should have been removed when they are known to be incompatible.
Yes, but do we _know_ some of the above are incompatible?
I recall Chip mentioning ABI broke sometime after 5.8.0. Maybe I'm wrong...
Warren
On Sun, 2005-04-03 at 23:51 -1000, Warren Togami wrote:
I recall Chip mentioning ABI broke sometime after 5.8.0. Maybe I'm wrong...
No, you're right, I forgot. man perl582delta or http://search.cpan.org/dist/perl/pod/perl582delta.pod#Incompatible_Changes
FWIW, I don't remember running into this myself nor seeing any related bug reports. The changelog of the perl package does not contain hints of special patches having been applied in the shipped 5.8.1 series packages that would fix the incompatibility.
So, 5.8.1 would be a candidate for removal from the compat list, and @INC and friends. All perl-* packages in Rawhide have been built with 5.8.3 or later, and IIRC no perl-* packages have been removed from FC since FC1 (5.8.1) so the removal wouldn't seem to need any actions there. It would affect 3rd party packages and locally installed modules done with 5.8.1 but still in use with current FC4 perl. But that is probably close to an empty set today.
Also, the perl-5.8.0's shipped in RHL9 and RHEL3 have quite a few patches applied, including at least some upstream ones (according to the changelog of the package). If some of those patches introduced the binary incompatibility present in upstream 5.8.1, 5.8.0 would be a candidate for removal from the compat lists too.
On Thursday 31 March 2005 17:07, Warren Togami wrote:
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
What about Requires: perl(abi) = 5.8 or whatever? Similar in the vein of how Python packages are being put together. :MODULE_COMPAT_ seems a bit overkill. Maybe I'm not seeing the whole picture, but it'd be nice to have some consistency even between different module-based interpreted languages.
On Fri, 2005-04-01 at 03:02 +0800, Jeff Pitman wrote:
On Thursday 31 March 2005 17:07, Warren Togami wrote:
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
What about Requires: perl(abi) = 5.8 or whatever? Similar in the vein of how Python packages are being put together. :MODULE_COMPAT_ seems a bit overkill. Maybe I'm not seeing the whole picture, but it'd be nice to have some consistency even between different module-based interpreted languages.
Agreed in principle, but IMO hardly worth changing unless it's done automatically by rpmbuild, like it does for Python in Rawhide/FC4tX. This provision was added there specifically for the purpose of being the official interface for depending on a specific ABI-compatible version of Perl. Such interfaces cannot obviously be changed without good reasons and a deprecation period.
:MODULE_COMPAT_* may not be eye candy, but it is there (and was there before Python got a similar one), does what it's intended to do, and masses of specfiles depend on its presence. IIRC cpanflute2 also adds those dependencies nowadays, so some tools would need fixes too, not only existing packages, if it went away.
OT: ISTR the ruby package lacks this kind of "abi" provision, yet it has site-* in similar manner as python and perl packages.
packaging@lists.fedoraproject.org
-
Dag Wieers -
Jeff Pitman -
Michael Schwendt -
Ville Skyttä -
Warren Togami