Universal package specification

[Eugene Gorodinsky]

Sorry, accidentally pressed send...

2009/11/29  <madduck at madduck.net>:

> Yes, in some ways that would be nice, but there'd be disadvantages.
> First of all, as I just wrote, dependence on commercial players
> would shrink, so don't expect much support from them. Second, the
> one-size-fits-all distro just doesn't exist. Debian calls itself
> "universal", and it probably gets closest to being a distro that can
> be used on the desktop as well as a high-security server, but the
> split is already pretty big.
>
That is why I'm saying the package format and libraries should be
standardised and everything else should be left alone. I do not
believe in one-size-fits all.

> However, Fedora and Debian could collaborate and use the same DVCS
> repository for any given package. This is what we are trying to
> achieve over at vcs-pkg.org: there's a set of common branches, a set
> of feature branches which I can cherry-pick if I want a given
> feature for my distro, and a set of distro-specific branches. Then
> we all build our binaries out of the same repository, binaries
> specifically assembled for the distro's use-case, at the same
> time as redundancy is minimised because all binaries stem from more
> or less the same source.
>
> Software product lines across distributions. How awesome.
>
Sounds interesting. I'll have to look into it closer. Actually it
almost sounds like the holy grail of package management...

> You might want to read up on the discussion around binary
> compatibility between Debian and Ubuntu to get a feeling of the
> level of collaboration/standardisation/synchronicity required for
> what you are trying to achieve. Synchronicity is what caused Debian
> and Ubuntu, two very close relatives, to be binary *in*compatible:
> Debian moved too slow for Ubuntu, and Ubuntu moved too fast for
> Debian. You could call us lazy and them innovative, you could say
> we're volunteers and they are paid workers, or — and this is the
> only real reason I think — you could acknowledge that Debian focuses
> a lot more on stability and Ubuntu on the cutting edge, and you
> cannot bridge that gap indefinitely and universally.
>
The focus on stability is a good idea, I think. However, sometimes you
want a stable base along with certain cutting edge applications.
Thanks for pointing me to the discussion on binary incompatibility.

>> I'm not touting this as an advantage, it simply seems logical to
>> do this if you want to conserve space/bandwidth.
>
> Debian Packages files are indices, and they contain all the
> information because only then are you able to search the indices.
> Therefore, if you want to avoid having to download all packages to
> be able to search across them, you need this index.
>
> Also, APT needs the meta data to resolve dependencies.
>
> To remove redundancy, you'd have to remove the metadata from the
> binary packages. That's surely doable, but would also mean that
> a single .deb file would become useless: you could not obtain meta
> data from it, and in particular, dpkg could not enforce policy and
> prevent installation of packages with unresolved dependencies.
>
Yes, a single deb file would indeed become useless, but if the package
has non-executable files it's usually split into two packages so it's
kind of useless to have just one anyway. This is why I don't think the
approach of having metainformation stored per-package is any good.
Plus, if you want to let users be able to simply download using a
browser and double-click a package to install it, you can create an
"additional" format which would basically be a .tar that contains all
the needed packages. Installing it would be the same as extracting all
files into a temporary directory and then feeding the manifest to the
package manager. It's also not cpu-intensive to create these tar
archives on the fly, which would save storage space on the
server-side.


> I am sorry if I sound discouraging. I may well be wrong and you
> should not use my thoughts over yours. I do think there are better
> uses of time and energy, and some are even on the way to the
> universal package, e.g. the LSB and vcs-pkg.org. Maybe it would pay
> off to have a look there to see if you can find a way to approach
> your ideas in a more bottom-up fashion?
>
On the contrary: I've posted my idea here because I want to know what
the problems are in package management. And thanks, I definitely will
have a look at vcs-pkg.org