Mailinglist Archive: opensuse-packaging (186 mails)

< Previous Next >
Re: [opensuse-packaging] openSUSE vs Fedora packaging documentation
  • From: Stanislav Brabec <sbrabec@xxxxxxx>
  • Date: Thu, 12 Feb 2009 19:01:37 +0100
  • Message-id: <1234461697.28128.271.camel@xxxxxxxxxxxxxx>
Ludwig Nussel wrote:

Depends on the policy you change. There are a lot of knobs in
/usr/lib/rpm/macros. %run_ldconfig is an additional knob in SUSE.
Obviously it was simple to change it from doing something stupid to
just calling ldconfig. If calling ldconfig becomes deprecated
tomorrow you can globally change it to something else, rebuild,

All packagers are involved and every one
has to complete the task for all maintained packages:
grep ^%run_ldconfig */*.spec | wc -l

for/getpac/sed/submitpac :-)

Yes. It still introduces several hours of review work.

To create a package conforming to the current packaging conventions, you
also should split most of these packages according to Shared Library
Packaging Conventions. Sed will not help with this work. Splitting of
just only avahi to 23 sub-packages took nearly 2 work days to the first
successful build.

How many years would take enabling of final force-fail check for Fedora
incompatible packages?

What does that prove exactly? Do you want to say the one who decided
years ago that everyone needs to put %run_ldconfig calls in %post
was mistaken and the correct implementation would have been to
always have %post call ldconfig automatically?

%run_ldconfig was only a work-around. The mistake was the package
manager, that forces calling of /sbin/ldconfig 2000 times during system
upgrade. Now we have a better work-around: running much faster
/sbin/ldconfig 2000 times.

I have no idea what a 'class based build system' is supposed to be.

A packaging system that allows you to define package classes, methods,
conventions, packaging phases and script in a central place. Examples of
such systems: EBuild, BitBake.

Imagine that you define a shared library class, that will define:

Split each library automatically to a sub-package.
Automatically create correct names for all these sub-packages.
Call correct scripts defined in just one place.
Generate a correct dependency to the devel package.
Do this everything without any single line in the package description.

However if you e.g. want to automatically have different post
install scripts for certain kind of packages you'd have to tag your
packages first and then have macros insert different scripts
according to the tags definition.

That is why I am thinking about a different packaging system, where I
don't have to insert a macro, that will tag my packages with certain
tags to be able to insert another bunch of macros that will insert
correct script.

You can have that with rpm too. It's just that we have thousands of
packages that have no tags.

No, you can't do it with RPM:

- You cannot change script definition by a script called in %install
phase (at the best you can %define foo %(command))

- You can create a macro that creates an excerpt of a script and add it
to %install and include correct excerpt in each script definition (using
several additional macros in each package), but you cannot detect a
correct sub-package for the script. You can see how ugly it is: Look
at /etc/rpm/macros.gconf2.

- You can define a symbol automatically, but you cannot trigger script
on this symbol.

- If the same script is used in many packages, you cannot trigger it
only once per transaction.

Best Regards / S pozdravem,

Stanislav Brabec
software developer
SUSE LINUX, s. r. o. e-mail: sbrabec@xxxxxxx
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >