[pacman-dev] pacman, be quiet !
$sudo pacman -Syu ... :: lomoco: local (1.0-5) appears to be newer than repo (community/1.0-3) ... I know, I installed that! grrr... I know I'm annoying with debian (:D), but debian tools like apt-get or aptitude don't annoy me with these kind of messages at each upgrade. However, what I like in synaptic (gui frontend) is its ability to show these locally installed packages (I don't think apt-get can do it). So what would be great is to disable these messages by default, but being able to list them, with eg pacman -Q --local, or whatever. But that's too hard for me. Anyway, I was looking at pacman code in pacman.c , and saw this : 290 /* debug levels are made more 'human readable' than using a raw logmask 291 * here, we will ALWAYS set error and warning for now, though perhaps a 292 * --quiet option will remove these later */ So I went ahead and tried implementing this quiet flag. However, it's not very useful for me, because I'm too lazy to add an additional flag every time. At least now, I *can* disable these messages... but the behavior I described above would be much better.
Friday 20 of April 2007 00:10:27 Xavier napisał(a):
$sudo pacman -Syu ...
:: lomoco: local (1.0-5) appears to be newer than repo (community/1.0-3)
...
I know, I installed that! grrr... I know I'm annoying with debian (:D), but debian tools like apt-get or aptitude don't annoy me with these kind of messages at each upgrade. However, what I like in synaptic (gui frontend) is its ability to show these locally installed packages (I don't think apt-get can do it). So what would be great is to disable these messages by default, but being able to list them, with eg pacman -Q --local, or whatever. But that's too hard for me. Anyway, I was looking at pacman code in pacman.c , and saw this : 290 /* debug levels are made more 'human readable' than using a raw logmask 291 * here, we will ALWAYS set error and warning for now, though perhaps a 292 * --quiet option will remove these later */
So I went ahead and tried implementing this quiet flag. However, it's not very useful for me, because I'm too lazy to add an additional flag every time. At least now, I *can* disable these messages... but the behavior I described above would be much better.
Hi, I, personally, like this behaviour of pacman. I can right away see if my current mirror is out of date, and such messages are merely informational - however what I'd rather suggest is bump version/inform the person who is responsible for the PKGBUILD/ package in the official repos - getting it to the higher version for everyone who wishes to install it (if it indeed incorporates some news, i.e. if it's not a major version bump for example - there should be a separate pkg for those sometimes since not everyone plans on running the latest, as that doesn't always mean necesarily the greatest). Cheers, //m. -- Mateusz Jędrasik <m.jedrasik@gmail.com> tel. +48(51)69-xxx-xx, +44(772)664-2342 http://imachine.szklo.eu.org
2007/4/20, Mateusz Jędrasik <m.jedrasik@gmail.com>:
I, personally, like this behaviour of pacman. I can right away see if my current mirror is out of date, and such messages are merely informational -
hmm, that only happens when you're switching mirrors, right? I personally always use the same one :) But I get your point.
however what I'd rather suggest is bump version/inform the person who is responsible for the PKGBUILD/ package in the official repos - getting it to the higher version for everyone who wishes to install it (if it indeed incorporates some news, i.e. if it's not a major version bump for example - there should be a separate pkg for those sometimes since not everyone plans on running the latest, as that doesn't always mean necessarily the greatest).
Right, maybe in most cases, if the packages you're using is newer than the one in the mirrors, then the one in the mirrors should be upgraded. But that's not always the case. For example, you might be running an experimental version that shouldn't be in any mirrors, or you applied some custom patches for testing, or you enabled/disabled some configure options that will not make everyone happy. I believe you can have valid reasons for building several custom packages different from the ones in the repos, and you know they are only local because you build them, and you don't want to have pacman output spammed at every upgrade :) Obviously, if this information is very useful for several people, and don't store anyone but me, it should just stay this way.
Friday 20 of April 2007 02:55:50 Xavier napisał(a):
2007/4/20, Mateusz Jędrasik <m.jedrasik@gmail.com>:
I, personally, like this behaviour of pacman. I can right away see if my current mirror is out of date, and such messages are merely informational -
hmm, that only happens when you're switching mirrors, right? I personally always use the same one :) But I get your point.
however what I'd rather suggest is bump version/inform the person who is responsible for the PKGBUILD/ package in the official repos - getting it to the higher version for everyone who wishes to install it (if it indeed incorporates some news, i.e. if it's not a major version bump for example - there should be a separate pkg for those sometimes since not everyone plans on running the latest, as that doesn't always mean necessarily the greatest).
Right, maybe in most cases, if the packages you're using is newer than the one in the mirrors, then the one in the mirrors should be upgraded. But that's not always the case. For example, you might be running an experimental version that shouldn't be in any mirrors, or you applied some custom patches for testing, or you enabled/disabled some configure options that will not make everyone happy. I believe you can have valid reasons for building several custom packages different from the ones in the repos, and you know they are only local because you build them, and you don't want to have pacman output spammed at every upgrade :)
Obviously, if this information is very useful for several people, and don't store anyone but me, it should just stay this way. _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
I guess you could rename the package somehow then, as long as it's providing the proper dependencies... Dunno if there are switches in PKGBUILD like provides='blah' to make that happen without extra magic, I'm not too familiar with it yet. On the other hand there is always aur as well, which probably could sort things out. Anyway - it's just a small message - I don't see a reason onto adding functionality to pacman that is only usable to very few people, not only adding it, but making it the default - that is even less desired in my opinion. Regards, //m. -- Mateusz Jędrasik <m.jedrasik@gmail.com> tel. +48(51)69-xxx-xx, +44(772)664-xxxx http://imachine.szklo.eu.org
I guess you could rename the package somehow then, as long as it's providing the proper dependencies... Dunno if there are switches in PKGBUILD like provides='blah' to make that happen without extra magic, I'm not too familiar with it yet.
Unfortunately provide cannot have a version number now, however depends may need it. In my opinion we should implement it. (We talked about this earlier here.) "Emulate packages" is another reason for doing that. And frugalware guys already did this, so we just ~apply their patch(es). Anyway, there is nothing wrong with --quiet option if there would be any way to add options to pacman.conf. In general, IMHO that would be useful if we could set default switches in pacman.conf or in "PACFLAGS". (Another examples where this would be useful: --verbose, --debug, --noconfirm). What's more, I think we should unify the command line parameters and pacman.conf: I think they should be identical (of course command line should override pacman.conf). Bye, ngaba
Na Fri, Apr 20, 2007 at 12:36:22PM +0200, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> pisal(a):
"PACFLAGS". (Another examples where this would be useful: --verbose, --debug, --noconfirm).
--verbose controls the frontend while --debug controls the library. the only problem is that the logmask is always or'ed with PM_LOG_WARNING which means you can't disable warnings. Xavier, what about disabling that or'ing when --debug is used? then using --debug 0, you could avoid those messages thanks, VMiklos -- developer of Frugalware Linux - http://frugalware.org
2007/4/20, VMiklos <vmiklos@frugalware.org>:
--verbose controls the frontend while --debug controls the library. the only problem is that the logmask is always or'ed with PM_LOG_WARNING which means you can't disable warnings.
Xavier, what about disabling that or'ing when --debug is used? then using --debug 0, you could avoid those messages
Hmm, I don't know, I think that ideally, all logs could be enabled or disabled at running time. There are 5 kind of logs, so that would make 6 level : 0 : nothing, 1 : +error, 2 : +warning, 3 : +debug, 4 : +download, 5 : +function And the default level would be either 1 or 2. While I think errors, which really indicate something went wrong, should be displayed by default, I'm not sure about warnings, which are generally harmless. Is it possible to handle this only with this --debug option, by keeping it clear and easy to use? Using --debug 2 for getting warnings and --debug 3 for debug level is maybe not very clear, but well, I'm not sure..
Na Fri, Apr 20, 2007 at 06:38:59PM +0200, Xavier <shiningxc@gmail.com> pisal(a):
Hmm, I don't know, I think that ideally, all logs could be enabled or disabled at running time.
i was wrong, you can already disable warnings using --debug 0 ;)
There are 5 kind of logs, so that would make 6 level : 0 : nothing, 1 : +error, 2 : +warning, 3 : +debug, 4 : +download, 5 : +function And the default level would be either 1 or 2. While I think errors, which really indicate something went wrong, should be displayed by default, I'm not sure about warnings, which are generally harmless.
Is it possible to handle this only with this --debug option, by keeping it clear
it's clear already, just have a look at the library header (--debug -1 will enable all logs, --debug 0 will disable all of them, 4 will display errors only and so on)
and easy to use?
i have no idea how could this be easier to use, though for sure it may be hard for someone who is not familiar with the hexadecimal numbers maybe something like chmod's +r w x a etc?
Using --debug 2 for getting warnings and --debug 3 for debug level is maybe not very clear, but well, I'm not sure..
debug is 1, warnigns is 4, i don't think we would like to change these causing an api change VMiklos -- developer of Frugalware Linux - http://frugalware.org
2007/4/20, VMiklos <vmiklos@frugalware.org>:
i was wrong, you can already disable warnings using --debug 0 ;)
hmm, I don't understand, looking at your code there : http://darcs.frugalware.org/repos/pacman-g2/src/pacman-g2/pacman-g2.c I see : config->debug |= PM_LOG_WARNING; which seems to always happen.
it's clear already, just have a look at the library header (--debug -1 will enable all logs, --debug 0 will disable all of them, 4 will display errors only and so on)
and easy to use?
i have no idea how could this be easier to use, though for sure it may be hard for someone who is not familiar with the hexadecimal numbers
maybe something like chmod's +r w x a etc?
Oh I see, you directly set the log level using the representation in hex in the code. I didn't know your code was that different, sorry. Hmm, in this case, it indeed gives total configuration of the log level. And yes, having a letter for each kind of log would probably makes it easier.
Na Fri, Apr 20, 2007 at 09:55:33PM +0200, Xavier <shiningxc@gmail.com> pisal(a):
I see : config->debug |= PM_LOG_WARNING; which seems to always happen.
yes, but then parseargs() it will be overwritten by the given value
Hmm, in this case, it indeed gives total configuration of the log level. And yes, having a letter for each kind of log would probably makes it easier.
PM_LOG_DEBUG -> d PM_LOG_ERROR -> e PM_LOG_WARNING -> w PM_LOG_FLOW1 -> ? PM_LOG_FLOW2 -> ? PM_LOG_FUNCTION -> maybe f i'm not sure about the question marks thanks, VMiklos -- developer of Frugalware Linux - http://frugalware.org
There is a provides array... for you to be sure. As well - i also like this kind of behaviour. I once had problems with my system, and was able to completely downgrade my system since i did know all packages which came from testing... On 4/20/07, Mateusz Jędrasik <m.jedrasik@gmail.com> wrote:
Friday 20 of April 2007 02:55:50 Xavier napisał(a):
2007/4/20, Mateusz Jędrasik <m.jedrasik@gmail.com>:
I, personally, like this behaviour of pacman. I can right away see if my current mirror is out of date, and such messages are merely informational -
hmm, that only happens when you're switching mirrors, right? I personally always use the same one :) But I get your point.
however what I'd rather suggest is bump version/inform the person who is responsible for the PKGBUILD/ package in the official repos - getting it to the higher version for everyone who wishes to install it (if it indeed incorporates some news, i.e. if it's not a major version bump for example - there should be a separate pkg for those sometimes since not everyone plans on running the latest, as that doesn't always mean necessarily the greatest).
Right, maybe in most cases, if the packages you're using is newer than the one in the mirrors, then the one in the mirrors should be upgraded. But that's not always the case. For example, you might be running an experimental version that shouldn't be in any mirrors, or you applied some custom patches for testing, or you enabled/disabled some configure options that will not make everyone happy. I believe you can have valid reasons for building several custom packages different from the ones in the repos, and you know they are only local because you build them, and you don't want to have pacman output spammed at every upgrade :)
Obviously, if this information is very useful for several people, and don't store anyone but me, it should just stay this way. _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
I guess you could rename the package somehow then, as long as it's providing the proper dependencies... Dunno if there are switches in PKGBUILD like provides='blah' to make that happen without extra magic, I'm not too familiar with it yet.
On the other hand there is always aur as well, which probably could sort things out. Anyway - it's just a small message - I don't see a reason onto adding functionality to pacman that is only usable to very few people, not only adding it, but making it the default - that is even less desired in my opinion.
Regards,
//m.
-- Mateusz Jędrasik <m.jedrasik@gmail.com> tel. +48(51)69-xxx-xx, +44(772)664-xxxx http://imachine.szklo.eu.org
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
participants (5)
-
Georg Grabler
-
Mateusz Jędrasik
-
Nagy Gabor
-
VMiklos
-
Xavier