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 15:36:04 +0100
  • Message-id: <1234449365.28128.189.camel@xxxxxxxxxxxxxx>
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:

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:


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

- Better scripts:
- One time triggers: we really need to call ldconfig, font cache
updates, icon cache updates etc. just once to finally get rid
- 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):

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"
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.)


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@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 >