FS#10630 - Making optdepends more visible to the end-user
Attached to Project:
Pacman
Opened by Abhishek Dasgupta (abhidg) - Wednesday, 11 June 2008, 02:55 GMT
Last edited by Xavier (shining) - Sunday, 24 August 2008, 01:10 GMT
Opened by Abhishek Dasgupta (abhidg) - Wednesday, 11 June 2008, 02:55 GMT
Last edited by Xavier (shining) - Sunday, 24 August 2008, 01:10 GMT
|
Details
Summary and Info:
Currently, optdepends is an optional field in PKGBUILDs which lists optional dependencies for a particular package along with the use of that particular dependency. However optdepends is not exposed to the end-user during installation of packages. It is visible on doing a query , but ideally it should be printed on installation. Otherwise duplication of work occurs when a packager puts in optdepends and has to manually put in the deps in the .install file to be printed out. It would be nice if pacman printed out the optdepends for a package after installation prior to/after the .install file (if any) is executed. Also a switch to install optdepends would be handy. |
This task depends upon
Closed by Xavier (shining)
Sunday, 24 August 2008, 01:10 GMT
Reason for closing: Implemented
Additional comments about closing: implemented with commit 96e023c7bd0b1
Sunday, 24 August 2008, 01:10 GMT
Reason for closing: Implemented
Additional comments about closing: implemented with commit 96e023c7bd0b1
About a switch to install, I am not sure. It would be yet another switch (we have already many ;)) but also, what would it do, install all optdepends?
It seems like this feature might be more interesting to implement in a gui where the opt depends could be graphically selected or something.
happens when one tries to install a group:
# pacman -Sz blueman
Optional dependencies for blueman
gnome-bluetooth: Send files over bluetooth
gnome-vfs-obexftp: To view OBEX ftp shares
btsco: For bluetooth audio
Install all of them (y/n)?
Selecting y will install all, and n will allow one-by-one choices.
I agree this is not as important as printing out the optdepends.
Anyway, I actually run into several problems when trying to do just the printing part.
It is easy to access the optdepends after the installation of one package in libalpm (libalpm/add.c), but the printing should be done from the frontend.
This could be done by some sort of callbacks, maybe another EVENT ? That looks very ugly though...
If the printing is done from the frontend, it can only be done after the transaction ends, that is, after every package is installed.
From the frontend, we can get a list of the packages with alpm_trans_get_pkg but this returns a list of pmsyncpkg.
And this pmsyncpkg contains a pmpkg which comes from the sync database!
And guess what, the sync databases don't have this OPTDEPENDS information, it only appears in the local database.
So currently, I am stuck.
But maybe they should.
http://www.archlinux.org/pipermail/arch-dev-public/2008-July/007136.html
Do we need to delay it to a later 3.2.x release or even 3.3?
This is not true:
EVENT(trans, PM_TRANS_EVT_UPGRADE_DONE, newpkg, oldpkg);
So the front-end can do anything after each package upgrade.
So that's the way we need to go?
IMHO yes.
If we want to do some hacks in order to automatically install optdepends we must hack this to back-end, because in this case the optdepends part should be handled in sync_trans_prepare part (where we have syncdb info only, so %OPTDEPENDS% db-record is needed!). Here the front-end cannot add any new targets to the transaction, only the back-end. (Creating transaction from front-end is very ugly, this process can be "recursive".)
So imho the first thing we should decide, whether alpm should deal with optdepends at all. If not, imho it shouldn't send any optdepend specific event, and front-end should do its task via UPGRADE_DONE callback. If yes, imho we _must_ put %OPTDEPENDS% to db; in this case back-end should ask optdepend specific question, so that solution is optimal.
Yeah, that seems nice indeed, I did not think about that.
"So imho the first thing we should decide, whether alpm should deal with optdepends at all. If not, imho it shouldn't send any optdepend specific event, and front-end should do its task via UPGRADE_DONE callback. If yes, imho we _must_ put %OPTDEPENDS% to db; in this case back-end should ask optdepend specific question, so that solution is optimal."
Why not first doing it in the frontend, but also put %OPTDEPENDS% to the db, so that we can later decide to handle it in the backend. It would also allows us to see optdepends on -Si operation.
Patch attached, and a sample output :
checking package integrity...
(2/2) checking for file conflicts [#####################] 100%
(1/2) upgrading audacious-plugins [#####################] 100%
Optional dependencies for audacious-plugins
jack-audio-connection-kit: Jack output
curl>=7.16.2: Audioscrobbler plugin
musicbrainz: Audioscrobbler plugin
lirc-utils: Infra-red support
libmodplug: Modplug plugin
projectm: Projectm visualization plugin
sdl: Paranormal visualization plugin
neon: HTTP and Web-stream playback
wavpack: Wavpack input
fluidsynth: Fluidsynth amidi-plug backend
(2/2) upgrading alsa-lib [#####################] 100%
Optional dependencies for alsa-lib
python
Your patch is ~identical to mine, except that I used list_display(" ", optdepends, 1) instead of printf. (See ML for list_display patch. This is a bit ugly, because I used " " for displaying 4 spaces...)
I was looking at the repo-add part too, but I am not doing much except copying depends/conflicts/provides part.
I am not really satisfied with my indent neither (the same for -Qi Optdepends):
Original (no) indent:
foo: install foo to enab
le bar
New indent:
foo: install foo to
enable bar
Clearly, indent to : looks be the best, but I am lazy for doing that (and we have no clear definition to OptDepend format)
We then changed it to "provision=version" to avoid this problem, but the same problem still hurts us for the optdepends. And we can't really work around it here.
I went back to this old provision version bug report, and saw you proposed a fix to repo-add :
http://bugs.archlinux.org/task/9171?getfile=1756
I guess I did not pay much attention to it back then, because looking at it again now, it looks fine, and this code definitely needed to be fixed.
So after getting that fix, the repo-add part for optdepends should then be straightforward.
Because in my test, your new indent looked ok to me, when I tested with pacman -Qi audacious-plugins in a small terminal.
About echo -e, I can't think about any cases where it could cause problem. We should not have escape characters anywhere.
Btw, I am satisfied with both your and my patch atm.
Ok, I agree that the output with your patch is not the ideal one, but it is still very decent, and I find it much better than no indent at all.
And btw, I thought the same, having two list_display functions instead of a linebreak param.
But this situation is very similar to the yesno extra param I added. Maybe it would also be better here to provide two functions, like yesno and noyes.
In both cases, the two functions could be basic wrapper to the generic function with an extra parameter.
Is it implemented?
The progress happened too late, right around the 3.2.0 release.
Then I hoped it could make it in 3.2.1, but I doubt Dan wants new features in minor release, so I will put this for 3.3 (even if it is a minor patch).