[pacman-dev] [PATCH] Allow package to display a brief message before sync install

Marc - A. Dahlhaus [ Administration | Westermann GmbH ] mad at wol.de
Tue Sep 15 09:10:41 EDT 2009


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 at iphitus.org> wrote:
> > >>     
> > >>> On Tue, Sep 15, 2009 at 11:20 AM, Dan McGee <dpmcgee at 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?



More information about the pacman-dev mailing list