Universal package specification

[Eugene Gorodinsky]

2009/11/28  <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?
>
No, I don't unfortunately. That would require at least calculating the
time invested by maintainers now, and estimation of that time doesn't
seem feasible.

>> > 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?
>
For third-party plugins and for packages that allow for third-party
plugins there is a "base" field and a "plugins" field in the
specification. If that is not sufficient, the package can be provided
in a distribution-specific format as it probably is provided now. If
that does not work we can still use tgz + instructions how to install.
It's also possible to let package vendors define their own interfaces,
although I'm not sure if it's a good idea.

>> > 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.
>
If there is a universal format, then the less popular a distro is
(provided it's not a derivative of a more popular distribution) the
more reasons it has to standardize its shared libraries.

> 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
>
I'm only aware of one such library - glibc. I don't know why this is
done though. Which other libraries do this?

>> > 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"?
>
Sorry, I meant the process of distributing files. Bandwidth is still
an issue, and that way you can download less.