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