[pacman-dev] Groups. Again.

[Xyne]

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