Re: new package format
2009/7/31 Giacomo A. Catenazzi <cate@debian.org>:
> Eugene Gorodinsky wrote:
>>
>> Hi all
>> I've read the debian news announcement today
>> (http://www.debian.org/News/2009/20090730). What got me very
>> interested was the part about a new package format
>
> There are two changes: one about the source package format
> (a true format change) and about binary package format
> (this is only a "formal" change about supported compressions
> algorithms, not real changes on functionality).
>
> Anyway these two format are already defined by long time
> (we need to have support of new format some releases
> before actual use, in order to provide smooth upgrades)
>
> So IMHO this is not the right period to discuss about a
> new format: we still have to use a "old new format".
>
>
>> (in my oppinion
>> this area can be vastly improved, and I'm interested in contributing).
>
> What are the problems of actual format?
>
For one the dependencies are specified as actual packages, rather than
the actual files themselves. Thus, if a user has installed some
library by `make install`, s/he cannot install a program packaged as a
deb, that relies on the library without some pain.
On windows a program may contain some optional components, which you
can choose at install time. This approach (I mean having some main
package and some required and some optional subpackages inside it) is
quite user-friendly. Neither dpkg nor apt have this functionality in
them, and I do not think it's possible to implement it without
changing the package format.
I also think some abstraction from the actual filesystem is a good
idea. For example currently the only way to install a lib in a
directory other than the one it was intended for is by using a hack
that would look at the directory of a file and move it somewhere. It
seems that with the current situation where you want to use
/lib/i386-linux-gnu tuples instead of the approach used before, would
be less painful if the current package format had some abstraction
from the filesystem. Since the programs don't usually care where the
library is, as long as it is in the LDD_LIBRARY_PATH.
The translations packages could be specifically marked as such, so
that a user could easily check if her package has translations for her
native language. The same applies for documentation, probably, which
could be made into an optional subpackage.
Currently debian policy is to have a .desktop file for each GUI
program. What would be better, IMHO, is having some sort of
abstraction, so that the package manager itself would create a
.desktop file entry, given an icon and some information about the
package.
Since programs usually store their settings in the user's home
directory, that aren't deleted when the program is uninstalled the
user's home directory becomes a mess. I'm not sure if it's possible to
change some functionality within dpkg without changing the format
itself.
>> Searching the list archives I was unable to find any discussion
>> relating to that, except for the multi-arch spec and a discussion that
>> took place way back in 1999. Is there anything I might have missed?
>
> Check the changelogs of dpkg to find when people discussed it.
>
> Anyway there were not real change since a lot of time. In last
> 10 years IIRC there was some support to "tar" extensions and
> compressing algorithm.
>
> ciao
> cate
>
Reply to: