| |||||||||||||
Packaging summitPackaging summitPosted Oct 8, 2009 15:25 UTC (Thu) by kragil (subscriber, #34373)Parent article: A report from the RPM summit
Why not get all major distros (deb and rpm based) together and define what packages should provide and discuss a long term roadmap so that one LSB-package (maybe just meta-package at first) format will eventually exist.
Packaging and distributed bug tracking are still points where major synergies are lost in the FOSS world.
(Log in to post comments)
Packaging summit Posted Oct 8, 2009 16:01 UTC (Thu) by rgc (subscriber, #36411) [Link]
The major reason packages for one distro are not usable in another is not the packaging format, but the diverging policies. If policies matched, the currently existing format converters would render the issue moot. Without matching policies, converging on a single format is probably just bikeshed painting. And, since having diferent policies is pretty much the reason for having diferent distros, I mostly fail to see how this can be a worthwhile effort.
Packaging summit Posted Oct 8, 2009 16:41 UTC (Thu) by DOT (subscriber, #58786) [Link]
What kind of policies are you talking about? Can't a powerfully expressive system deal with varying policies?
Packaging summit Posted Oct 8, 2009 17:45 UTC (Thu) by rgc (subscriber, #36411) [Link]
Some scenarios that come readily to mind:
If you have a distro that wants to enable selinux (or any other cross-app functionality) and another one that wants nothing to do with it, that gives you incompatible library dependencies from the start.
Some distros insist in modifying upstreams to comply with file location policies (think plugin paths) while other distros insist on unmodified upstreams.
Distros migrating now to upstart may want to change the location (maybe even syntax!) of their init scripts, while conservative distros want to keep the current ones.
Several distros are trying approaches to multiarch, with differing implementations regarding file locations. A cross-distro policy for that will necessarily have to wait until a winner is selected, if one ever is, since they might be serving different trade offs.
There's probably a couple other dozen of examples, I'm just trying to give a feel of what I mean.
Packaging summit Posted Oct 8, 2009 17:55 UTC (Thu) by khc (subscriber, #45209) [Link]
package naming policy matters too. If package A depends on libB-4, another package that provides the same thing but calls itself B-4 wouldn't satisfy that.
You can solve that specific problem by using file based dependency, but then you have other problems too (where to put the files, what files to package).
Packaging summit Posted Oct 9, 2009 16:11 UTC (Fri) by sorpigal (subscriber, #36106) [Link]
Where to put the files isn't all of it. You can have the same version of a lib compiled with different compile-time options which could affect compatibility.
There isn't even any consensus on representing version information. Debian's notion of what kind of version string is "higher" is different from Fedora's, even if the package format were the same.
Packaging summit Posted Oct 8, 2009 18:23 UTC (Thu) by nevyn (subscriber, #33129) [Link] To see what was meant let's take a look at say, openssl, in both Fedora and OpenSuSE. They both use rpm, and are even moving towards having the same version of rpm, so the difference is mainly "policy".
This is a huge difference already, and will propagate throughout the entire distro.
Again, a major difference. Yum certainly doesn't understand what the -32bit suffixes mean (so multilib_policy won't work).
Again, this is a policy which is going to propgate thought the distro. There is no solution to this apart from "merge policy" or "have two separate packages".
The contents of those directories is also very different. Again, this is a "merge or rebuild" type problem.
Again, even if everything else matched installing the OpenSuSE packages on Fedora could blow everything up due to this difference.
Opps, any binaries linking to ssl can't move between distros. now because they have different .so numbers.
Again, major change. And that's the obvious policy differences seen in a few minutes on one package (due to the different split of packages and files, I didn't really try to see investigate file differences), where both distros. have the same upstream version: 0.9.8k. So you have to "fix" all of the above, and more, to have something you can realistically share between those two distros. (where fix means someone changing their policy, which isn't going to happen without a large fight) ... as the above poster said, the packaging format is the least of your problems.
Packaging summit Posted Oct 24, 2009 15:59 UTC (Sat) by jengelh (subscriber, #33263) [Link]
>OpenSuSE has .x86_64 only, with some "duplicates" which have a suffix of -32bit. Again, a major difference. Yum certainly doesn't understand what the -32bit suffixes mean (so multilib_policy won't work).
One reason is simple: because rpm -Uhv openssl-1.0 would eliminate all packages of the same name with a lower version number.
>Fedora names the libraries /usr/lib64/libcrypto.so.0.9.8k _and_ /usr/lib64/libcrypto.so.8. OpenSuSE names the libraries /usr/lib64/libcrypto.so.0.9.8. Opps, any binaries linking to ssl can't move between distros. now because they have different .so numbers.
You could blame openssl for that, because they are not using the library versioning scheme "correctly" (by the definition of the libtool manual). Either libcrypto.so.X with proper X, or libcrypto-0.9.8.so(.0).
Packaging summit Posted Oct 8, 2009 16:42 UTC (Thu) by skvidal (subscriber, #3094) [Link]
'Major Synergies' are not lost and since we had a cross-distro packaging summit a number of years ago at an Linux Foundation Face to Face I can relatively assure you that nothing will come out of another one.
the packaging structure is too fused to the distro process. Changing much of the packaging policies/structures is going to require moving the distros too.
The amount of force required to overcome the inertia there is MASSIVE.
I do not think that much force exists, honestly.
Packaging summit Posted Oct 8, 2009 20:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Won't happen, unless we all switch to something like Nix (package manager, not LWN subscriber :) ).
Packaging summit Posted Oct 8, 2009 22:26 UTC (Thu) by nevyn (subscriber, #33129) [Link]
I've yet to see someone developing a significantly used package management system (Eg. rpm/dpkg/yum/apt/zypp/smart/etc.) that thinks autopackage, Nix or zero-install is going to work.
Dito. for anyone in rel-eng at a large distribution (Eg. Debian, Fedora, OpenSuSE, Ubuntu, etc.)
I've yet to see autopackage, Nix or zero-install distribute a significant number of used packages ... and thus. show that they can work at anything above toy examples.
Feel free to get back to me when one of the above is true.
Packaging summit Posted Oct 9, 2009 9:17 UTC (Fri) by epa (subscriber, #39769) [Link]
Have you looked at Conary? It's by the original rpm developer, so it might have a better chance than most of dealing with the real-world problems that come up.
Packaging summit Posted Oct 9, 2009 11:21 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
Thanks for mentioning Conary. So the problem is not getting better: new package formats getting added :-)
Are all Conary-based distributions compatible with each other?
(Conary was invented to solve a different problem. It is well-suited for solving it. But Conary won't bring us world peace. Nor would it unify all distributions)
Packaging summit Posted Oct 9, 2009 15:41 UTC (Fri) by nevyn (subscriber, #33129) [Link]
Conary is/was interesting. I had high hopes for it when it was released, but that was years ago now. Whether it was the concept wasn't as great as I thought or just that rPath didn't have the resources to make it I don't know.
But I did not see Conary as the same as Nix/zero-install (and still don't) because to me the idea behind rPath was that you could manage a largish number of "small" changes well (ie. 1,000 customers with a small number of patches each[1]), that package creation might be easier than anything else, and of course the rollback/sub-set features (although years later others are getting there).
Nix/zero-install/etc. seem to me to be based on the idea that you can have large changes within a distro. and it still work. And I'll bet against that everyday, and twice on Sundays.
[1] http://illiterat.livejournal.com/3568.html
Packaging summit Posted Oct 9, 2009 9:11 UTC (Fri) by nix (subscriber, #2304) [Link]
Despite my name I don't see how Nix would help much with alien-package installation either. You would still have policy differences between installed packages, and while shared library naming might matter a bit less, dlopen()ed pathnames are still seriously important, unless you think KDE will like having several copies of its libraries and their state in a single process's address space at the same time (I tried it, and the best scenario is a coredump).
Packaging summit Posted Oct 9, 2009 9:15 UTC (Fri) by epa (subscriber, #39769) [Link]
One LSB package format does exist. It is RPM version 3 (which differs from the RPM version currently used in RPM-based distros). See http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-gene...
Perhaps it's due an upgrade, to define a new common package format which can take advantage of features in dpkg, newer rpm releases, or other package managers. But personally I think that we should try and get the existing standards to work before we go off and invent new ones. So far, I don't know of any ISV that manages to ship their application as a single LSB-compliant package to run on any LSB-compliant system (given a certain architecture, say x86). So what are the obstacles stopping them?
Packaging summit Posted Oct 17, 2009 20:23 UTC (Sat) by sfink (subscriber, #6405) [Link]
Maybe it's just me, but I'd much rather see a common source format for packaging. That way, I could create one description of the package and could be processed into packages of whatever formats I provided enough information to support. It could even have a lint mode that would tell me that my description is adequate to generate an RPM for just about any version of Fedora, but if I wanted it to work on Ubuntu, I needed to provide a startup script in X format.
A common specification format together with a rich policy database would make it much more likely that upstream maintainers could produce reasonable seeds that distributions could use, and might help unify tool development (ah, I see you're using git to hack on your local copy of this package, and version 2.13 is in your history. I'll generate a source bundle that includes the virgin 2.13 along with all of your patches automatically.)
I suppose this could be done with a meta-source bundle that generated sources for all the different package systems and distro flavors, but it seems an unnecessary layer. Probably the best way to get started, I suppose.
The reason why I haven't taken a stab at it is because I've gone through much pain to be semi-competent at building RPMs, and I'm not anxious to go through that much pain again for a different format. (I took a brief stab at learning dpkg because I keep hearing how incredibly awesome it is, and at least from the building side, it just seems to have a different set of miseries. I don't know whether it's nicer overall or not, and I don't especially care since I don't need to know it.) I'm guessing that's a common stumbling block -- the people who know this stuff deeply enough are wedded to a particular distro, since that's *why* they know it that deeply.
One last comment -- when talking about package management, the users people are normally thinking of are the recipients of the packages or the distribution maintainers. I'm in a 3rd category: I build lots of new or slightly customized RPMs all the time, but they are for my own use and that of a small network of other people (usually the other people at my company.) If package building wasn't such a pain in the rear, there would be a lot more people like me. Currently, most people seem to compile and make install on a dozen different machines rather than fight with building a package once.
|
|||||||||||||