Re: new package format
Eugene Gorodinsky wrote:
2009/7/31 Giacomo A. Catenazzi <cate@debian.org>:
Eugene Gorodinsky wrote:
(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.
It is difficult to track the version of a file, and it is very difficult to
know if a version is compatible with our packages. There are a lot of
other important things to check (ABI), not only the version.
In general it is impossible to do right dependencies to external/local
installed packages.
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.
In debian is done by different packages (within the same source).
Usually these related packages are listed in "Suggests" or/and
have a common prefix in package name.
User interface problems are outside 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.
Not sure I understand, and security implication should be handled
with care.
Anyway RH has support to install packages in own homes. This kind of
abstraction could be nice to have.
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.
I think this is not a problem of package format, but of user
interface.
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.
This is outside package format. Anyway it is being standardized.
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.
This was already discussed, and it is impossible to solve.
Package managers must not touch homes. Check archives about
a lot discussions about this.
IMHO you are trying to solve problems on the wrong level.
Package format is a low level format. A lot of stuff can
be done with actual package format, but with improvement
of user interface or/and with triggers and postinst
stuffs.
Actual system is not perfect. You can help, but it is not
so easy to improve such things in a sane way without
causing troubles with existing users.
ciao
cate
Reply to: