2009/11/28 Ben Finney <ben+freedesk...@benfinney.id.au>: > Eugene Gorodinsky <e.gorodin...@gmail.com> writes: > >> I believe one of the main problems on Linux is the lack of a universal >> package format that works on all major distributions. > > Could you clarify why this is a problem, and for whom? I'm sure we could > all imagine reasons, but it would be good to be explicit about what > problem is being solved here. > Some packages are available in rpm only, others are available in dpkg only. Some packages are available in rpm and in dpkg, but not in the formats for other distributions. If those distributions start supporting either rpm or dpkg they will need to make sure they are fully compatible with debian or redhat, because you don't really know what it is that a package depends on: is it some particular files (e.g. config files) or is it the shared libraries provided or maybe it needs a certain dbus interface etc. Two packages depending on a third package may depend on different interfaces, thus it's not possible to replace this third package with a compatible one without closely studying what it is that all of the packages that have it in their dependencies really depend on. A more fine grained dependency mechanism would allow that.
>> Existing package formats were developed for specific distributions and >> don't offer the features required by software that is not >> distribution-specific. However most software isn't really distribution >> specific. > > Perhaps not, but the requirements for getting that software installed > and working on a particular distribution *is* specific to the packaging > system used on that distribution. > My experience is limited, but usually having specific libraries on the system is enough to get software to work. This could partially be because of the FHS conforming filesystems and other plumbing parts being similar. The software that depends on the filesystem in such a way should probably be rewritten to use a shared library of some sort - tying software to parts of the filesystem is really a bad idea (e.g. if it weren't for the software that was written to use open sound system directly, OSS would have probably been dropped a long time ago). Could you give an example to illustrate the problem? >That's a big part of the problem > addressed by a packaging system (note: the whole system, not just the > format of package data). 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. >> A lot of times the only difference between software packaged for one >> distribution and the same software packaged for another distribution >> is the directories this software is installed into. > > I don't find this to be a fair representation. Rather, software packaged > for different packaging systems contains very different *instructions* > to the packaging systems, even if the software work ends up in similar > filesystem locations. The filesystem locations are one — important but > not dominant — aspect of the information in a package. > By instructions, do you mean scripting, or something else? If it is scripting, then yes, I agree. My opinion on this right now is that the package system should provide some limited scripting capabilities, although I must confess, I haven't researched this thoroughly. >> Also since packages are not only distributed by themselves, but (and >> this happens more and more often) through repositories, some of the >> header data in packages such as rpm or dpkg packages is duplicated. > > 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. _______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions
