[opensuse-packaging] openSUSE vs Fedora packaging documentation
Hi, I compared a Fedora Packaging Guidelines [1] and SUSE Packaging Convetions [2] and I think that Fedora documentation is really better than we provide. It's not only about amount of information, but mainly in structure of it. For example if we want to read about License policy in SUSE and start on Packaging page [3] - how can user get from this page to equivalent of Licensing guidelines [4]? Fedora way is Packaging -> Packaging/Guidelines -> Packaging/LicensingGuidelines Or another example - is really necessary talk about BuildService account on packaging cookbooks of KDE[5] or Java[6]? In fact with this structure, where they exists outside Packaging/ it makes a sense, but it's really necessary? If we want to help a community to participate on openSUSE (for example packaging in Contrib) we also need a better documentation than we have. So main questions are: - how could be Packaging/ maintained (eg. we would have a Docbook original somewhere and convert it to wiki as SUSE packaging conventions [2])? - how could we structure existing information to be more readable and useful for community? - what is missing, or unclear and needs to be improved? (- and who will do this all ;-)) [1] http://fedoraproject.org/wiki/Packaging:Guidelines [2] http://en.opensuse.org/Packaging/SUSE_Package_Conventions [3] http://en.opensuse.org/Packaging/ [4] https://fedoraproject.org/wiki/Packaging/LicensingGuidelines [5] http://en.opensuse.org/KDE/Packaging/Cookbook [6] http://en.opensuse.org/Java/Packaging/Cookbook Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mercredi 11 février 2009, à 15:51 +0100, Michal Vyskocil a écrit :
So main questions are: - how could be Packaging/ maintained (eg. we would have a Docbook original somewhere and convert it to wiki as SUSE packaging conventions [2])? - how could we structure existing information to be more readable and useful for community? - what is missing, or unclear and needs to be improved? (- and who will do this all ;-))
Can't we simply adopt the Fedora doc and make it a cross-distribution documentation? (we might have some differences, but I'm sure we can drop some, and work with Fedora people on a good way to highlight the differences) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, 2009-02-11 at 16:24 +0100, Vincent Untz wrote:
Le mercredi 11 février 2009, à 15:51 +0100, Michal Vyskocil a écrit :
So main questions are: - how could be Packaging/ maintained (eg. we would have a Docbook original somewhere and convert it to wiki as SUSE packaging conventions [2])? - how could we structure existing information to be more readable and useful for community? - what is missing, or unclear and needs to be improved? (- and who will do this all ;-))
Can't we simply adopt the Fedora doc and make it a cross-distribution documentation? (we might have some differences, but I'm sure we can drop some, and work with Fedora people on a good way to highlight the differences)
Vincent
-- Les gens heureux ne sont pas pressés.
Good idea. I'm sure Fedora would be happy and willing to co-operate on this. Having spoken to several people and been approached by several whilst at FOSDEM about ways in which they can work with openSUSE and other projects, they are keen to help in the cross pollination of information. Regards, Andy -- Andrew Wafaa, openSUSE Member: FunkyPenguin. openSUSE: Get It, Discover It, Create It at http://www.opensuse.org awafaa@opensuse.org | http://www.wafaa.eu -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday 11 of February 2009 16:42:59 Andrew Wafaa wrote:
On Wed, 2009-02-11 at 16:24 +0100, Vincent Untz wrote:
Le mercredi 11 février 2009, à 15:51 +0100, Michal Vyskocil a écrit :
So main questions are: - how could be Packaging/ maintained (eg. we would have a Docbook original somewhere and convert it to wiki as SUSE packaging conventions [2])? - how could we structure existing information to be more readable and useful for community? - what is missing, or unclear and needs to be improved? (- and who will do this all ;-))
Can't we simply adopt the Fedora doc and make it a cross-distribution documentation? (we might have some differences, but I'm sure we can drop some, and work with Fedora people on a good way to highlight the differences)
Vincent
-- Les gens heureux ne sont pas pressés.
Good idea.
I'm sure Fedora would be happy and willing to co-operate on this. Having spoken to several people and been approached by several whilst at FOSDEM about ways in which they can work with openSUSE and other projects, they are keen to help in the cross pollination of information.
If Fedora would be interested, why not. I'm afraid that this would be better, but rather impossible way. Stanislav Brabec told me about his effort on unification of RPM macros used by various distributions, but it failed. It failed on a simple reason - no one want to change his policy/macros/etc. I CCing him, so he should be able provide more details about current state of discussion on rpm-devel (or rpm-maint, I'm not sure) mailing list. But if you know some interested guys from Fedora, I'm really interested on it and I'll help if I can. Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On čt 12. února 2009, Michal Vyskocil wrote:
On Wednesday 11 of February 2009 16:42:59 Andrew Wafaa wrote:
On Wed, 2009-02-11 at 16:24 +0100, Vincent Untz wrote:
Le mercredi 11 février 2009, à 15:51 +0100, Michal Vyskocil a écrit :
So main questions are: - how could be Packaging/ maintained (eg. we would have a Docbook original somewhere and convert it to wiki as SUSE packaging conventions [2])? - how could we structure existing information to be more readable and useful for community? - what is missing, or unclear and needs to be improved? (- and who will do this all ;-))
Can't we simply adopt the Fedora doc and make it a cross-distribution documentation? (we might have some differences, but I'm sure we can drop some, and work with Fedora people on a good way to highlight the differences)
Vincent
-- Les gens heureux ne sont pas pressés.
Good idea.
I'm sure Fedora would be happy and willing to co-operate on this. Having spoken to several people and been approached by several whilst at FOSDEM about ways in which they can work with openSUSE and other projects, they are keen to help in the cross pollination of information.
If Fedora would be interested, why not. I'm afraid that this would be better, but rather impossible way. Stanislav Brabec told me about his effort on unification of RPM macros used by various distributions, but it failed. It failed on a simple reason - no one want to change his policy/macros/etc. I CCing him, so he should be able provide more details about current state of discussion on rpm-devel (or rpm-maint, I'm not sure) mailing list.
90% of Fedora guidelines applies on openSUSE too. It would be relatively easy to just take the Fedora guidelines and do some adjustments. Another question is how to keep the Fedora and openSUSE versions of the guidelines synced in the future. Vladimir -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag, 12. Februar 2009 13:20:13 schrieb Vladimir Nadvornik:
On čt 12. února 2009, Michal Vyskocil wrote:
On Wednesday 11 of February 2009 16:42:59 Andrew Wafaa wrote:
On Wed, 2009-02-11 at 16:24 +0100, Vincent Untz wrote:
Le mercredi 11 février 2009, à 15:51 +0100, Michal Vyskocil a écrit :
So main questions are: - how could be Packaging/ maintained (eg. we would have a Docbook original somewhere and convert it to wiki as SUSE packaging conventions [2])? - how could we structure existing information to be more readable and useful for community? - what is missing, or unclear and needs to be improved? (- and who will do this all ;-))
Can't we simply adopt the Fedora doc and make it a cross-distribution documentation? (we might have some differences, but I'm sure we can drop some, and work with Fedora people on a good way to highlight the differences)
Vincent
-- Les gens heureux ne sont pas pressés.
Good idea.
I'm sure Fedora would be happy and willing to co-operate on this. Having spoken to several people and been approached by several whilst at FOSDEM about ways in which they can work with openSUSE and other projects, they are keen to help in the cross pollination of information.
If Fedora would be interested, why not. I'm afraid that this would be better, but rather impossible way. Stanislav Brabec told me about his effort on unification of RPM macros used by various distributions, but it failed. It failed on a simple reason - no one want to change his policy/macros/etc. I CCing him, so he should be able provide more details about current state of discussion on rpm-devel (or rpm-maint, I'm not sure) mailing list.
90% of Fedora guidelines applies on openSUSE too. It would be relatively easy to just take the Fedora guidelines and do some adjustments.
Another question is how to keep the Fedora and openSUSE versions of the guidelines synced in the future.
Work together with them on it. We have discussed this before already with Fedora and they were interessted in a joint approach as well. I can tell you the contacts in PM, in case you do not have them anymore. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Vladimir Nadvornik wrote:
90% of Fedora guidelines applies on openSUSE too. It would be relatively easy to just take the Fedora guidelines and do some adjustments.
But also lot of differences: (This document was written a year ago and may be outdated.) Different higher level solutions built on top of RPM Official openSUSE solution is ZYPP: http://en.opensuse.org/Libzypp RPM patches openSUSE uses patched rpm, which does some things differently. For example: - safely removes $RPM_BULD_ROOT - %makeinstall uses DESTDIR - openSUSE supports Recommends:, Supplements:, Enhances:, Suggests: (probably fixed in rpm 4.6) - ... Spec files Preamble openSUSE still use PreReq, Fedora uses newer Requires(pre) (note: Requires(posttrans) is even not yet implemented). Macros Here is a set of macros defined in /usr/lib/rpm/suse_macros: %restart_on_update %stop_on_removal %configure_kernel_source %run_permissions %run_suseconfig_fonts %suse_update_config %suse_update_libdir %fillup_and_insserv %do_real_fillup %add_start_if_needed %insserv_cleanup %fillup_only %rc_fillup %sysc_fillup %save_rc_config_d_was_in_filelist %insserv_force_if_yast %supplements_kernel_module For guessing openSUSE version, strings %suse_version and %sles_version exist. Sysconfig openSUSE uses a special way to maintain sysconfig files. All sysconfig files must have a special sysconfig comments for sysconfig editor and use fillup. Scripts GConf: openSUSE and Fedora use three scriptlets to perform the update. As the update process combining old and new instance scriptlets is very fragile, they are incompatible and clean cross-distro update is impossible. http://en.opensuse.org/SUSE_Build_Tutorial/GConf_scriptlets On my opinion, Fedora's scriptlets may break in case of package rename and merge of two packages into one. openSUSE seems to survive it. Texinfo: openSUSE and Fedora do the same, but openSUSE defines macros %install_info and %install_info_delete. Actually used scriptlets are fragile and in some situations they keep unwanted orphans or delete wanted items. Scrollkeeper: Fedora uses scriptlets to perform scrollkeeper-update. openSUSE has patched scrollkeeper/rarian and can live without scriptlets here. desktop-database: openSUSE has a SuSEconfig script. SuSEconfig is called after every installation and updates desktop database. SuSEconfig is deprecated in openSUSE, but reverting to RPM based solutions means editing of hundreds of spec files and ~30000% performance loss in a worst case. Fedora calls update-desktop-database from scriptlets. As it calls all scriptlets at the end of a big transaction, calling it 300 times at once is a bit faster. SuSE uses %suse_update_desktop file a lot in %install phase. It provides a way to control contents of desktop files. mimeinfo: Both Fedora and openSUSE use nearly the same scriptlets, which do the same. Use of RPM based solutions means about ~2000% performance loss in a worst case here. GTK+ icon cache: openSUSE uses SuSEconfig script. SuSEconfig is called after every installation and updates GTK+ icon cache. Reverting to RPM based solutions means editing of hundreds of spec files and ~30000% performance loss in a worst case. Fedora calls it at the end of the transaction many times at once. Peformance loss is not as bad here, because subsequent runs reuse file system cache and run faster. Fedora's use of touch seems to be obsolete nowadays (fixed in upstream). Fonts: openSUSE has %run_suseconfig_fonts and a a SuSEconfig script conditionally called after every installation. Reverting to RPM based solutions would mean a hour or more of installation time in a worst case on slow machines. Fedora calls it at the end of the transaction many times at once. Peformance loss is not as bad here, because subsequent runs reuse file system cache and run faster. Shared libraries: openSUSE and Fedora do the same (including the tricky way), but several openSUSE packages still use deprecated %run_ldconfig. Initscripts Conventions: openSUSE has macros doing stuff in a very similar way altogether with fillup: %fillup_and_insserv %insserv_only %stop_on_removal %restart_on_update The bad thing is the fact, that it may fail badly in case of package rename. To fix this failure, a new RPM feature may be needed. User and group handling: Both use a very similar approach, but I think there is no convention. The bad thing is the fact, that calling userdel is unsafe and may fail badly for a similar reasons like init scripts. libexecdir: Fedora allows /usr/libexec. /usr/libexec is not allowed in openSUSE, --libexecdir=%{_prefix}/lib/%{name} is preferred. But openSUSE %configure still uses buggy --libexecdir=%{_libdir} and each package has to set it explicitly. https://bugzilla.novell.com/show_bug.cgi?id=157894 SuSEconfig: It's a SuSE specific solution of some problems of rpm. External links: openSUSE packaging http://en.opensuse.org/Packaging Fedora packaging https://fedoraproject.org/wiki/Packaging/Guidelines Differences introduced in >= rpm 4.6: %patch/%patch0 behave differently fuzz in patches is no more allowed Differences in Mandriva %make %makeinstall* different way to call ldconfig -- 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
On Thursday 12 of February 2009 14:03:20 Stanislav Brabec wrote:
Vladimir Nadvornik wrote:
90% of Fedora guidelines applies on openSUSE too. It would be relatively easy to just take the Fedora guidelines and do some adjustments.
But also lot of differences:
(This document was written a year ago and may be outdated.)
I added it on wiki http://en.opensuse.org/Packaging/Distribution_differences Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thursday 12 February 2009 13:20:13 Vladimir Nadvornik wrote:
90% of Fedora guidelines applies on openSUSE too. It would be relatively easy to just take the Fedora guidelines and do some adjustments.
Another question is how to keep the Fedora and openSUSE versions of the guidelines synced in the future.
What about the following: * Create a cross-distribution (RPM based) consensus with other distros (Fedora was interested in this) on the following: + create a unified document that contains both what we have in common and documents differences + Decide to not introduce new differences but if one distribution needs to enhance the document, it will be done together with the others so that we do not diverge + work on the low-hanging fruits and sync those that are easy to do Even if the complete merge might take some time, I think a goal would help - not only openSUSE as distribution but everybody using the openSUSE Build Service building packages for both Fedora and openSUSE! Who'll start this? Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
What about the following: * Create a cross-distribution (RPM based) consensus with other distros (Fedora was interested in this) on the following:
+ Use rpmbuild and rpm versions behaving equally on both distros. It must be the first step, otherwise fix of one will break the other.
+ create a unified document that contains both what we have in common and documents differences + Decide to not introduce new differences but if one distribution needs to enhance the document, it will be done together with the others so that we do not diverge + work on the low-hanging fruits and sync those that are easy to do
Even if the complete merge might take some time, I think a goal would help - not only openSUSE as distribution but everybody using the openSUSE Build Service building packages for both Fedora and openSUSE!
Who'll start this?
Already started but without valuable output: http://lists.rpm.org/pipermail/rpm-maint/2008-July/thread.html -- 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
Le vendredi 13 février 2009, à 12:55 +0100, Stanislav Brabec a écrit :
Andreas Jaeger wrote:
What about the following: * Create a cross-distribution (RPM based) consensus with other distros (Fedora was interested in this) on the following:
+ Use rpmbuild and rpm versions behaving equally on both distros.
It must be the first step, otherwise fix of one will break the other.
So I guess the first question is "how hard would it be to move to rpm 4.6?" and the second one is "did we try pushing our rpm patches to rpm upstream?". Or, basically, are we involved in the development of upstream rpm? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Feb 13, 09 16:53:12 +0100, Vincent Untz wrote:
Le vendredi 13 février 2009, à 12:55 +0100, Stanislav Brabec a écrit :
Andreas Jaeger wrote:
What about the following: * Create a cross-distribution (RPM based) consensus with other distros (Fedora was interested in this) on the following:
+ Use rpmbuild and rpm versions behaving equally on both distros.
It must be the first step, otherwise fix of one will break the other.
So I guess the first question is "how hard would it be to move to rpm 4.6?" and the second one is "did we try pushing our rpm patches to rpm upstream?".
Or, basically, are we involved in the development of upstream rpm?
RPM upstream is torn into two upstreams. One is Fedora, the other is Jeff Johnson. I understand that we need to work towards one common RPM upstream in order to make that pig fly again. Not sure which 'we' should take lead. sigh, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le samedi 14 février 2009, à 12:36 +0100, Juergen Weigert a écrit :
On Feb 13, 09 16:53:12 +0100, Vincent Untz wrote:
Or, basically, are we involved in the development of upstream rpm?
RPM upstream is torn into two upstreams. One is Fedora, the other is Jeff Johnson. I understand that we need to work towards one common RPM upstream in order to make that pig fly again.
Not sure which 'we' should take lead.
I know that, and I always thought we were staying on the 4.x branch, and not the 5.x one (ie, Fedora's and not Jeff's). So I was implying the 4.x branch in my question :-) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Michal Vyskocil wrote:
Can't we simply adopt the Fedora doc and make it a cross-distribution documentation? (we might have some differences, but I'm sure we can drop some, and work with Fedora people on a good way to highlight the differences)
If Fedora would be interested, why not. I'm afraid that this would be better, but rather impossible way. Stanislav Brabec told me about his effort on unification of RPM macros used by various distributions, but it failed. It failed on a simple reason - no one want to change his policy/macros/etc. I CCing him, so he should be able provide more details about current state of discussion on rpm-devel (or rpm-maint, I'm not sure) mailing list.
The effort silently disappeared. Going deeper to document any of the details, you find more and more differences introduced by a different solution implemented in past and different target. http://lists.rpm.org/pipermail/rpm-maint/2008-July/002210.html Such effort would be welcome on both sides, but everybody should realize an extreme amount of work needed for this effort. Due to manual-work nature of spec files, there is no easy way to adopt packages to any unified conventions. Unification means changes of nearly all macros, and definition of new macros to define new different aspects of particular distros (whether to call autoreconf or not,...), then manual modification of _all_ packages. Here is my blind guess: When both Fedora and Novell hire two new employees dedicated to this work, unified spec files of our packages may be ready in say 2 years. - Several man-weeks of work to create the draft We have to create a document, which would be accepted by both sides. We need to target many particular aspects (autotools based stuff, perl stuff, python stuff, gnome, kde, gconf2, mime-database, icon-database, fonts, summary and description conventions and syntax, names of packages, unification migration conventions and migration protection...) - Several man-months of work to unify RPM implementation Our rpm implementation differs in important aspects. Redhat uses rpm 4.6, Novell did not even started to think about migration to it. We actually have rpm 4.4 with 61 patches, custom macros. We have to evaluate, how many packages will need spec file changes after migration to the new rpm. However I believe, that rpm >4.6 may bring new power for zypp and even packages quality, the migration will be far from trivial. - Several man-years to modify all packages in openSUSE and Fedora. Example: Imagine, that %run_ldconfig was deprecated in SuSE several years ago, but it is still widely found in our packages. Exactly the same situation affect Shared Library Packaging Rules. Now multiply the amount of work (or time) to fix the whole distro by 5-10 and you are near to the spec file unification. P. S.: With a similar amount of work, we may think about migration to any of modern package-class based building tools or design a new build system from scratch: http://en.opensuse.org/BrainStorming_Prague/Way_we_do_packaging_is_ineffecti... It also means rewrite of package descriptions, but this approach would bring much more benefits in long-term than spec files unification. -- 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
Am Donnerstag, 12. Februar 2009 13:34:11 schrieb Stanislav Brabec: ...
P. S.: With a similar amount of work, we may think about migration to any of modern package-class based building tools or design a new build system from scratch: http://en.opensuse.org/BrainStorming_Prague/Way_we_do_packaging_is_ineffect ive
Okay, I read this and knows now that everything is bad. Can you make a suggestion how to improve ? Maybe even with small steps so we can actually make something better ? (I doubt that you want to suggest to use deb, right ?) bye adrian PS: Small rant: I think only czech and netherlands people can reach the moaning level of typical germans ;) -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thursday 12 of February 2009 13:40:31 Adrian Schröter wrote:
Am Donnerstag, 12. Februar 2009 13:34:11 schrieb Stanislav Brabec: ...
P. S.: With a similar amount of work, we may think about migration to any of modern package-class based building tools or design a new build system from scratch: http://en.opensuse.org/BrainStorming_Prague/Way_we_do_packaging_is_ineffe ct ive
Okay, I read this and knows now that everything is bad.
Can you make a suggestion how to improve ? Maybe even with small steps so we can actually make something better ?
(I doubt that you want to suggest to use deb, right ?)
No, the static nature of spec files if also included in debs. It's easier add some (few) missing features of deb to rpm, than switch SUSE to deb. Only one valid reason should be a Debian community and packages (that's Ubuntu way), but I'm sure Standa means BitBake[1] or some variants. But it's completely different topic. [1] http://bitbake.berlios.de/manual/
bye adrian
PS: Small rant: I think only czech and netherlands people can reach the moaning level of typical germans ;)
--
Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Adrian Schröter wrote:
Am Donnerstag, 12. Februar 2009 13:34:11 schrieb Stanislav Brabec: ...
P. S.: With a similar amount of work, we may think about migration to any of modern package-class based building tools or design a new build system from scratch: http://en.opensuse.org/BrainStorming_Prague/Way_we_do_packaging_is_ineffect ive
Okay, I read this and knows now that everything is bad.
No. You only read the "what is bad" part. The document does not contain "what is good" part, especially: ZYPP: It support half of the package manager features in a far better way than any packaging tool in the world. IF (install package A) AND (install package B) => ZYPP recommends A-plugin-B C-branding-FOO conflicts with all other packages that provide C-branding Do you know about any else tool capable to do such things? Build Service is another superior tool. We can build our distribution in several particular repositories just by setting up few links.
Can you make a suggestion how to improve ? Maybe even with small steps so we can actually make something better ?
Package Manager: If we want to stay at RPM, we should think about features we heavily need: - Better scripts: - One time triggers: we really need to call ldconfig, font cache updates, icon cache updates etc. just once to finally get rid SuSEconfig. - Pre-transaction scripts: We want to un-install info pages or gconf schemas in a clean way before RPM starts to manipulate with files. - Prevent breakage by %postun when package is renamed. - Integration with external solver (work in progress in Redhat): To be able to recycle ZYPP solver result and database. - Integration with external downloader (work in progress in Redhat): To be finally install in transactions instead of forces nodeps installation of particular packages and possible temporary breakage. For more see (and feel free to improve): http://rpm.org/wiki/Problems Package building: 20 years ago there was no configure, no DESTDIR. Spec files like we use just now reflect this situation: Describe all needed steps manually in detail and just for a single package. Now we have a different situation: 90% of packages use configure, support DESTDIR and installs files to standard directories. We should think, how to reflect this situation. Package maintainers should spent their time on package understanding, improving and integrating, not in manual handling each file destination and cut-paste-edit work. Simple global change should not introduce editing of hundreds particular spec files. Many people outside of the RPM world already went it this direction. Package description in a class based build system can consist from an absolute minimum of information needed for successful build of package. Better building tools already exist: BitBake, ebuild, buildroot-ng, sorcery. Most of them are simpler to use than spec. I can imagine, that a complete package build description in openSUSE 13.0 may consist from just 7 lines: ------------------ SUMMARY = "Graphic File Browser Utility" DESCRIPTION = ".........." GROUP = "Productivity/Graphics/Viewers" DEPENDS = "gtk2" HOMEPAGE = "http://gqview.sourceforge.net/" SRC_URI = "${SOURCEFORGE_MIRROR}/gqview/gqview-2.1.5.tar.gz" inherit autotools ------------------
(I doubt that you want to suggest to use deb, right ?)
No, but I think that several people would like to suggest it. It would be step forward for package manager (deb features are superior of rpm features) and step backward in package build tool Debian build tools are even more dumb than rpmbuild. (Well, with a semi-automatic tool to create the description, it can be considered as an advantage.) Summary: ZYPP is my favourite. It would run much faster it if would not have to go on a cripple horse back. -- 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
Stanislav Brabec <sbrabec@suse.cz> writes:
I can imagine, that a complete package build description in openSUSE 13.0 may consist from just 7 lines:
[...]
SRC_URI = "${SOURCEFORGE_MIRROR}/gqview/gqview-2.1.5.tar.gz" inherit autotools
I can't. There is not only gqview-2.1.5 we want to build a 1000 ×. Things looking easy are often just obscure--cf. /etc/gnome_defaults.conf. Accept that this world is a nice place of diversity and learn to cope with the chaos. One way would be not to package all and every upstream package release. -- Karl Eichwalder -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Karl Eichwalder wrote:
Stanislav Brabec <sbrabec@suse.cz> writes:
I can imagine, that a complete package build description in openSUSE 13.0 may consist from just 7 lines:
[...]
SRC_URI = "${SOURCEFORGE_MIRROR}/gqview/gqview-2.1.5.tar.gz" inherit autotools
I can't. There is not only gqview-2.1.5 we want to build a 1000 ×. Things looking easy are often just obscure--cf.
There is nothing obscure in ./configure ; make ; make install DESTDIR=... But our spec file contains a lot of pad saying just: - Yes, we want to package all files, that upstream installs. - Yes, we want to integrate desktop file, that upstream installs. - Yes, we want to follow Shared Library Packaging Conventions. - Yes, we want to place include files to devel package. - Yes, we want to place .pc files to devel package. - Yes, we want to use standard parallel make. - Yes, we want to use standard installation process. - Yes the devel package requires everything that .pc file declares to require. Instead we can say: - Handle package using standard autoconf based process. - Follow .pc files and use standard splitting. Yes, such tool must support non-standard steps, but it is not a problem: - Apply these patches. - Install this extra file. - Add this extra dependency. - Split in a non-standard way.
/etc/gnome_defaults.conf. Accept that this world is a nice place of diversity and learn to cope with the chaos.
Obscure SuSE specific configuration like /etc/gnome_defaults.conf is an answer to upstream GNOME, which provided infrastructure for selecting a default application, but it did not provide any way to guess such application. Getting many bugs about incorrectly associated MIME types, I wrote this one.
One way would be not to package all and every upstream package release.
Another way would be a tool, which will do it for us. If we decide to update once a year, we can loose users that want latest version of just this package. -- 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
On Friday 13 February 2009 12:47:56 Stanislav Brabec wrote:
[...] Obscure SuSE specific configuration like /etc/gnome_defaults.conf is an answer to upstream GNOME, which provided infrastructure for selecting a default application, but it did not provide any way to guess such application.
Getting many bugs about incorrectly associated MIME types, I wrote this one.
Are those changes upstream? If not, please try! That would make the conflicts smaller as well ;) Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
On Friday 13 February 2009 12:47:56 Stanislav Brabec wrote:
[...] Obscure SuSE specific configuration like /etc/gnome_defaults.conf is an answer to upstream GNOME, which provided infrastructure for selecting a default application, but it did not provide any way to guess such application.
Getting many bugs about incorrectly associated MIME types, I wrote this one.
Are those changes upstream? If not, please try! That would make the conflicts smaller as well ;)
No. - It is not a patch but an utility on top of GNOME MIME system. - I guess that upstream will not like implementation of associative arrays in bash. Tool seems to work well, but just now I have a bug regarding KDE and MIME defaults in firefox. It should not be complicated to generalize it and re-implement in C and then propose as a generic freedesktop tool. -- 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
On Monday 16 February 2009 14:04:00 Stanislav Brabec wrote:
Andreas Jaeger wrote:
On Friday 13 February 2009 12:47:56 Stanislav Brabec wrote:
[...] Obscure SuSE specific configuration like /etc/gnome_defaults.conf is an answer to upstream GNOME, which provided infrastructure for selecting a default application, but it did not provide any way to guess such application.
Getting many bugs about incorrectly associated MIME types, I wrote this one.
Are those changes upstream? If not, please try! That would make the conflicts smaller as well ;)
No.
- It is not a patch but an utility on top of GNOME MIME system.
- I guess that upstream will not like implementation of associative arrays in bash.
Tool seems to work well, but just now I have a bug regarding KDE and MIME defaults in firefox. It should not be complicated to generalize it and re-implement in C and then propose as a generic freedesktop tool.
That sounds like a good idea, I'd like to have such kind of solutions upstream, Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote in Wed 02/18 2009 at 14:03 +0100:
On Monday 16 February 2009 14:04:00 Stanislav Brabec wrote:
Andreas Jaeger wrote:
On Friday 13 February 2009 12:47:56 Stanislav Brabec wrote:
[...] Obscure SuSE specific configuration like /etc/gnome_defaults.conf is an answer to upstream GNOME, which provided infrastructure for selecting a default application, but it did not provide any way to guess such application.
Getting many bugs about incorrectly associated MIME types, I wrote this one.
Are those changes upstream? If not, please try! That would make the conflicts smaller as well ;)
No.
Tool seems to work well, but just now I have a bug regarding KDE and MIME defaults in firefox. It should not be complicated to generalize it and re-implement in C and then propose as a generic freedesktop tool.
That sounds like a good idea, I'd like to have such kind of solutions upstream,
Moving this part of discussion to upstream: http://lists.freedesktop.org/archives/xdg/2009-February/010208.html -- 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
2009/2/12 Stanislav Brabec <sbrabec@suse.cz>:
Package building:
20 years ago there was no configure, no DESTDIR. Spec files like we use just now reflect this situation: Describe all needed steps manually in detail and just for a single package.
Now we have a different situation: 90% of packages use configure, support DESTDIR and installs files to standard directories.
We should think, how to reflect this situation. Package maintainers should spent their time on package understanding, improving and integrating, not in manual handling each file destination and cut-paste-edit work. Simple global change should not introduce editing of hundreds particular spec files.
Many people outside of the RPM world already went it this direction. Package description in a class based build system can consist from an absolute minimum of information needed for successful build of package.
Better building tools already exist: BitBake, ebuild, buildroot-ng, sorcery. Most of them are simpler to use than spec.
I can imagine, that a complete package build description in openSUSE 13.0 may consist from just 7 lines: ------------------ SUMMARY = "Graphic File Browser Utility" DESCRIPTION = ".........." GROUP = "Productivity/Graphics/Viewers" DEPENDS = "gtk2" HOMEPAGE = "http://gqview.sourceforge.net/" SRC_URI = "${SOURCEFORGE_MIRROR}/gqview/gqview-2.1.5.tar.gz" inherit autotools ------------------
If the problem is that spec files are too generic then you can create a wrapper from this, more specific, ".newspec" format to the more generic .spec format, true? The OBS could search for .newspec files if no .spec file is found and run something like #!/bin/sh . "$1.newspec" SOURCE=$(basename "$SRC_URI") wget "$SRC_URI" -O "$SOURCE" bznew "$SOURCE" case "$SOURCE" in *.gz) SOURCE=${SOURCE/%.gz/.bz2};; *.tgz) SOURCE=${SOURCE/%.tgz/.tar.bz2};; esac echo "# norootforbuild Name: "$NAME" Version: "$VERSION" Release: 0 License: "$LICENSE" Group: "$GROUP" Summary: "$SUMMARY" Source: "$SOURCE" URL: "$HOMEPAGE" BuildRoot: %{_tmppath}/%{name}-%{version}-build BuildRequires: "$DEPENDS" BuildRequires: update-desktop-files optipng fdupes %description "$DESCRIPTION" %prep %setup -q %build %configure "$CONFIGURE_OPTS" %{__make} %{?_smp_mflags} %install %{__make} DESTDIR=%{buildroot} install for FILE in \$(find %{buildroot} -name '*.desktop'); do FILE=\$(basename "\$FILE") %suse_update_desktop_file \${FILE%.desktop} done %optipng %{buildroot} %fdupes -s %{buildroot} rpm -ql filesystem > .filesystemlist # Needed to get the correct final name of man pages /usr/lib/rpm/brp-compress find %{buildroot} | sed 's:%{buildroot}::' > .rpmlist %{__cat} .rpmlist .filesystemlist | sort | uniq -d > .duplist %{__cat} .rpmlist .duplist | sort | uniq -u > %{name}.files %{__rm} -f .filesystemlist .duplist .rpmlist %clean %{__rm} -rf %{buildroot} %files -f %{name}.files %defattr (-, root, root, 755) %changelog" > "$1.spec" But I also have my doubts about this working... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Cristian Morales Vega wrote in Sun 02/22 2009 at 08:55 +0100:
If the problem is that spec files are too generic then you can create a wrapper from this, more specific, ".newspec" format to the more generic .spec format, true?
The OBS could search for .newspec files if no .spec file is found and run something like
All spec template systems have common problems: - There is no way to define exceptions: apply additional patch, move or remove installed file, change make behavior or similar. - There is no way to split package automatically. spec is a sub-optimal intermediate format for these meta formats: It's too sophisticated for simple tools and it's too dumb to be effective for mass changes. Just try your proposal below and try to compile package that_ - needs to export variable before configure - is not smp compatible - has a special desktop file that should not be translated - needs split to more sub-packages
#!/bin/sh
. "$1.newspec"
SOURCE=$(basename "$SRC_URI") wget "$SRC_URI" -O "$SOURCE" bznew "$SOURCE" case "$SOURCE" in *.gz) SOURCE=${SOURCE/%.gz/.bz2};; *.tgz) SOURCE=${SOURCE/%.tgz/.tar.bz2};; esac
echo "# norootforbuild
Name: "$NAME" Version: "$VERSION" Release: 0 License: "$LICENSE" Group: "$GROUP" Summary: "$SUMMARY" Source: "$SOURCE" URL: "$HOMEPAGE" BuildRoot: %{_tmppath}/%{name}-%{version}-build BuildRequires: "$DEPENDS" BuildRequires: update-desktop-files optipng fdupes
%description "$DESCRIPTION"
%prep %setup -q
%build %configure "$CONFIGURE_OPTS" %{__make} %{?_smp_mflags}
%install %{__make} DESTDIR=%{buildroot} install for FILE in \$(find %{buildroot} -name '*.desktop'); do FILE=\$(basename "\$FILE") %suse_update_desktop_file \${FILE%.desktop} done %optipng %{buildroot} %fdupes -s %{buildroot} rpm -ql filesystem > .filesystemlist # Needed to get the correct final name of man pages /usr/lib/rpm/brp-compress find %{buildroot} | sed 's:%{buildroot}::' > .rpmlist %{__cat} .rpmlist .filesystemlist | sort | uniq -d > .duplist %{__cat} .rpmlist .duplist | sort | uniq -u > %{name}.files %{__rm} -f .filesystemlist .duplist .rpmlist
%clean %{__rm} -rf %{buildroot}
%files -f %{name}.files %defattr (-, root, root, 755)
%changelog" > "$1.spec"
But I also have my doubts about this working... -- 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
Stanislav Brabec wrote:
Example: Imagine, that %run_ldconfig was deprecated in SuSE several years ago, but it is still widely found in our packages. Exactly the same situation affect Shared Library Packaging Rules. Now multiply the amount of work (or time) to fix the whole distro by 5-10 and you are near to the spec file unification.
Well, that's just a matter of making certain rpmlint check failures finally fatal. It's just that someone will have to sustain the wrath of packagers (and coolo who wants so create snapshots) afterwards :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag 12 Februar 2009 schrieb Ludwig Nussel:
Stanislav Brabec wrote:
Example: Imagine, that %run_ldconfig was deprecated in SuSE several years ago, but it is still widely found in our packages. Exactly the same situation affect Shared Library Packaging Rules. Now multiply the amount of work (or time) to fix the whole distro by 5-10 and you are near to the spec file unification.
Well, that's just a matter of making certain rpmlint check failures finally fatal. It's just that someone will have to sustain the wrath of packagers (and coolo who wants so create snapshots) afterwards :-)
I think, making them fatal is the final step. First collect which packages are affected and create a list, so everyone can help sort it out. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Feb 12 13:52 Ludwig Nussel wrote (shortened):
Stanislav Brabec wrote:
Example: Imagine, that %run_ldconfig was deprecated in SuSE several years ago, but it is still widely found in our packages. Exactly the same situation affect Shared Library Packaging Rules. Now multiply the amount of work (or time) to fix the whole distro by 5-10 and you are near to the spec file unification.
Well, that's just a matter of making certain rpmlint check failures finally fatal. It's just that someone will have to sustain the wrath of packagers (and coolo who wants so create snapshots) afterwards :-)
I don't know if the ':-)' was meant for the whole paragraph. If not, what you wrote is - as far as I see - a total misunderstandig of what Stanislav Brabec meant. Using whatever check-tool on top of RPM is the totally wrong way to "solve" any intrinsic problem in RPM. Therefore the wrath of packagers who are annoyed by fatal failures of whatever check-tools on top of RPM is correct and justified. Remember RFC1925 in particular item (6) and (6a) therein. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Johannes Meixner wrote:
On Feb 12 13:52 Ludwig Nussel wrote (shortened):
Stanislav Brabec wrote:
Example: Imagine, that %run_ldconfig was deprecated in SuSE several years ago, but it is still widely found in our packages. Exactly the same situation affect Shared Library Packaging Rules. Now multiply the amount of work (or time) to fix the whole distro by 5-10 and you are near to the spec file unification.
Well, that's just a matter of making certain rpmlint check failures finally fatal. It's just that someone will have to sustain the wrath of packagers (and coolo who wants so create snapshots) afterwards :-)
I don't know if the ':-)' was meant for the whole paragraph. If not, what you wrote is - as far as I see - a total misunderstandig of what Stanislav Brabec meant. Using whatever check-tool on top of RPM is the totally wrong way to "solve" any intrinsic problem in RPM.
Actually I didn't intend to participate in a philosophical discussion about rpm, spec files nor how packaging policy gets applied. I had the impression that there is some frustration that even basic policy changes aren't fully enforced after years. I wanted to remind that someone has to step up and just do it in those specific cases mentioned above. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Ludwig Nussel wrote:
Johannes Meixner wrote:
I don't know if the ':-)' was meant for the whole paragraph. If not, what you wrote is - as far as I see - a total misunderstandig of what Stanislav Brabec meant. Using whatever check-tool on top of RPM is the totally wrong way to "solve" any intrinsic problem in RPM.
I had the impression that there is some frustration that even basic policy changes aren't fully enforced after years. I wanted to remind that someone has to step up and just do it in those specific cases mentioned above.
Even such simple policy change needs years to complete just because rpm has no way to do it globally. All packagers are involved and every one has to complete the task for all maintained packages: grep ^%run_ldconfig */*.spec | wc -l 359 How many years would take enabling of final force-fail check for Fedora incompatible packages? Here is an example from class based build system: openembedded/classes/package.bbclass, line 662: postinst += bb.data.getVar('ldconfig_postinst_fragment', d, 1) Changing of ldconfig_postinst_fragment value you will change this policy for all packages in the whole distribution. New policy can be enforced in less that one minute. Benefits: Work time to implement: 0.01% Time required to enforce policy: 0.0001% -- 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
Stanislav Brabec wrote:
Ludwig Nussel wrote:
Johannes Meixner wrote:
I don't know if the ':-)' was meant for the whole paragraph. If not, what you wrote is - as far as I see - a total misunderstandig of what Stanislav Brabec meant. Using whatever check-tool on top of RPM is the totally wrong way to "solve" any intrinsic problem in RPM.
I had the impression that there is some frustration that even basic policy changes aren't fully enforced after years. I wanted to remind that someone has to step up and just do it in those specific cases mentioned above.
Even such simple policy change needs years to complete just because rpm has no way to do it globally.
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 :-)
How many years would take enabling of final force-fail check for Fedora incompatible packages?
No idea but that has nothing to do with rpm. You'd have the very same problem with any other system if you have to modify thousands of legacy packages in two projects with different origins.
Here is an example from class based build system:
openembedded/classes/package.bbclass, line 662: postinst += bb.data.getVar('ldconfig_postinst_fragment', d, 1)
Changing of ldconfig_postinst_fragment value you will change this policy for all packages in the whole distribution.
New policy can be enforced in less that one minute.
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? I have no idea what a 'class based build system' is supposed to be. 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. You can have that with rpm too. It's just that we have thousands of packages that have no tags. Even more clever than having ldconfig calls in post install scripts would be if rpm could call an appropriate post installation action automatically according to package contents. After all it already knows that the package installs stuff to e.g. /usr/lib or /usr/share/info so it could call ldconfig/install-info etc automatically. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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
On Thursday 12 of February 2009 17:37:18 Ludwig Nussel wrote:
Stanislav Brabec wrote:
Ludwig Nussel wrote:
Johannes Meixner wrote:
I don't know if the ':-)' was meant for the whole paragraph. If not, what you wrote is - as far as I see - a total misunderstandig of what Stanislav Brabec meant. Using whatever check-tool on top of RPM is the totally wrong way to "solve" any intrinsic problem in RPM.
I had the impression that there is some frustration that even basic policy changes aren't fully enforced after years. I wanted to remind that someone has to step up and just do it in those specific cases mentioned above.
Even such simple policy change needs years to complete just because rpm has no way to do it globally.
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 :-)
And we will get another 'Please not bypass a devel project' [1] e-mail here. We have a BuildService, we have a devel projects, we are opened and we would like to have a big participating community, ... But we still use an internal build system to break it all. It's not a technical question about merging capabilities of osc, but rather about some processes we use, because we wouldn't break a devel projects even we would improve a spec file quality by removal of deprecated constructs in spec. No one volunteer (and a regular package maintainer) would be happy, if someone thirds somtimes breaks his packages in Devel project in OBS. I know that this is a quickest approach to fix it, and it was used many times. But nowadays with buildservice and a devel projects it shouldn't be used anymore. It simply breaks a whole idea of Buildservice and an opened development of openSUSE. Interesting question is, if it's possible to do it with same efficiency and speed using BuildService and devel projects only and what needs to be done to improve it, because I don't see any way how this should be done. But it needs to be discussed on opensuse-buildservice ML ... [1] http://lists.opensuse.org/opensuse-packaging/2009-01/msg00135.html Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Feb 13 09:39 Michal Vyskocil wrote (shortened):
On Thursday 12 of February 2009 17:37:18 Ludwig Nussel wrote:
Stanislav Brabec wrote:
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 :-)
I fully agree here! Why bother all packagers when it could be solved automatically at least for very most cases? When a macro is used, why not change to what the macro evaluates (even if it may evaluate to nil if it has become obsolete)?
And we will get another 'Please not bypass a devel project' [1] e-mail here. ... [1] http://lists.opensuse.org/opensuse-packaging/2009-01/msg00135.html
I have nothing to do with Gnome but I do not understand what the mail is about. When I am a package maintainer for a software package called "foo", I am not interested in which zillions of whatever kind of projects the software package "foo" is used. I am only interested to get the right package sources for "foo". What is "the right package sources"? I don't know and I don't want to know! All I know is that someone may have told me that "foo" has a bug in e.g. "openSUSE 11.0" or that I like to provide the newest version of "foo" for "the openSUSE project". If I have to fix a bug in "foo" for "openSUSE 11.0" I do: 1. getpac foo for openSUSE 11.0 (I know our exact syntax ;-) 2. change the package sources so that the bug is fixed 3. submitpac foo for openSUSE 11.0 If I like to provide the newest version of "foo" for "the openSUSE project" I do: 1. getpac foo for openSUSE 2. change the package sources so that it includes the newest version 3. submitpac foo for openSUSE If this somehow disturbs whatever other project which depends somehow on "foo", it is not my problem - it is only a problem of the packaging environment. By the way: getpac foo for this followed by a submitpac foo for that shoud exit with a nice red blinking error message but submitpac foo enforce for that might be a reasonable functionality. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday 13 of February 2009 10:52:35 Johannes Meixner wrote:
Hello,
On Feb 13 09:39 Michal Vyskocil wrote (shortened):
On Thursday 12 of February 2009 17:37:18 Ludwig Nussel wrote:
Stanislav Brabec wrote:
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 :-)
I fully agree here! Why bother all packagers when it could be solved automatically at least for very most cases? When a macro is used, why not change to what the macro evaluates (even if it may evaluate to nil if it has become obsolete)?
And we will get another 'Please not bypass a devel project' [1] e-mail here.
...
[1] http://lists.opensuse.org/opensuse-packaging/2009-01/msg00135.html
I have nothing to do with Gnome but I do not understand what the mail is about. When I am a package maintainer for a software package called "foo", I am not interested in which zillions of whatever kind of projects the software package "foo" is used.
We have a nice idea and feature called Colaboration [1]. We have a BuildService, concept of devel projects and things should be opened for external contributors, because we (as SUSE) want to get more volunteers for openSUSE from community. Problem is, that as an external volunteer you don't have any other way as use a BuildService, so you have a link of foo from openSUSE:Factory/foo to your devel project. And when you did some changes in foo and anyone use an internal getpac, subpac, then your devel/foo package will be broken, because Global patches cannot be applied. The same problem is if anyone use submitreq from another project to Factory. Or when you send a submitreq with version update, and meanwhile anyone use getpac/subpac to fix something. I fixed this problem some days ago in my package. Things get worst, as there's nothing like merge, or git's rebase in osc, so you must fix the conflicts manually. [1] http://en.opensuse.org/Build_Service/Collaboration Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Feb 13 11:35 Michal Vyskocil wrote (shortened):
On Friday 13 of February 2009 10:52:35 Johannes Meixner wrote:
On Feb 13 09:39 Michal Vyskocil wrote (shortened):
And we will get another 'Please not bypass a devel project' [1] e-mail here. ... [1] http://lists.opensuse.org/opensuse-packaging/2009-01/msg00135.html
I have nothing to do with Gnome but I do not understand what the mail is about. When I am a package maintainer for a software package called "foo", I am not interested in which zillions of whatever kind of projects the software package "foo" is used.
We have a nice idea and feature called Colaboration [1]. ... [1] http://en.opensuse.org/Build_Service/Collaboration
You misunderstood what I actually meant because we do have internal tools which are called "getpac" and "submitpac" and unfortunately I used those names. But I did mean our actual internal tools getpac and submitpac. I meant "getpac" and "submitpac" only as placeholders. I do not care at all hwo the tool is called (getpac, submitpac, osc, whatever else). I just want to have a tool which does what I described. Now regarding our actual internal tools getpac and submitpac: When I can use our internal tools getpac and submitpac (without getting error or warning messages) and when this disturbs whatever other project which depends somehow on my packages, it is not my problem - it is only a problem of the packaging environment. By the way: I wrote: If I have to fix a bug in "foo" for "openSUSE 11.0" I do: 1. getpac foo for openSUSE 11.0 2. change the package sources so that the bug is fixed 3. submitpac foo for openSUSE 11.0 You may wonder what should happen if "foo" fails to build in the "openSUSE 11.0" build environment. Not the packager but submitpac would have to care about this. If build fails, the new but broken package sources should not be comitted to the "openSUSE 11.0" package source repository so that a subsequent "getpac foo for openSUSE 11.0" should result the old clean sources together with a notification that there are newer submitted but not comitted sources and a reason why the newer sources are not comitted. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, a typo: On Feb 13 14:15 Johannes Meixner wrote (shortened):
You misunderstood what I actually meant because we do have internal tools which are called "getpac" and "submitpac" and unfortunately I used those names. But I did mean our actual internal tools getpac and submitpac.
But I did not mean our actual internal tools getpac and submitpac. Sorry for causing even more confusion :-( Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le vendredi 13 février 2009, à 10:52 +0100, Johannes Meixner a écrit :
On Feb 13 09:39 Michal Vyskocil wrote (shortened):
And we will get another 'Please not bypass a devel project' [1] e-mail here. ... [1] http://lists.opensuse.org/opensuse-packaging/2009-01/msg00135.html
I have nothing to do with Gnome but I do not understand what the mail is about. When I am a package maintainer for a software package called "foo", I am not interested in which zillions of whatever kind of projects the software package "foo" is used.
Oh, right. Except that GNOME:Factory is where the GNOME maintainers maintain their packages. So your sentence should be "When I am not a package maintainer for 'foo' but I want to update 'foo', I do..."
I am only interested to get the right package sources for "foo". What is "the right package sources"? I don't know and I don't want to know! All I know is that someone may have told me that "foo" has a bug in e.g. "openSUSE 11.0" or that I like to provide the newest version of "foo" for "the openSUSE project".
If I have to fix a bug in "foo" for "openSUSE 11.0" I do: 1. getpac foo for openSUSE 11.0 (I know our exact syntax ;-) 2. change the package sources so that the bug is fixed 3. submitpac foo for openSUSE 11.0
If I like to provide the newest version of "foo" for "the openSUSE project" I do: 1. getpac foo for openSUSE 2. change the package sources so that it includes the newest version 3. submitpac foo for openSUSE
Really, you can do all that with the build service: osc branch openSUSE:11.0 foo or osc branch openSUSE:Factory foo It will do the right thing and branch from where it should be branched (eg, GNOME:Factory) when needed. You do your changes, and then osc sr create -m "I updated this" It will again do the right thing and submit the package where it should be submitted. So really, there's no issue here except that some people do not use the build service. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le vendredi 13 février 2009, à 09:39 +0100, Michal Vyskocil a écrit :
On Thursday 12 of February 2009 17:37:18 Ludwig Nussel wrote:
for/getpac/sed/submitpac :-)
[...]
Interesting question is, if it's possible to do it with same efficiency and speed using BuildService and devel projects only and what needs to be done to improve it, because I don't see any way how this should be done. But it needs to be discussed on opensuse-buildservice ML ...
Sure it's possible. for/osc branch/osc co/sed/osc sr/ The magic is that "osc branch" does the right thing and branches from the devel project. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, on 02/11/2009 03:51 PM Michal Vyskocil wrote:
I compared a Fedora Packaging Guidelines [1] and SUSE Packaging Convetions [2] and I think that Fedora documentation is really better than we provide.
[...]
If we want to help a community to participate on openSUSE (for example packaging in Contrib) we also need a better documentation than we have.
It's probably not what you want to hear but i can tell you this: If you won't do it nobody will. So take whats there and structure it how you think its best for the users. Then come back here, propose your results and collect feedback. If you get feedback then incorporate it. Repeat that cycle unless you are certain that you incorporated all feedback. In the end put it into place. This is what you can do and this is the only way to resolve this particular task. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday 11 of February 2009 16:54:54 Henne Vogelsang wrote:
Hi,
on 02/11/2009 03:51 PM Michal Vyskocil wrote:
I compared a Fedora Packaging Guidelines [1] and SUSE Packaging Convetions [2] and I think that Fedora documentation is really better than we provide.
[...]
If we want to help a community to participate on openSUSE (for example packaging in Contrib) we also need a better documentation than we have.
It's probably not what you want to hear but i can tell you this:
I did not expect any other response ;-)
If you won't do it nobody will. So take whats there and structure it how you think its best for the users. Then come back here, propose your results and collect feedback. If you get feedback then incorporate it. Repeat that cycle unless you are certain that you incorporated all feedback. In the end put it into place.
You're right. I just tried to check, if anyone has some idea what's really missing now.
This is what you can do and this is the only way to resolve this particular task.
Henne
-- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson
Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mittwoch 11 Februar 2009 15:51:02 Michal Vyskocil wrote:
Or another example - is really necessary talk about BuildService account on packaging cookbooks of KDE[5] or Java[6]? In fact with this structure, where they exists outside Packaging/ it makes a sense, but it's really necessary?
Please "ping" the original authors of the pages you've mentioned.
So main questions are: - how could be Packaging/ maintained (eg. we would have a Docbook original somewhere and convert it to wiki as SUSE packaging
NO! We've a docbook in the past, but writing xml (even with the best editor in town) is ugly. That's why we use the wiki for it: it's easier to get people working/fixing things in the wiki than in a separate book stored in a CVS somewhere else. But: it might be a good idea to have some tools which extract the wiki pages from time to time and produce some kind of PDF, static HTML or something like that for users without internet access.
conventions [2])? - how could we structure existing information to be more readable and useful for community?
=> Should be something for the Wiki Mailingllist, too - CCing...
- what is missing, or unclear and needs to be improved? (- and who will do this all ;-))
[1] http://fedoraproject.org/wiki/Packaging:Guidelines [2] http://en.opensuse.org/Packaging/SUSE_Package_Conventions [3] http://en.opensuse.org/Packaging/ [4] https://fedoraproject.org/wiki/Packaging/LicensingGuidelines [5] http://en.opensuse.org/KDE/Packaging/Cookbook [6] http://en.opensuse.org/Java/Packaging/Cookbook
Regards, Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (15)
-
Adrian Schröter -
Andreas Jaeger -
Andrew Wafaa -
Cristian Morales Vega -
Henne Vogelsang -
Johannes Meixner -
Juergen Weigert -
Karl Eichwalder -
Lars Vogdt -
Ludwig Nussel -
Michal Vyskocil -
Stanislav Brabec -
Stephan Kulow -
Vincent Untz -
Vladimir Nadvornik