2007/4/20, Mateusz Jędrasik :

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.

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

2007/4/20, VMiklos :

--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..

2007/4/20, VMiklos :

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.

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 wrote:

Friday 20 of April 2007 02:55:50 Xavier napisał(a):

...

2007/4/20, Mateusz Jędrasik :

...

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 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