[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:
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...
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:
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.
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:
On 9/12/07, Xavier <shiningxc@gmail.com> 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.
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?
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:
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.
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? :)
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).
yes, probably extra switches to kill automatism could not hurt - VMiklos
On Wed, Sep 12, 2007 at 07:57:17PM +0200, Miklos Vajna wrote:
On Wed, Sep 12, 2007 at 07:26:52PM +0200, Xavier <shiningxc@gmail.com> 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.
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? :)
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:
Some users even try to reinstall all installed packages sometimes. This would lose all REASON information.
is this a hobby? :)
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
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..) Your version is also reasonable (this is the "importance viewpoint", I discussed about something similar here: http://www.archlinux.org/pipermail/pacman-dev/2007-September/009274.html). Then did you also change the behaviour of -U?
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/
-D is already used by makepkg. though a relevant patch is here: IIRC there are no hidden args in our pacman now. Bye, ngaba
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
-D is already used by makepkg. though a relevant patch is here: IIRC there are no hidden args in our pacman now. Well, I was wrong. -D is not used anymore, however -T is still hidden. And there must be hidden args, since makepkg is a srcipt (I recognized this after my mail, since I've never read its "source"; then why do we work on alpm library, if only pacman uses it ?:-). Bye, ngaba
---------------------------------------------------- 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:
Well, I was wrong. -D is not used anymore, however -T is still hidden. And there must be hidden args, since makepkg is a srcipt (I recognized this after my mail, since I've never read its "source"; then why do we work on alpm library, if only pacman uses it ?:-).
rewriting makepkg in C is not a good idea imho - VMiklos
On 9/14/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
On Thu, Sep 13, 2007 at 04:57:50PM +0200, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Well, I was wrong. -D is not used anymore, however -T is still hidden. And there must be hidden args, since makepkg is a srcipt (I recognized this after my mail, since I've never read its "source"; then why do we work on alpm library, if only pacman uses it ?:-).
rewriting makepkg in C is not a good idea imho
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:
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.
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