2009/7/31 Giacomo A. Catenazzi <c...@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 > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org