Xavier wrote: > Hi list > > Jakob and I have been going back and forth about where groups handlings should > be, in backend or frontend, and how alpm interface should look like. > > It turns out Jakob has several arguments for the group backend solution, and > he > spent quite some time working on it, improving and fixing things. > This solution fixes several flaws that pacman currently has without > drastically > changing the code. > > There are just two disappointing aspects that Jakob covered below in bad news. > > Also there are still some points I would like to see improved, but more > aesthetic than real issues, so low priority. I was going to cover them here, > but > this will just confuse things and would deserve its own topic/discussion.
I'm re-proposing that we scrap groups entirely in favor of metapackages. (I think I send a message to this list about this over a year ago.) A metapackage would consist of an empty package (i.e. no installable files other than pacman metadata). The package would list the members of the metapackage as optdepends. For this to be useful, the following would be needed: * optdepends dialogue: this would be (almost?) identical to the current group dialogue... the user could then either select all members of the metapackage or just the ones he wants, exactly as groups currently work * user-selected optdepends would need to be handled by pacman: an easy way to do this is to add an extra directory to the database alongside "local" and "sync" to store data about user-selected optdepends ("soft deps", as opposed to "hard deps" specified by "depends"). For the sake of example, let's call this directory "custom". When a user installs an optdepend specifically for package "foo" (i.e. makes it a "soft dep" of "foo"), the directory "custom/foo" would be created in the database. Inside that directory, a file named "depends" would be created. This file would be analogous to the "depends" file in the "local" and "sync" directories. "custom/foo/depends" would contain a section named "%DEPENDS%" and in that section it would list all "soft deps" installed by the user for "foo". When pacman needs to check the dependencies of any package, it loads the "depends" file in "sync" or "local", depending on the operation. At this point, pacman has an internal list of the package's dependencies. It should then check for the existence of "custom/$pkgname/depends". If that file exists, it should be loaded and all packages listed in that file's %DEPENDS% section (the optdepends specified by the user) should be added to the aforementioned internal list of dependencies. At that point, all optdeps specified by the user will be treated as though there were deps of the package and pacman can manage them without any further changes. The overhead of testing for the existence of a file should be negligible. By keeping this in a separate directory in the database ("custom" in this example), the "local" and "sync" databases are unaffected, i.e. no files in either of the existing databases would need to be changed, plus "custom" could be extended later if necessary (e.g. to allow users to associate files with packages, e.g. config files). Other benefits would be automatic upgrades... currently a user has to manually check if a new package is added to a group and anyone can place their own packages in any group. With metapackages as specified above, only the maintainer of the metapackage can control which packages are "included" in it, and when the maintainer adds a new package to the group, the "new optdep" hook would inform the user (and maybe even trigger the selection dialog). * The optdep dialogue should be accessible for managing optdeps locally, i.e. when not installing, e.g. "pacman -Q --optdeps foo". This should also let the user. * An "--asoptdepsfor" (or "--assoftdepsfor") option should be added to make packages "soft deps" of another package, e.g. "pacman --assoftdepsfor foo bar baz" would make "bar" and "baz" "soft deps" of foo. * An "old optdep" hook could inform the user when an optdep installed as a "soft dep" has been removed from a package, e.g. "foo" used to list "bar" as an optdep so the user installed "bar" as a "soft dep", but now "foo" has dropped "bar" as an optdep, so a message is display upon upgrade. * Files and dirs in "custom" should be removed when they are empty. Advantages: * "groups" can be completely replaced with something that follows as a natural consequence of pacman's standard behavior with all benefits that it brings * "soft deps" would not need to be limited to optdepends, thus users could easily manage their own custom dependencies I would really like to hear some thoughts about this approach from the devs. Regards, Xyne