* On 2023-09-23 at 11:47 BST, Thomas Klausner wrote:
On Fri, Sep 22, 2023 at 07:50:26PM -0400, Greg Troxel wrote:Thomas Klausner <wiz%NetBSD.org@localhost> writes: > How about: > > UPGRADE_NOTICE+= "<=4.5 Please foobar the nozzle before upgrading." > UPGRADE_NOTICE+= "<=5 Please remove the baz before upgrading." > > so that when you upgrade from a version before 4.5, both messages are > displayed and if you upgrade from a version before 5, the second is > displayed? That seems ok. I wonder if this should be more structured than split by first space, but that seems ok. I'd expect most conditions to be <, as in <X when the change happens in X.0, but as long as < and <= both work, people can write the conditions they think they need and we'll see how it goes.Yeah, the space is not optimal, other suggestions are welcome, and perhaps we can get rid of the '<' too and just use a version number.
It needs to be a full pmatch. In many cases PKGBASE is going to be different, you can't just match on version.
> At least by pkgin. Not sure if we want to teach pkg_add about this
This won't be a pkgin thing, it'll be a pkg_summary thing, and then it's up to consumers of that file format, including pkgin, to do something about it.
Currently there are no fields in pkg_summary that contain multiple parts that need parsing in either key or value, and I'm not particularly keen on changing that. I don't know that I'm hugely sold on this whole idea yet, but I think that if you're going to add it then I'd rather do it in the key rather than the value, e.g. something like:
NOTICES=pgsql NOTICE_MATCH.pgsql=postgresql1[0-4]-[0-9]* NOTICE_MSG.pgsql=You need to dump and restore blahThis is quite a large change to what has so far been a very stable key=value file format though, so I'd like this to be well considered, along with perhaps discussing if we should instead start developing a new format that allows us to be more flexible if we're likely to want additional features in the future.
For example one thing I've had a number of users ask over the years is the ability to ask what package provides a particular file. It's a reasonable thing we should provide, but it currently would bloat pkg_summary considerably. An option if we did decide to change formats would be to have separate files with some of them being optional for users who want to opt-in to extra features.
-- Jonathan Perkin - mnx.io - pkgsrc.smartos.org Open Source Complete Cloud www.tritondatacenter.com