Re: [OM Cooker] Fwd: perl-URPM flaws [+PATCH]

On Jul 30, 2013, at 1:18 PM, Per Øyvind Karlsen wrote:

> 2013/7/30 Jeff Johnson <[email protected]>
> 
> On Jul 30, 2013, at 9:04 AM, Per Øyvind Karlsen wrote:
> 
>> 2013/7/26 Jeffrey Johnson <[email protected]>
>> Now for OMA ... Mageia can fix their own silly flaws.
>> 
>> Pleas apply this (or equivalent) patch to perl-URM svn.
>> Code in mandriva svn is obsolete, the code has been moved to git repository on ABF at  https://abf.rosalinux.ru/moondrake/perl-URPM
>> 
>> Could you regenerate your patch against this, then I'll apply? :)
>> 
> 
> Generating and verifying the patch took most of a day: I don't have
> that amount of free time to chase after every fork of URPM with
> its very own repository.
> I've merged it now. :)
> 

Good.

Meanwhile there are many other problems in URPM.

E.g. exposing --relocate functionality is (atm) known to have
not worked for (at least) 2y because of misuse of a pointer/structure.

You might just as well rip out the functionality: --relocate "works" just
like it always has in RPM:
	Barely useful, naively designed.
and exposing in URPM just propagates uselessness needlessly.

There are further problems with rpmconstant extracting and re-exposing
defines and constants into perl bindings that are then expected to
be present in URPM.

Finally -- like many perl programs -- URPM assumes that rpm/perl-rpm (and all URPM build prereqa)
are installed on the build machine, or it fails to build or run. There are ways to
fix the build: see perl/Makefile.PL for one way using rpaths so that modules/libraries
are loaded from within the build tree rather than searching the usual "system" paths.

Note that I am building (and attempting to use) perl-URPM on CentOS and Mac OS X routinely.
Portability to other operating system environments is enhanced if URPM can be tested
without installing. Achieving a wider adoption is crucial to URPM's continued usage:
Mandriva isn't the company it once was.

I'd also suggest coverage testing (or at least running under valgrind sufficiently
to ensure no flaws) to enhance the reliability of a crucially important piece of
software. De facto testing (as you have just seen) isn't adequate to find moderately
serious flaws:
	Hooray! the software builds: ship it!

73 de Jeff