Re: Regarding MESSAGEs during pkg_add installation of meta packages

[Greg Troxel <gdt%lexort.com@localhost>]

David Holland <dholland-pkgtech%netbsd.org@localhost> writes:

>  > I'd be happy with just deciding that MESSAGE (now) is something thath
>  > should not exist, and then entirely removing support for it, and
>  > bulk-rming all MESSAGE files, after giving people who think they might
>  > have README.pkgsrc content a chance to move to that.
>
> I have one reservation about that. Well, two.
>
> 1. Sometimes there are cases where it's fairly important to include a
> message of the form "When updating from 2.x to 3.x you need to
> re-reticulate all the splines or thingy-gui won't start". The current
> MESSAGE infrastructure is a poor way to handle this. However, I don't
> think we want to replace it with _no_ way to handle this. Ideally
> these would be indexed by version number so they only get displayed
> when applicable.

The previous documentation was that MESSAGE should be used only for
lasting negative consequences.  So far we do not have an example where
that is applicable.

A package where you need to do such manual things on upgrade to get it
to work has an upstream bug, and of course many packages do.  We ask
that NEWS be in commit messages - but people often commit without
adequate NEWS.  There is of course pgsql and mongo (and I think mysql*)
where you have to dump/restore across major versions.  There is
nextcloud where you have to manually initiate upgrade migrations.  I
hypothesize that these sorts of migration pain points are in large
packages where those using them need to read the upstream documentation
anyway.

I'd like to talk about actual cases, thinking that there are few to
none.

> 2. Moving the assorted glop that exists in most MESSAGEs to a
> README.pkgsrc is fine, but when that stuff matters it's probably a
> good idea to specifically point users at it. This applies, for
> example, when you need to install other things to get a properly
> functional package. (Whether such cases should exist is another
> debate; for the time being they do.) The same alternative notice
> system as (1) should serve. Ideally these notices would also be
> indexed such that they only appear when installing for the first time.

That is what DESCR is for: to describe what is in the package.  And,
therefore what is not in the package but might be expected.  The case
you describe is a package that is sort of split into base and plugins
(often sound), but we have chosen not to have any dependencies.

There are a lot of DESCR that have upstream marketing text and don't
explain what is in the package.  This has been often a problem when we
have multiple versions.  I have fixed many of these over the years.

> Also, there are some things where the default config you need has to
> go in $HOME, so dealing with that problem isn't quite as simple as
> just using CONF_FILES.

I think the expectation is that upstream should document how to use the
program, that the docs are in the distfile, that pkgsrc installs the
docs, and that users read the docs before using the program.  I do not
think it is wise or reasonable to go off plan from that.



I've drafted a deprecation plan, to follow shortly, which should allow
us to remove the vast majority of MESSAGE files (which we have agreement
on) and we can see what's left.