2009/7/31 Giacomo A. Catenazzi <c...@debian.org>: > Eugene Gorodinsky wrote: >> >> 2009/7/31 Giacomo A. Catenazzi <c...@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. > That's sort of what I had in mind, except on a larger scale where a package is simply marked as being a shared library and perhaps given some tag, e.g. "base". The package manager would then install it into /lib or wherever it deems necessary.
> >> 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. > What I meant was to have some certain predefined types of packages, so that it was easy for the package manager to tell which packages are translations, which are libraries, which are documentation etc., and also easy to tell which translation/documentation packages belong to a particular piece of software. > >> 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. > Any pointers on what to search for? My search proved unsuccessful (again) Anyway, wouldn't specifying which files need to be deleted from the user's home directory solve the issue? > > 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. > I hope I am. Would make things much easier :) > 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. > I'll look into the current format more, since I guess I might have missed a few things. > ciao > cate > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
