- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Consistent Packaging for Linux Apps
Then I came across this piece about something that Mark Shuttleworth , the person behind the Ubuntu movement, had written, and I was intrigued. He points out that in many ways, the differences between the two packaging formats are more hindrance than help to the end user. Could this really be true? Ah, that is the real question, I suspect. |
|
|
Comments (19)
> Yum and apt-get are pretty much the standards now.
When even Slackware has slapt-get, I'm forced to agree.
When even Slackware has slapt-get, I'm forced to agree.
I use PCLOS, which uses apt with rpm packages. Works fine for me.
Yum and apt are package managers, not package formats. They key here is package formats.
First off, the author was referring to the many projects that only offer a tar.gz GNU source package.
Second, .deb and .rmp are far from perfect. I can't build a .deb and expect it to work across debian deratives. I have to create separate .deb's for every version of every distribution (which is why I pitch my software to distro packagers so their build systems can take care of it). dsc (debian source packages) work more consisitently but need to be compiled to .deb's first, but you can make many different .deb's out of one .dsc. But not even that works consistently. For example, Ubuntu Edgy doesn't carry gnome-cards-data which is a required dependency on Debian etch for my gnome-hearts game. So I still have two separate .dsc's.
What would be nice is some kind of source packaging that can be automatically compiled to both .dsc and source rpm (which can then automatically be compiled to binary OS/version specific packages). That would go some way to fix the packaging mess.
Quoting:Then the author goes on to say "Until we can come together on a packaging scheme that meets with everyone's needs, let's consider offering rpm and deb packages." Um. We have those already.
First off, the author was referring to the many projects that only offer a tar.gz GNU source package.
Second, .deb and .rmp are far from perfect. I can't build a .deb and expect it to work across debian deratives. I have to create separate .deb's for every version of every distribution (which is why I pitch my software to distro packagers so their build systems can take care of it). dsc (debian source packages) work more consisitently but need to be compiled to .deb's first, but you can make many different .deb's out of one .dsc. But not even that works consistently. For example, Ubuntu Edgy doesn't carry gnome-cards-data which is a required dependency on Debian etch for my gnome-hearts game. So I still have two separate .dsc's.
What would be nice is some kind of source packaging that can be automatically compiled to both .dsc and source rpm (which can then automatically be compiled to binary OS/version specific packages). That would go some way to fix the packaging mess.
The major distributions carry thousands of packages. It's the wee fringe projects, or bleeding-edge new stuff that comes only in tarballs. It's been a long time since I couldn't just yum-install or aptitude-install something I wanted. Maybe my experience isn't typical, but it seems to me that griping about tarballs is a pretty outdated gripe.
"What would be nice is some kind of source packaging that can be automatically compiled to both .dsc and source rpm (which can then automatically be compiled to binary OS/version specific packages). "
Yes, that sounds good.
(edited to fix weird HTML stuff that disappeared)
"What would be nice is some kind of source packaging that can be automatically compiled to both .dsc and source rpm (which can then automatically be compiled to binary OS/version specific packages). "
Yes, that sounds good.
(edited to fix weird HTML stuff that disappeared)
>Maybe my experience isn't typical, but it seems to me that griping about tarballs is a pretty outdated gripe.
I think your experience is typical. For the most part, those programs that need to be installed from a tarball aren't ones for beginners. There's nothing that a new/inexperienced user will need that won't be in 95% of the repos out there, it might even be in all of them. If you need a program that can only be installed from a tarball, you probably know what you're doing. Sure, there might be exceptions, but a few exceptions aren't going to render an OS unusable to beginners.
I think your experience is typical. For the most part, those programs that need to be installed from a tarball aren't ones for beginners. There's nothing that a new/inexperienced user will need that won't be in 95% of the repos out there, it might even be in all of them. If you need a program that can only be installed from a tarball, you probably know what you're doing. Sure, there might be exceptions, but a few exceptions aren't going to render an OS unusable to beginners.
Actually there's a *lot* that is only available as a tar.gz (including for example, the Linux kernel and Gnome). The fact that most distro's carry the software in a package is thanks to that distro's volunteers, not to the people that write the software. I think the author is griping that soooo much effort needs to be spent on packaging. If there was a universal (source) packaging format then much less enegry would be spent on constantly repackaging software for different distributions.
In a way, tar.gz *is* the universal source packaging format. The problem with it is that you can't specify anything but the most basic build dependencies in it. This makes it useless for distro's who now have to spend an incredible ammount of time adding all the stuff that's common to modern packaging formats. I think the author is griping for a successor to tar.gz
In a way, tar.gz *is* the universal source packaging format. The problem with it is that you can't specify anything but the most basic build dependencies in it. This makes it useless for distro's who now have to spend an incredible ammount of time adding all the stuff that's common to modern packaging formats. I think the author is griping for a successor to tar.gz
>Yum and apt are package managers, not package formats. They key here is package formats.
Since most everything can be installed from the package manager, where the package format is transparent, the key here is that this is a moot point. It's not that I don't understand that sometimes there are problems, just that the users of most distros need not give a hoot about it.
>much simpler licensing terms and of course - a better ecosystem for software developers.
That's from the article. Um...I really don't know what to make of it.
Since most everything can be installed from the package manager, where the package format is transparent, the key here is that this is a moot point. It's not that I don't understand that sometimes there are problems, just that the users of most distros need not give a hoot about it.
>much simpler licensing terms and of course - a better ecosystem for software developers.
That's from the article. Um...I really don't know what to make of it.
> First off, the author was referring to the many projects that only offer a tar.gz GNU source package.
A tar.gz source package can be compiled on any Linux system. An rpm or deb package is far more distro specific, often limited to a handful of distros.
> What would be nice is some kind of source packaging that can be automatically compiled to both .dsc and source rpm
Not exactly what you want, as it compiles to binary deb and rpm files, but take a look at checkinstall.
A tar.gz source package can be compiled on any Linux system. An rpm or deb package is far more distro specific, often limited to a handful of distros.
> What would be nice is some kind of source packaging that can be automatically compiled to both .dsc and source rpm
Not exactly what you want, as it compiles to binary deb and rpm files, but take a look at checkinstall.
The 'package format battle' is almost completely a non-issue, as what matters most is if the package's /contents/ have been specifically designed to fit your distribution, not what container it comes in. Every so often, the idea to do a generic package format comes up, and completely misses that point. Since it goes without saying if you have designed the content to fit a given distribution, you would put it in that distribution's packaging, the only thing left of such an argument is that having one format instead of two slightly lessens the maintenance load on Synaptic/KPackage.
swbrown: A better universal source packaging format (not a binary format like rpm or deb but a source formal like dsc) would allow shifting the burden of packaging from the distribution to the upstream author. That means avoining lots of duplicate work, freeing up volunteer time to do other usefull things.
"would allow shifting the burden of packaging from the distribution to the upstream author"
This is another variant of that common idea that comes up often that misses the point.
Example: what distribution is the upstream author going to target with their packaging? All of them? What about Debian's menu system, pre/post install system, and split configuration file formats? Fedora with its different FS hierarchy, menu system, init scripts, etc.? Familiar Linux with its reduced form factor, custom sized icons, and ram disks for intermediate files? What about the dependencies which will be different versions, and often names, on every distribution? What about automatically upgrading from past versions, including data migration? What toolchain is it to be built for?
The value of packaging is when the /contents/ are laser-targetted to fit perfectly within a /specific/ distribution. The upstream author can't possibly provide that. What you'd wind up with is package quality like you see with use of alien.
This is another variant of that common idea that comes up often that misses the point.
Example: what distribution is the upstream author going to target with their packaging? All of them? What about Debian's menu system, pre/post install system, and split configuration file formats? Fedora with its different FS hierarchy, menu system, init scripts, etc.? Familiar Linux with its reduced form factor, custom sized icons, and ram disks for intermediate files? What about the dependencies which will be different versions, and often names, on every distribution? What about automatically upgrading from past versions, including data migration? What toolchain is it to be built for?
The value of packaging is when the /contents/ are laser-targetted to fit perfectly within a /specific/ distribution. The upstream author can't possibly provide that. What you'd wind up with is package quality like you see with use of alien.
It should target LSB. If a distro deviates from LSB it bears the burden of modifying the packages themselves. Even if a unifies source package format can only shift half the burden upstream then it'll be worth it. The ammount of time spent repackaging software is enormous - larger than the actual coding I think.
"It should target LSB. If a distro deviates from LSB it bears the burden of modifying the packages themselves."
Let me try this from a different angle.
Think of Windows XP as a platform. It's orders of magnitude more standardized than the LSB provides, or will ever provide, seeing as it comes from a single source, runs on a single platform, and infrequently changes. And on Windows XP, the upstream authors all package their own software, and they generally only support that one platform, so all that should make for a best-case for upstream packaging.
So, how does that work out? I have games that save screenshots somewhere in C:Program Files, My Documents, per-user Application Data, global Application Data, or a directory directly off of C:. They provide updates either through their own custom updater, InstallShield's updater, Steam, EA Link, GameShadow, or downloadable patches. They might install themselves in the menu under "Games", the name of the company that produced it, the name of the company that distributes it, or directly in the menu. They might have an uninstall link in the menu system and/or be uninstallable from 'Add Remove Programs'. Their documentation and license might be found in C:Program Files, on the CD they came with, on a website link via the menu, or on a website you find directly. Security updates might be provided via the Windows Updater, the Windows Update website, Microsoft Office Update, a custom automatic update in the background, a custom automatic update when you next run the software, a custom automatic update when the administrator next runs the software, a custom updater tool, or a website to download patches from. It's unlikely many applications that won't survive a Vista update will automatically update to support it when I install Vista.
And that's on the highly standardized Windows XP platform with the upstream authors likely only targeting that one platform. Understand the problem now? :)
What Debian and others do is to groom the software to exactly fit their model of how the world should work, which is the main value in a GNU/Linux distribution - everything working the same way. That's also the vast majority of the work they do. In some cases, it's actually /against/ the wishes of the upstream authors (e.g., FireFox's runtime automatic update is disabled by Debian in favor of updating it via apt-get like everything else), so it's totally unrealistic to expect there could ever possibly remotely be a solution where the upstream authors do the distribution packaging themselves and have that turn out better, especially considering that unlike the Windows XP case, their software is likely used on dozens of platform targets, many of which are not Linux-based.
Let me try this from a different angle.
Think of Windows XP as a platform. It's orders of magnitude more standardized than the LSB provides, or will ever provide, seeing as it comes from a single source, runs on a single platform, and infrequently changes. And on Windows XP, the upstream authors all package their own software, and they generally only support that one platform, so all that should make for a best-case for upstream packaging.
So, how does that work out? I have games that save screenshots somewhere in C:Program Files, My Documents, per-user Application Data, global Application Data, or a directory directly off of C:. They provide updates either through their own custom updater, InstallShield's updater, Steam, EA Link, GameShadow, or downloadable patches. They might install themselves in the menu under "Games", the name of the company that produced it, the name of the company that distributes it, or directly in the menu. They might have an uninstall link in the menu system and/or be uninstallable from 'Add Remove Programs'. Their documentation and license might be found in C:Program Files, on the CD they came with, on a website link via the menu, or on a website you find directly. Security updates might be provided via the Windows Updater, the Windows Update website, Microsoft Office Update, a custom automatic update in the background, a custom automatic update when you next run the software, a custom automatic update when the administrator next runs the software, a custom updater tool, or a website to download patches from. It's unlikely many applications that won't survive a Vista update will automatically update to support it when I install Vista.
And that's on the highly standardized Windows XP platform with the upstream authors likely only targeting that one platform. Understand the problem now? :)
What Debian and others do is to groom the software to exactly fit their model of how the world should work, which is the main value in a GNU/Linux distribution - everything working the same way. That's also the vast majority of the work they do. In some cases, it's actually /against/ the wishes of the upstream authors (e.g., FireFox's runtime automatic update is disabled by Debian in favor of updating it via apt-get like everything else), so it's totally unrealistic to expect there could ever possibly remotely be a solution where the upstream authors do the distribution packaging themselves and have that turn out better, especially considering that unlike the Windows XP case, their software is likely used on dozens of platform targets, many of which are not Linux-based.
Windows is anything *but* standardised. LSB is years ahead of it. Also, don't forget we're talking open source software here (or at least open source packaging). An upstream package that doesn't follow the LSB (with for example install locations, etcetera) would get patches from the distribution packagers. Bugs and patches in packages would flow up- and downstream in the same way as currently happens with code.
Distro-specific things can still be kept distro-specific. To take your firefox example further: Debian would ony have to maintain two patches: The one that sets the name to iceweasel and the one that disables automatic updates. Everything else can be done upstream, making sure that the 80% mundane/standardised part of the packaging is only done once, instead of being done for every distro out there.
Debian's dsc already has such functionality. To make an Ubuntu dsc out of a debian dsc for gnome-hearts I simply delete one file from the /patches directory an debuild it.
The more LSB grows, the more feasible and rewarding a unified source packaging system becomes.
Distro-specific things can still be kept distro-specific. To take your firefox example further: Debian would ony have to maintain two patches: The one that sets the name to iceweasel and the one that disables automatic updates. Everything else can be done upstream, making sure that the 80% mundane/standardised part of the packaging is only done once, instead of being done for every distro out there.
Debian's dsc already has such functionality. To make an Ubuntu dsc out of a debian dsc for gnome-hearts I simply delete one file from the /patches directory an debuild it.
The more LSB grows, the more feasible and rewarding a unified source packaging system becomes.
"Windows is anything *but* standardised. LSB is years ahead of it."
I think you don't understand what the LSB is.
I think you don't understand what the LSB is.
I understand well enough. Things like the FSH that the LSB provides are exactly the type of things that are not standardised on Windows. Which is why with Windows programs you find junk all over the place, like you described thee posts up. Same goes for updates. On Linux, updates are provided by the distro. The only reason FireFox has it's own updater is because it runs on Windows too. I can't remember ever using a Linux app that carried it's own updater (well, except for the package manager ;-).
"I understand well enough. Things like the FSH that the LSB provides are exactly the type of things that are not standardised on Windows."
This is where you don't understand. the LSB is to provide /a subset/ of the /existing/ level of platform standardization you find on Windows, in order to make it easier for proprietary third-party companies to target Linux-based platforms. Maybe you're interpreting 'platform standardization' wrong - it's not standard as in a registered standard, it's a measure of the platform's diversity.
Think of it this way - if you only targeted Debian Sarge, that would be like targeting only Windows XP, although XP will remain a stable, supported target for many years longer. However, the GNU/Linux space is diverse, so those proprietary software companies want to target as many platforms as possible with just one build, seeing as they can't rely on the distributors to groom their software to perfectly fit like what happens with Free Software, as they won't have access to the source. As such, they want at least some subset of the various distributions to be a known target they can code for, and they can attempt to pick up the remaining slack themselves. Through certification, customers know which distributions will be able to run the software. That's the role of the LSB.
However, I just argued that for Free Software, we fare _far_ better even /without/ a standardized target, due to the grooming distributions do of upstream software. We are able to present a fully consistent work with that distribution's world view and I'm sure Microsoft and Apple are jealous of that ability, as it's simply not possible for them to do so as they lack the necessary source access. Free Software obviously has little to directly gain from the LSB, yet supporting it will take a lot of effort (e.g., how the LSB often includes versions of software that are too buggy to work on all platforms, which is a major issue for Debian). It's primarily of concern to proprietary companies that want to target Linux-based systems. This is also why the LSB is controversial.
This is where you don't understand. the LSB is to provide /a subset/ of the /existing/ level of platform standardization you find on Windows, in order to make it easier for proprietary third-party companies to target Linux-based platforms. Maybe you're interpreting 'platform standardization' wrong - it's not standard as in a registered standard, it's a measure of the platform's diversity.
Think of it this way - if you only targeted Debian Sarge, that would be like targeting only Windows XP, although XP will remain a stable, supported target for many years longer. However, the GNU/Linux space is diverse, so those proprietary software companies want to target as many platforms as possible with just one build, seeing as they can't rely on the distributors to groom their software to perfectly fit like what happens with Free Software, as they won't have access to the source. As such, they want at least some subset of the various distributions to be a known target they can code for, and they can attempt to pick up the remaining slack themselves. Through certification, customers know which distributions will be able to run the software. That's the role of the LSB.
However, I just argued that for Free Software, we fare _far_ better even /without/ a standardized target, due to the grooming distributions do of upstream software. We are able to present a fully consistent work with that distribution's world view and I'm sure Microsoft and Apple are jealous of that ability, as it's simply not possible for them to do so as they lack the necessary source access. Free Software obviously has little to directly gain from the LSB, yet supporting it will take a lot of effort (e.g., how the LSB often includes versions of software that are too buggy to work on all platforms, which is a major issue for Debian). It's primarily of concern to proprietary companies that want to target Linux-based systems. This is also why the LSB is controversial.
I think we're talking about totally disparate parts of the LSB. You're focussing on APIs/ABIs while I'm focussing on thinks like FSH and the .desktop standard.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
Then the author goes on to say "Until we can come together on a packaging scheme that meets with everyone's needs, let's consider offering rpm and deb packages." Um. We have those already.
Is consistency really such a great thing to strive for? Why not just standardize on a single distribution, then you don't have to worry about distribution differences. Instead of wanting the whole world to be the same. Distribution differences are vexing at times, I've cussed plenty my own self. But all that rampant creativity is the strength of FOSS. The good stuff survives and the crud dies.