Bug 6651

the thing is, /usr/bin/prove is already shipped by perl-devel. so shipping /usr/bin/prove also in perl-Test-Harness results in a file conflict...

and lots of other dual-lifed packages are shipping scripts living in /usr/bin. knowing that the following criterias need to be pondered:
- rpm conflict: whether package installs fine when perl-xxx (perl-devel or perl-doc) is already installed
- latest version available: whether mageia is providing users the latest version of the modules / scripts
- perl packaging ease: whether perl package is easy to manage
- perl modules packaging ease: whether dual-life perl module packages are easy to manage
- user friendly-ness: whether things "just work" (tm) for the user


therefore i had the following options, with associated pros(+) and cons(-):

*1* ship scripts as is in dual-life package
- rpm conflict
+ latest version
+ perl pkg
+ perl module pkg
+ user friendly (except for rpm conflict)
==> rpm conflict is a no-no for me. discarding this option.

*2* do not ship dual-life packages
+ no rpm conflict
- latest version
+ perl pkg
+ perl module pkg
+ user friendly
==> not nice, meaning one does not get bleading-edge versions for 1 year (stable perls are now released every year, and bug-fix versions do not update dual-lifed modules anymore). it can work, though.

*3* rename conflicting scripts in non-core package
+ rpm conflict
+ latest version
+ perl pkg
- perl module pkg
- user friendly
==> perl module spec files are not really difficult to change. user need to be aware that they have both versions available if they want to use latest script versions

*4* remove core package version, and ship modules only in perl-x-y packages
+ rpm conflict
+ latest version
- perl pkg
+ perl module pkg
+ user friendly
==> this puts some complexity in perl spec file (which is already complex enough as is), and also does not always work, given that perl is using some modules shipping conflicting scripts during its build phase.

*5* use alternatives schema for conflicting scripts
+ rpm conflict
+ latest version
- perl pkg
- perl module pkg
+ user friendly
==> i don't know alternatives that much, but they're a bit complex to manage afaik (lots of post/postun work), and we're talking about quite a lot of new alternatives. also, i don't know if alternatives is considered the official way to go in mageia.

*6* other alternative scheme, eg dropping an alias in /etc/profile.d (while still renaming conflicting scripts to script-x.y.z)
+ rpm conflict
+ latest version
+ perl pkg
- perl module
+ user friendly
==> shouldn't be really difficult to do, but maybe a bit fragile (running "prove" and "/usr/bin/prove" wouldn't yeald the same result). also, i don't know the official way to go in mageia.


now, a brief look at history... (this spans mandriva+mageia life-time)

we used to not ship updates of dual-life modules (aka option 2). however, some modules required recent version of core toolchain modules (such as testing framework), and therefore we had to dual-life some of the modules. also, it was interesting for perl developers to get latest & greatest modules available.

so we went for option 1 (ship both core & dual-life modules as-is), but quickly found ourselves faced at rpm conflict problem. this was "not good" (tm) and we had to find another solution.

so we tried to remove conflicting modules from core perl package (option 4). however, it added some real complexity in perl spec file (and we really don't need it! :-) ), and also proved inefficient: perl building is more and more relying on the modules shipped with core (latest examples in date: json, digest::md5). so even if it worked for some time, we had to change our way of working. note also that perl 5 porters tend to object if installing "perl" on a linux dist doesn't install everything shipped in perl tarball.

therefore i decided to rename conflicting scripts in dual-lifed modules to their names followed by their version. it was quite easy (really just an additional line in the module spec file), and allows for easy differenciation. also, noting that most of the time the interest of packages lies in modules (which aren't renamed, since perl maintains 3 install dirs: core / vendor / site) not scripts, and it was a no brainer to switch to this solution. also, given that we had to move to this solution (cf paragraph above) and to please perl 5 porters, i changed perl 5.16 all remaining option 4 in perl spec file.

now, you are telling me that it's not optimal: i know that indeed it isn't. but using alternatives is not nice, since it means adding sthg like this in both perl and perl modules spec files (taken from vim package): 
=========================
update-alternatives --install /bin/vi vi /bin/vim-minimal 10 \
    --slave /bin/view view /bin/vim-minimal \
    --slave /bin/ex ex /bin/vim-minimal \
    --slave /bin/rvi rvi /bin/vim-minimal \
    --slave /bin/rview rview /bin/vim-minimal

%postun minimal
[ $1 = 0 ] || exit 0
update-alternatives --remove vi  /bin/vim-minimal
=========================
and i'm not sure that we want to move to a /etc/profile.d/85-perl-test-harness.sh providing an alias - or any other scheme, but you're welcome to prove me wrong on this point.


final words and considerations on this issue:

- perl 5 porters are leaning to a smaller core. this should mean that some conflicting modules should be removed in future versions. case in point: CPANPLUS should be removed from perl 5.18, others may follow. obviously, some conflicting packages will remain, such as test::harness, so it's not a silver bullet either.

- users hitting the problem (such as you) are quite knowledge-able people. after all, not everyone needs to run "prove" or other such scripts. and given that scripts are the only problem (modules once again do not conflict), i think the issue is a low priority one. which means that i would tend to "WONTFIX" it... even if i totally agree with you that a) it's not clean and b) i would like a solution for it

- a simple solution that i need to investigate is the "vendorscriptexp" option during perl configuration. in that case, it may be possible to automatically install dual-life scripts (and also scripts shipped in regular cpan modules) in another directory altogether, such as /usr/bin/perl5-scripts (or whatever). but this a) needs to be tested, b) would be really not unixy and c) needs an official approve (and decision on the name of this new perl bindir) from mageia 
technical committee.

Thanks a lot for this long and detailed explanation. This was very interesting. I wondered if this solution could work:

*7* In post-installation of perl-Test-Harness: create a symlink pointing to prove-3.23 named /usr/local/bin/prove.

This way, core modules install their scripts in /usr/bin/, and dual-life modules create their symlinks in /usr/local/bin/. This way, they will never conflict, and you can install/uninstall Perl packages pretty easily. Depending on which directory is scanned first (depends on what $PATH contains), you would get the dual-life script first, or fallback to the core one (so ideally, $PATH should first look at /usr/local/bin before /usr/bin). What do you think?

in that case, i'd rather investigate vendorscriptexp and point it to /usr/local/bin rather than adding some post install in all conflicting dual-lifed packages - but i think that system shouldn't install stuff in /usr/local which is reserved for, erm, local stuff the local admin want to deploy...

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

I know the bug hasn't been fixed, but as explaing in comment 1, things aren't easy and we have most likely the best solution available for now.

Closing thus as resolved/wontfix - feel free to reopen (with a more recent mageia version / cauldron) if you really want to pursue a better solution...

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX