Debian 7.0 "Wheezy" Officially Released

[Wilfred]

It's totally different from RPM-style multilib.

Fedora (and virtually all RPM-based distributions that have adopted the /usr merge) split libraries into a /usr/lib and a user/lib64, where /usr/lib stores 32bit libraries and a handful of important 64bit libraries. /usr/lib/64 stores the remaining majority of the 64bit libraries.

Before multiarch on Debian was available the Debian way was to have a /lib and /lib32, where /lib stores the 64bit libraries and /lib32 stores the runtime libraries installed by the ia32-libs package (which only contains the most commonly used 32bit runtime libraries, and not the whole set of 32bit libraries).

With multiarch Debian now stores libraries in the /usr/lib/<architecture>/ format so you will get something like this in the root directory:

/usr/lib/ia32(or was it i586, can't remember)/
usr/lib/amd64/
usr/lib/arm/
usr/lib/arm64/

As you can see the very nice thing about Debian's style of multiarch is that there is only one /lib directory at the top level, with all the architectures being separated into their own folder at a lower level. The RPM way of having usr/lib and usr/lib64 was definitely superior to Debian's then non-standard /lib32 and /lib implementation, but the new way Debian handles multiarch in 7.0 is now definitely more elegant than the current /usr/lib and usr/lib64 implementation.

The question is whether the RPM-based distributions will adopt the Debian way of multiarch now. I hope they do, but not holding my breath.

It's /usr/lib/i386-linux-gnu/ and /usr/lib/x86_64-linux-gnu/.
After getting used to it, I quite like it. I really hope Redhat/Suse/Gentoo will also implement it, but I'm not expecting it.

[uid313]

Debian /usr merge

Will Debian do the /usr merge?

[varikonniemi]

Probably not, since it was not invented there. Just look at them sticking with .deb even though RPM is technically superior and recommended by LSB. Even the RPM version they recommend had to be neutered since .deb simply is not capable of all the features of RPM even after conversion using alien.

If they could let go of their NIH syndrome, this silly restriction to LSB RPM would be thrown away.

[Sonadow]

Probably not, since it was not invented there. Just look at them sticking with .deb even though RPM is technically superior and recommended by LSB. Even the RPM version they recommend had to be neutered since .deb simply is not capable of all the features of RPM even after conversion using alien.

If they could let go of their NIH syndrome, this silly restriction to LSB RPM would be thrown away.

except that .deb did come out before RPM and they were the ones who created that packaging format. You are probably have to pry .deb out of their cold dead hands.

It's like Microsoft having created .exe and .msi as the de facto formats for Windows and suddenly some wise guy from another department says "hey I have a new packaging format .abc which should become the standard packaging and executable format for Windows and you have to use it as the new standard format because the Microsoft board said so." No way will the Windows department obey that order.

[Wilfred]

Probably not, since it was not invented there. Just look at them sticking with .deb even though RPM is technically superior and recommended by LSB. Even the RPM version they recommend had to be neutered since .deb simply is not capable of all the features of RPM even after conversion using alien.

If they could let go of their NIH syndrome, this silly restriction to LSB RPM would be thrown away.

As already mentioned deb is older than rpm, so it would have to be RedHat which would have to change. Furthermore AFAIK rpm does not have the recommends and suggests which deb does have. RPM does indeed have the capability to depend on the existence of a file instead of an installed package which is completely insane IMHO. Also lots of weird features of rpm have been removed the last couple of years.

So which features does rpm have which deb does not?

[Serge]

Probably not, since it was not invented there. Just look at them sticking with .deb even though RPM is technically superior and recommended by LSB. Even the RPM version they recommend had to be neutered since .deb simply is not capable of all the features of RPM even after conversion using alien.

If they could let go of their NIH syndrome, this silly restriction to LSB RPM would be thrown away.

I think that having RPM as the only packaging format in the spec is the reason why LSB never took off. I think the LSB developers and writers should just have skipped that part of the spec. Better and more experienced standards bodies have figured out that it's more effective to wait for a de facto standard to emerge instead of trying to proscribe a de jure standard where a de facto one does not exist. Blame spite, NIH, whatever you want, but bottom line is it's LSB that failed, not Debian and its derivatives who failed to adopt it. Oh, yeah, and let's not forget that in the modern world, "Debian and its derivatives" most likely refers to over half the Linux user base.

As already mentioned deb is older than rpm, so it would have to be RedHat which would have to change. Furthermore AFAIK rpm does not have the recommends and suggests which deb does have. RPM does indeed have the capability to depend on the existence of a file instead of an installed package which is completely insane IMHO. Also lots of weird features of rpm have been removed the last couple of years.

So which features does rpm have which deb does not?

Delta downloads is the most important one that comes to mind. I never really cared much for the specifics of this argument, I just notice that it always ends in a stalemate. As it probably will this time as well.

[Ibidem]

I hope Debian doesn't do the /usr merge, and Debian policy appears to look strongly askance at it (starting after $local_fs, etc.)
The standard approach is to increase the number of supported scenarios, rather than decreasing them.

A *.deb package is an ar archive containing two tarballs. RPM is a varying binary format (currently around version 5, IIRC) which apparently has some relationship to cpio, but can only be read by custom tools.
Now, to install an RPM-based system, you need to start with a custom tool. To install a debian-based system, two archivers that are found on any unix-like system capable of building software are all you need to start...with the result that someone who knows what they are doing can install Debian Linux from a BSD system.
Reusing standard tools gives you a much more flexible system.
Delta downloads are an interesting feature...when everyone has access to the repository. LSB RPM is meant for those who ship proprietary software for multiple distros, which for quite some time meant shipping CDs with packages. At present, there isn't a universal package manager capable of handling repositories, let alone delta downloads; to establish this would likely require standardizing apt, yum, or zypper, or at least an archive format...which is likely to be a worse mess than dpkg vs rpm.

[Ray7brian2]

pretty short article for a major distro release. cant wait for testing to become ... modern.... now.