[pacman-dev] some limitations of the current front-end, new -D option
Hi! We discussed here that an option to change the install-reason of an installed package would be nice: http://www.archlinux.org/pipermail/pacman-dev/2007-September/009271.html So what about a new -D (like database) operation: set of commands to modify localdb (for experts only;-)? We could add a --reason (or --explicit and --dependency) option to this operation. For example: pacman -De xorg. (-D can be combined with Xavier's testdb to rebuild requiredby field etc. etc.) Here we can see some limitation of the current ("getopt") front-end (user should have to do -Qi, -D..., -Qi here): it's powerful for simple -A, -U, -S, -R commands, but an interactive (not necessarily graphical) front-end would be more comfortable for group operations, universal transactions (define operations per package), -D ... Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Tue, Sep 11, 2007 at 04:44:16PM +0200, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
So what about a new -D (like database) operation: set of commands to modify localdb (for experts only;-)?
-D is already used by makepkg. though a relevant patch is here: http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-g2.git;a=commit;h=09414... so that if foo requires libfoo and libfoo is marked as DEPEND, and later a use does a -S libfoo its reason will be changed to EXPLICIT. relevant test: relevant tests: http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-g2.git;a=commit;h=4c7e0... - VMiklos
On Wed, Sep 12, 2007 at 07:15:45PM +0200, Miklos Vajna wrote:
There are some particular cases where the previous behavior was better imo. Mostly when you reinstall a package for testing/debugging purpose, because you have some problems with it. Some users even try to reinstall all installed packages sometimes. This would lose all REASON information. The better thing to do is probably have it fully configurable. Being able to set the reason to explicit, to deps (--asdeps) or to keep it (current default behavior).
On 9/12/07, Xavier <shiningxc@gmail.com> wrote:
That was my first reaction too. I'd argue that it is, in fact, MOST cases where the previous behavior was better. I'm having trouble coming up with a use case where you'd ever prefer to have a package's reason set to explicit if it doesn't absolutely have to be. Can someone point one out? Scott
On Wed, Sep 12, 2007 at 11:56:51AM -0600, Scott Horowitz wrote:
Well, there is the xorg situation which I mentioned earlier : http://www.archlinux.org/pipermail/pacman-dev/2007-September/009272.html After the removal of the xorg package, all its deps become orphan, but you might dislike that.
On Wed, Sep 12, 2007 at 07:26:52PM +0200, Xavier <shiningxc@gmail.com> wrote:
sure, it's a matter of taste. to me, the reason EXPLICIT means i installed the package explicitly at least once, so i know that package. maybe it means something else for others (like some users always do a -Sd instead of -S..)
Some users even try to reinstall all installed packages sometimes. This would lose all REASON information.
is this a hobby? :)
yes, probably extra switches to kill automatism could not hurt - VMiklos
On Wed, Sep 12, 2007 at 07:57:17PM +0200, Miklos Vajna wrote:
I don't know, ask them. Here is the last situation I saw where it happened : http://bbs.archlinux.org/viewtopic.php?id=37182 But I already saw it several times in the past as well.
On 9/12/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
I had to do it in a couple of cases. For example, one year ago I was getting a lot of crashes almost everywhere. Reinstalling everything helped a lot. Or I had to reformat. A pacman -Q to a file and then a reinstall of everything on the new system. Corrado
Both solutions can be acceptable for me, but the implemented one should be consistent (but the current one is not: http://www.archlinux.org/pipermail/pacman-dev/2007-September/009271.html) Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Thu, Sep 13, 2007 at 04:57:50PM +0200, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
rewriting makepkg in C is not a good idea imho - VMiklos
On 9/14/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
I would agree. I'm sure we might be able to refactor a few small parts out, but in general, using bash is intentional, as PKGBUILDs are already in bash syntax. Basically we're getting the whole complex lexer/parser for free just by using bash.
rewriting makepkg in C is not a good idea imho
Well, I don't want to rewrite it (I'm not interested in makepkg), but I don't like "hidden" features of pacman. If you prefer a shell-script makepkg, I'd prefer small makepkg-helper tool(s) written in c (which would use libalpm). To tell the truth I'm not too familiar in makepkg, and if so much parts needed from pacman (config-file parsing(?), etc.), I can accept the current method. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Sat, Sep 15, 2007 at 04:50:40PM +0200, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
such hidden features could be solved by a /usr/libexec/makepkg-helper or so, and then features which are in pacman just for makepkg could be moved to that binary. in case it annoys you at a level that you would want to work on it ;) at least this is how hal, gpg and several gnome tools work - VMiklos
participants (6)
-
Aaron Griffin
-
bardo
-
Miklos Vajna
-
Nagy Gabor
-
Scott Horowitz
-
Xavier