Am Dienstag, den 15.09.2009, 15:09 +0200 schrieb Marc - A. Dahlhaus [ Administration | Westermann GmbH ]:
Am Dienstag, den 15.09.2009, 22:53 +1000 schrieb Allan McRae:
Nagy Gabor wrote:
2009. 09. 15, kedd keltezéssel 21.18-kor James Rayner ezt írta:
On Tue, Sep 15, 2009 at 9:14 PM, James Rayner <iphitus@iphitus.org> wrote:
On Tue, Sep 15, 2009 at 11:20 AM, Dan McGee <dpmcgee@gmail.com> wrote:
I don't really know what to think here. I had looked at that messages one for a long time and thought it was a decent idea, but never went far enough to take it and run with it.
@Loui- sure, but this is for extraordinary messages- a lot more exclusive than ChangeLog-worthy stuff, and you have to explicitly request to see that anyway.
@Jeff- it isn't exactly straightforward to view an install script beforehand, and the post_install business is a rather hacky reason for needing an install script.
-Dan
Dan's got the idea...
pacman should not break someone's system without at least telling them first. So yes - this is intended for more extraordinary messages.
The current ways of informing the user (homepage/forum news and post-install) are broken and non-simple: - both polling based
oh, and post-install is after the fact - when the system is broken, so it's not a very good way of informing the user that their system "will break" because it's already broken.
Anyway, I'm all for a more generalised/ideal setup, but that's been wanted for a while with no patches coming forward.
OK. Here is my staindpont (not closely related to iphitus's patch, but some thoughts about the "problem"):
1. echo lines in install scriplets are stupid. I bet that you also looked into install scriplets in /var/lib/pacman/... many times manually to read that information on an installed package (when something went wrong). I think this requires a new %INFO% field in (local) database, which could be accessed by -Q. Drawback: pre_install, post_install, pre_upgrade etc. is more sophisticated. (It is possible to only print info if we upgrade version older than...) 2. I am not sure about the pre-transaction messages. We ask for user confirmation before downloading packages, so in order to print info/alarm etc. messages then, we _must_ store this info in sync database, or interrupt the transaction once more before actual install. post-transaction messages are easier to implement, see 1. Iphitus chooses putting %ALERT% to syncdb.
Overall, I think iphitus's patch is a good compromise, if we want to distinguish important and non-important messages.
My problem is that I don't see when the packager should remove %ALERT% from package, in 1.0-2, 1.1-2, 2.0-1? When I've read (and understood) the alert message, printing it again is just a spam.
That point is what I have been thinking about all day but there is no easy solution there as far as I can tell. I have the same issue with deciding when to remove provides lines...
Allan
How about detaching the alerts from the actual package itself and add it only to the repo like we do for deltas? We then could add a logic to it to just print it for versions older than the flagged version by default...
This of course needs some new tools for the repo to add/modify/remove alerts.
I think this could be a way around this problem...
Marc
OT: is there a tool for removing deltas from repo archives?