Re: [Cooker] Updating to rpm4.4.1

[Michael Scherer]

On Thursday 28 April 2005 16:19, Olivier Thauvin wrote:
> I am currently working on rpm-4.4.1 and lot of things will change, so
> some explanations are usefull and some discussion should be open:
>
> What will change:
> - rpm spec file
>   - big clean up to remove uneed patch and obsolete patch
>   - remove update-alternative to maintain separatly and so stopping
> to make patch over existing patch. (our update-alternatives is in the
> mandriva cvs).
>
> - libraries
>   - mklibidication of popt lib and rpmlib, this will allow user to
> keep the librpm until application are not rebuild (mainly for
> perl-URPM)
>
> - configuration
>   - now our 'host' should be
> '%_target_cpu-mandriva-%{_target_os}-gnu', notice the mandriva. This
> will impact %configure* and so gcc.
>   - a new package 'rpm-mandriva-setup' will provide the rpm
> configuration in /usr/lib/rpm/mandriva, see bellow.
>   - rpm define some specifics macros for redhat and mandrake, but I
> don't think Jeff Jonhson want to maintain this, and because now we
> manage our configuration ourself in a separated package, it is
> useless, moreover 'mandriva' is unknown currently, so we stop to
> patch rpm configuration but overload it from rpm-mandriva-setup.
>   - rpm scripts (prov/req ect...) will be in rpm-mandriva-setup, so
> this mean we keep orginal rpm scripts without changes, but we do not
> use it in our configuration
>
> To properly split rpm, we have to provide what we remove:
>
> - update-alternatives:
> In the mandriva cvs: soft/update-alternatives. A simple rpm noarch,
> currently not installable but allready upload for testing purpose.
>
> - rpm-mandriva-setup:
> In mandriva cvs: soft/rpm-setup. My goal is to put there the minimum
> of changes, keeping code easy. So only macros we changed are put in
> this package.
> rpm 4.4.1 will search by default /usr/lib/rpm/mandriva/rpmrc (define
> at rpm compilation time). This rpmrc will search macros files in this
> order: - /usr/lib/rpm/macros (read originals macros)
> - /usr/lib/rpm/%{_target_cpu}-%{os}/macros (arch specific macros from
> rpm) - /usr/lib/rpm/mandriva/macros (our generics macros)
> - /usr/lib/rpm/mandriva/%{_target_cpu}-%{os}/macros (our arch
> specifics macros)
> - /etc/rpm/macros (system macros, admin config file)
> - /etc/rpm/macros.d/*.macros (this allow packager to maintain their
> per package macros, think to multiarch, php, ruby, http, ect...) 

Was it a problem with apache2 and axps ?
http://qa.mandriva.com/show_bug.cgi?id=6574

> - 
> ~/.rpmmacros (I don't have to explain).
>
> The rpm-mandriva-setup build system use autotools and you can setting
> up path for testing purpose by using rpm --rcfile.
>
> I will upload soon a first rpm-mandriva-setup for test, it will not
> use by default by current rpm, but you'll be able to follow
> devellopment and point issue.
>
> What I am doing now: on my amd64 I build rpm4.4.1 package, I will
> install it, install rpm-mandriva-setup and update-alternatives and
> pray my system will still works. I will try to rebuild rpms
> (perl-URPM first), find issue, fix macros, ect... and if I think it's
> ok, I'll put all rpm somewhere for comment and test. And then we'll
> be able to upload a first release.
>
> Will cooker be broken ? Normally no 

Damn, not even a little ?
How do you expect a release of quality without at least one major 
problem during cooker period :)

> (it's one thing I will test), 
> only installing cooker will not works until perl-URPM is not rebuild,
> but we'll be able to keep librpm4.2 and have perl-URPM working if
> more time is need to port perl-URPM.
>
> Here some questions:
> - should we keep the multiarch checks as it bother poeple on stable
> release, and I think it should go into rpmlint instead ?

Since multiarch check also have a impact on the location of the file, i 
think we should not remove it completly from rpm. However, maybe a 
macro instead of a patch will be more maintenable.

> - should we keep the patch removing conflict between doc files (I
> think gnome maintener should fix its packages definitivelly) ?

How could we see what would be broken ?

> - should we keep the patch making obsoletes apply to the rpm name
> instead rpm provide as it's change standard behaviour ?

How could we see what would be broken ? ( bis)

> - should we still provide popt 32bits code as package will use
> mklibname ?
>
> I still have lot of works (coloring patch to remade, finding a way to
> add popt option like rpm -bb without patch, else making a patch, ...)
>
> Comments, questions are welcome. I hope I forget nothing. Will rpm
> 4.4.1 have bug, surelly ! :)
>
> And sorry, I know my english is horrible...

You can ask to people to proofread it before sending the mail.
-- 
Michaël Scherer

On the importance to respond to proposal email :
http://www.nntp.perl.org/group/perl.bootstrap/1127