Re: new package format
2009/8/1 Tollef Fog Heen <firstname.lastname@example.org>:
> ]] Eugene Gorodinsky
> | 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.
> Except that this doesn't work particularly well. Libraries embed
> paths, and detecting when they do is painful.
Haven't thought of that, thanks for the input.
> | 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.
> like, the path, the description, translated into multiple languages and
> so on? This is just .desktop files reinvented.
Not quite. This separates the actual files the program uses and needs
from the files that are needed by the user. It's up to the package
manager to decide what to do with the information provided to it (e.g.
it could create a desktop icon, a menu icon, add an icon to a dockbar
or run the program once it is installed etc.). Granted, you can scan
the package and check if it has a .desktop file and read it if the
file exists, however this is a bit hackish.
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com