2009/11/28 <madd...@madduck.net>: > also sprach Eugene Gorodinsky <e.gorodin...@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. _______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions
