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, done.
All packagers are involved and every one has to complete the task for all maintained packages: grep ^%run_ldconfig */*.spec | wc -l 359
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@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org