pretty short article for a major distro release. cant wait for testing to become ... modern.... now.
Announcement
Collapse
No announcement yet.
Debian 7.0 "Wheezy" Officially Released
Collapse
X
-
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.
Leave a comment:
-
Originally posted by varikonniemi View PostProbably 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.
Originally posted by Wilfred View PostAs 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?
Leave a comment:
-
Originally posted by varikonniemi View PostProbably 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.
So which features does rpm have which deb does not?
Leave a comment:
-
Originally posted by varikonniemi View PostProbably 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.
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.
Leave a comment:
-
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.Last edited by varikonniemi; 08 May 2013, 03:30 AM.
Leave a comment:
-
Originally posted by Sonadow View PostIt'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.
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.
Leave a comment:
-
Originally posted by Kostas View PostWonder if they managed to reach Debian's expected stability despite having such an old and outdated GNOME version.
BTW, since they focus so much on the new multiarch support, I wonder how their way is different to the way Fedora handles it?
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.
Leave a comment:
-
Wonder if they managed to reach Debian's expected stability despite having such an old and outdated GNOME version.
BTW, since they focus so much on the new multiarch support, I wonder how their way is different to the way Fedora handles it?Last edited by Kostas; 06 May 2013, 10:12 PM.
Leave a comment:
Leave a comment: