Why do applications have to be packaged for each distribution?

conan1989 · 2015-04-21 12:36:29

Hi,
Sorry this is probably a stupid question, but i don't understand why it's necessary for each application to be packaged (and patched) by each distribution.
Example: (as i understand it) Mozilla Firefox. Arch has it's own version derived from Mozilla's, and so do the other distributions with their own variations.
Is anyone able to explain how this works and why it's done this way?

Bonus points: If anyone has a link to an article explaining in detail, would be very interesting to read

fsckd · 2015-04-21 13:08:01

While this is a newbie question, this subforum is for questions about Arch Linux. I'll move this thread to GNU/Linux Discussion.

Different distros try to solve different problems and have different approaches to the same problem. For example, Debian patch their packages heavily to fix bugs and other problems. Arch makes as few patches as possible to encourage fixes to be submitted upstream.

karol · 2015-04-21 13:26:11

The packaging formats and package managers differ too, some might be geared towards power at the cost of making it harder for packagers / maintainers to create PKGBUILDs / specs / recipes etc.
Some package managers use database backend, others rely on files. This might trade complexity for speed and memory use.

Trilby · 2015-04-21 13:44:13

Caution: broad generalizations from personal experience follow.

RPM is designed to be easy for developers and packagers - but is a royal PITA for an average user trying to install anything.

Deb is designed to be easy for "end-users" - but is a ginormous PITA for packaging.

Arch packages were designed by drunken taco-eating monkeys on a broken typewriter. And yet they work far better for both packagers and users.

ewaller · 2015-04-21 14:10:11

It is difficult to expand upon what Trilby said (priceless) but... Often an application has configuration options built right into them. The gnu build system allows you to pass parameters into the configure utility. These can define whether a tool like emacs has a GUI interface or not. It can define whether a package is going to or is not going to support things like Avahi. Or whether data will be kept in dot files or in a sql database. Whether documentation is to be includes. Whether it uses ASCII or unicode, whether it does or does not support right to left languages. etc...

Some distributions (Gentoo) allow users to set these options ('use' flags in Gentoo). In Arch, these parameters are set in the PKGBUILD. The default build configurations in Arch crafted to fit with options selected used in other packages. That is also why we sometimes have packages that provide the same thing packaged differently; example vim vs gvim.

Last edited by ewaller (2015-04-21 14:11:01)

brebs · 2015-04-21 14:39:21

conan1989 wrote:

each application to be packaged (and patched) by each distribution.

As an example, Arch uses giflib 5.1.1, whereas the majority of other distros (e.g. Ubuntu and Fedora) are on 4.1 or 4.2.

giflib 5.1.1 has a changed API & ABI, needing e.g. patch for windowmaker. Previously, quite a few other packages needed such a patch, e.g. openjdk7.

Software linking is darn *fragile*, and APIs of Linux software are too-often changing.

Blµb · 2015-04-24 08:01:11

When packaging software there are a bunch of questions you're facing. Many have been mentioned before.
This starts with the compile-time configuration regarding which parts of the software should be compiled/used, eg some libraries can use different backends and you can only choose one. Sometimes it's even a matter of licensing. Some distros like to enable experimental features if they don't break the rest of the software, some let you choose (like gentoo's useflags mentioned above).

Filesystem layouts differ: Some prefer /usr/lib/pkgconfig, some /usr/share/pkgconfig; some like /usr/libexec, some don't, some (eg FreeBSD, which isn't linux but with regard to package management faces the same questions) use /usr/local for packages. Some distinguish between binary-only packages by putting them into /opt, some don't. Some actually have /bin, /usr/bin and /usr/local/bin as separate directories
Or you might go a completely different way, too, nobody's forcing you to stick to "standards". I'd also like to point to haiku, also not a linux distro, but there too you have most of the same software packages available, which have to follow different directions there, too.

Default configurations: Some get patched (themed for the distro or for other reasons), some don't.

Init systems: Gentoo (at least last time I checked) defaults to openrc. Most people do not provide openrc scripts in their source repositories, so the packager is responsible for creating these.

Gentoo actually brings up another thing: it allows for some packages to have multiple versions installed, and you can use them explicitly and/or switch your default with `eselect`. (It probably does more than that, I haven't used gentoo in years.) For this of course you need to package your software in a certain way. Eg put your binaries and libraries into a separate folder and symlink them to their desired locations, rather than installing them there directly, since they'd be overwritten by the other versions of the package...

brebs · 2015-04-24 08:25:51

Blµb wrote:

Some prefer /usr/lib/pkgconfig, some /usr/share/pkgconfig

That's a multi-lib issue.

If a package has no multi-lib issues (e.g.randrproto because it's just headers), then can use /usr/share/pkgconfig/

If a package is multi-lib, then use /usr/lib/pkgconfig/ and e.g. /usr/lib32/pkgconfig/, to distinguish.

Upstream often get this *wrong*, so I have a commonly-used function:

use_pkgconfig_share_dir() {
    # For xorg proto pkgs, into /usr/share not /usr/lib, for multi-lib
    sed -e "/^pkgconfigdir =/s/.*/pkgconfigdir = \/usr\/share\/pkgconfig/" -i Makefile*
}

Blµb · 2015-04-24 09:07:03

makes sense, and explains why I haven't caught on to that yet

89c51 · 2015-04-24 18:28:38

Another related and maybe good question will be how moving to a container (???) type approach -like the one Lennart wrote a few months ago and i think snappy and docker try similar stuff- and how this will affect distros, package managers and ultimately arch and pacman.

karol · 2015-04-24 19:14:25

I don't see the need for containers on a desktop.

If somebody is interested in various ways you can package software, there's Wikipedia https://en.wikipedia.org/wiki/Category: … nt_systems :
* https://en.wikipedia.org/wiki/Image_Packaging_System
* https://en.wikipedia.org/wiki/Zero_Install
etc.

Arch Linux

#1 2015-04-21 12:36:29

Why do applications have to be packaged for each distribution?

#2 2015-04-21 13:08:01

Re: Why do applications have to be packaged for each distribution?

#3 2015-04-21 13:26:11

Re: Why do applications have to be packaged for each distribution?

#4 2015-04-21 13:44:13

Re: Why do applications have to be packaged for each distribution?

#5 2015-04-21 14:10:11

Re: Why do applications have to be packaged for each distribution?

#6 2015-04-21 14:39:21

Re: Why do applications have to be packaged for each distribution?

#7 2015-04-24 08:01:11

Re: Why do applications have to be packaged for each distribution?

#8 2015-04-24 08:25:51

Re: Why do applications have to be packaged for each distribution?

#9 2015-04-24 09:07:03

Re: Why do applications have to be packaged for each distribution?

#10 2015-04-24 18:28:38

Re: Why do applications have to be packaged for each distribution?

#11 2015-04-24 19:14:25

Re: Why do applications have to be packaged for each distribution?

Board footer