Universal package specification

[madduck at madduck.net]

also sprach Eugene Gorodinsky <e.gorodinsky at gmail.com> [2009.11.28.1600 +0100]:
> > Don't get me wrong, you have a noble goal, but if my experience
> > with vcs-pkg.org is any indication, then the aforementioned
> > large distros don't care.
> >
> > Why should Debian, RedHat/Fedora, and probably Novell/OpenSuse
> > abandon their package formats and converge on a universal one?
> >
> In the long run less resources will need to be wasted on package
> maintenance and more can be directed at other things.

Do you have any estimation how long it would take for the time
invested into development, deployment, and bug fixing to be
amortised?

> > We would have to standardise names and version schematar— how?
> >
> Only for shared libraries and dbus interfaces. And I believe those
> are already the same at least in debian and redhat systems.

What if a package depends on vim, or apache, or rsync?

> > This is where you'll need proper symbol versioning done right.
> > How do you want to get all the required knowledge for that out
> > to the people?
> >
> By proper symbol versioning do you mean shared libraries (and
> their versions) or something else?

Libraries and SONAMEs is the traditional way of doing it, but
I don't know many distros that rigorously paid attention to that.

Symbol versioning means that each symbol has a version and your
application may well work with older versions of a library if the
symbols it uses have not been changed (and ABI changes only
involved e.g. new symbols).

http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps

> >> The format by itself is useless without the package system
> >> supporting the features it provides, obviously. But the package
> >> system is powerless if the package format does not provide some
> >> necessary information to it. So the package format shouldn't be
> >> considered separately, but rather as part of the package
> >> management solution.
> >
> > I would be surprised if Debian were to embrace file
> > dependencies.
> >
> Why is that surprising?

Because it's been discussed numerous times as a possible extension
to dpkg and always found to be a feature that is not really
necessary when you have as tight control over the archive as Debian,
but instead facilitate hacks. RPM-based distros need file
dependencies because .rpm packages traditionally come from
everywhere, not a central, QA-controlled repository like Debian.

> > Ben Finney said, and you replied:
> >> > What does this mean? Can you give an example of “header data”
> >> > that is duplicated, and where this duplication occurs?
> >> >
> >> The control file in dpkg and apt Packages file for example.
> >
> > All the data are maintained in a single location. They are then
> > cached in multiple locations. That's not duplication, IMHO.
> >
> Maintained - yes. But I meant the actual distribution

Who cares about cached data in the "actual distribution"?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
fitter, healthier, more productive
like a pig, in a cage, on antibiotics
                                                          -- radiohead
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.freedesktop.org/archives/distributions/attachments/20091128/aad4b3d7/attachment.pgp