FS#4845 - New pacman.conf category: NoInstall

Attached to Project: Pacman
Opened by name withheld (Gullible Jones) - Wednesday, 21 June 2006, 18:49 GMT
Last edited by Roman Kyrylych (Romashka) - Saturday, 09 February 2008, 11:40 GMT
Task Type Feature Request
Category
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I think it would be nice to have a "NoInstall" category for pacman.conf... Like IgnorePkg, but instead of preventing an upgrade, it would do exactly what it said - prevent a (not yet installed) package from being installed, even if another package depended on it. This could be useful if, say, someone didn't want to install archlinux-menus, or wanted to use the Testing kernel but didn't feel like bothering with mkinitcpio.

(Actually, come to think of it, it might make more sense to modify IgnorePkg so that it also blocks the installation of listed packages that aren't already installed, on top of what it does now.)
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Saturday, 09 February 2008, 11:40 GMT
Reason for closing:  Implemented
Additional comments about closing:  Partially implemented as optdepends already, and anyone is welcome to step forward and improve that framework.
See also  FS#6430 
Comment by Ashok (ScriptDevil) - Thursday, 22 June 2006, 05:18 GMT
Yes! it would be really nice, because it would be similar o the USE( -kde ) for a package for which we dont need the whole of kde integration! One step closer to a perfect package manager
Comment by Ashok (ScriptDevil) - Thursday, 22 June 2006, 05:20 GMT
i think this can be changed by adding a new variable like USE in Arch too
Comment by name withheld (Gullible Jones) - Thursday, 22 June 2006, 13:46 GMT
It would not be like USE, it would just prevent the installation of the *specific* packages listed. I probably should have been more clear about that...

(Remember: Keep It Simple.)
Comment by Roman Kyrylych (Romashka) - Friday, 23 June 2006, 12:45 GMT
I fully agree with Gullible Jones.

As for USE variable: IMHO it would be better to add uses=() functionality to PKGBUILDs. For example:
depends=(glibc openssl pam)
uses=(openldap postgresql mysql)
Then pacman can (optionally) ask user if he/she wants to install those _optional_ dependencies, like this way:
pkgA can make use of the following packages: openldap postgresql mysql
Install openldap? [y/N]:
Install postgresql? [y/N]:
Install mysql? [y/N]:
These questions should be asked only when installing package, not when upgrading. (Of cource this behaviour could be extended to support more fine-grained control in future).

Right now some packages have dependencies in depends=() array that are, in fact, optional. Either such packages should be fixed, or proposed uses=() array functionality (or something similar) should be added.

Oh, I've got slightly offtopic here, sorry. :-)

Once again: NoInstall would be very useful option, at least for me. :-)
Comment by name withheld (Gullible Jones) - Friday, 23 June 2006, 23:25 GMT
I think adding USE functionality to PKGBUILDs doesn't really follow KISS, perhaps the Frugalware folks would do something like that but I don't think Arch would. But this is getting very OT.
Comment by Ashok (ScriptDevil) - Monday, 26 June 2006, 04:56 GMT
Cant we just edit /var/cache/pacman/pkg/<pkgname>-<pkgversion>/depends
and remove the unwanted deps by brute force. Probably the user should know the significance of what he is removing. But then that is ArchLinux for you - Experienced linux users, common sense and KISS policy!
Comment by name withheld (Gullible Jones) - Monday, 26 June 2006, 11:21 GMT
Then you'd have to force download only (downloading the deps anyway), edit the packages, install them... And do the same thing over again for every upgrade of said package. I hate to say it but that quite defeats the purpose of what I'm proposing: something that would allow users to block packages they didn't want with minimal fuss and PITA value.
Comment by Aaron Griffin (phrakture) - Wednesday, 24 January 2007, 18:02 GMT
I like the idea of stopping installation for packages marked as IgnorePkg.
This would, of course, spit off a warning about potential breakage... something like:

warning: package 'foo' is marked as ignored. This could cause applications to stop working.
It is recommended to install 'foo' unless you know what you're doing.
Comment by Roman Kyrylych (Romashka) - Wednesday, 24 January 2007, 19:44 GMT
Aaron. then I think this could be implemented with change in --ignorepkg & IgnorePkg behaviour as described in
http://bugs.archlinux.org/task/6094#comment13357
and comments below it. Then feel free to close #6094.

About warning message - I think when user uses IgnorePkg (I mean improved version that matches proposed NoInstall) - he/she already knows what he/she is doing (how is this different from -Rd, for example?), so warning messages will be annoying, IMO. :-/
Comment by Roman Kyrylych (Romashka) - Wednesday, 24 January 2007, 19:50 GMT
About breakage issues:
it would be nice to have something like -Sur to install all missed dependencies (those that was removed with -Rd or not installed/updated because of --ignorepkg).
This would be really good solution in cases of breakages due to dependency problems. What do you think about this?
Should I do separate feature request for this?
Comment by Roman Kyrylych (Romashka) - Wednesday, 07 March 2007, 19:39 GMT
See http://bugs.archlinux.org/task/6430 which requires implementing NoInstall functionality as part of IgnorePkg.
Comment by Xavier (shining) - Saturday, 09 February 2008, 11:37 GMT
I think that all these bugs (well it looks like there is only  FS#6430  left besides this one) should be closed now, for the same reason than  FS#6626  :
"Implemented as optdepends already, and anyone is welcome to step forward and improve that framework."

So it is also possible to post a new Feature Request for improving that framework.
But in my opinion, if something needs to be done, it should simply be about printing the optional dependencies during install.
That is, replacing the current way post_install is used by a cleaner, more consistent and controlled way using optdepends.

Loading...