| |||||||||||||
Packaging summitPackaging summitPosted Oct 8, 2009 17:45 UTC (Thu) by rgc (subscriber, #36411)In reply to: Packaging summit by DOT Parent article: A report from the RPM summit
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.
(Log in to post comments)
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.
|
|||||||||||||