tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgin package repository message (Was: 9.0 is getting old...)



> On Jun 8, 2024, at 1:17 PM, Jonathan Perkin <jperkin%mnx.io@localhost> wrote:
> 
> * On 2024-06-08 at 16:26 BST, David Brownlee wrote:
> 
>> It occurs to me that it would be helpful to provide a way for a binary
>> package repository to inject some form of message into pkgin users.
>> 
>> This could be used to tell 9.0 and 9.1 users that they need to upgrade
>> to >= 9.2, or that a repository has stopped being updated and they
>> need to switch somewhere else, or some critical issue in pkgin
> 
> Yeah I like this.
> 
>> It could be as simple as a text file in the package dir, automatically
>> checked and downloaded by pkgin, combined with logic to display it
>> always (bonus points for having pkgin commane line option to stop
>> showing the message until it changes)

Having the message disappear after the first time I think would make messages get lost after they were not noticed the first time.

> I think what I'd do is have it have similar logic to pkg_summary, so that it is only fetched if the mtime is different to what's in pkgin.db.
> 
> Then have it displayed if running on a tty, with a requirement that the user press a key to continue.  It is then no longer shown unless it is updated again.  That way users are required to interact with it to confirm it has been read, while not breaking automated updates.

I'd like to note that sometimes, for various reasons, including getting a program to behave in a particular way, it's necessary to script programs while they run under a pty, perhaps using a tool like lang/tcl-expect. Therefore blocking when on a tty would effectively hang these scripts. Having this interactive behavior is in general okay when the program invoker knows that he is running an interactive program and knows what to expect, but when you take a normally non-interactive program and make it interactive in certain rare corner cases and error conditions, well that's just asking for trouble.

I don't see why you can't just print an error message to stderr and return a nonzero failure code, just like any other error condition.

> I'll take a swing at it next week.
> 
> -- 
> Jonathan Perkin   -   mnx.io   -   pkgsrc.smartos.org
> Open Source Complete Cloud   www.tritondatacenter.com



Home | Main Index | Thread Index | Old Index