Re: CVS commit: pkgsrc/sysutils

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

Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:

>> The proper content of MESSAGE is documented in the pgksrc guide, and it
>> is basically things that are so important that persistent bad things
>> will happen if you don't notice.  In this case, it's just that somebody
>> not paying attention will when they try to upgrade to 2023Q4 notice that
>> 4.13 binary packages no longer exist, and then they need to switch to
>> 4.15 or something else.
>
> I consider it a bad thing to end up with a non-working system after an upgrade.
> Users needs to be warned in advance so they can have a proper migration plan

The real issue here is that "pkgin ug", if it cannot fully complete the
upgrade, needs to tell the user what cannot be done and stop.  I think
that it actually does this.    If you find that it doesn't,  a bug
report will be useful.

I build my own packages, so I sometimes run into a missing package on
upgrade (if it ended up on a package-using box but not on the
package-building box).  I have gotten these "foo is no in the
repository; proceed anyway" queries, said no, and gone back and built
it.  This to me seems entirely analogous.

I know you work on xen (which is really great, as not many do!), and
thus see it as critical, but this sort of deprecation is not really
unusual in pkgsrc which as 20k packages, many of which are super
important to various people.

For example, we are likely to remove emacs25 soon.  I don't think we
should add MESSAGE or put anything in DESCR.  someone with emacs25
installed, should they miss the thread on pkgsrc-users, will get a
"emacs25 is no longer in the repo" and then they can pick which of
26/27/28/29 they want to install instead.  Looking at pkgsrc as a whole,
this sort of thing is routine.

It would be interesting to know how Debian and Fedora deal with this
(and something else, if there is another root packaging system - suse?
- in the Linux world).

> And overall I think the deprecation mechanism in pkgsrc could be better
> (like: tag a package as deprecated so that pkgin/pkg_install could
> show installed deprecated packages and point to an upgrade path)

We have SUPERCEDES and pkgin is growing support for it.  But here, there
is probably no "just replace it with this other package", as the admin
needs to read the upgrade notes and perhaps edit config files.  If not,
removing 4.13 and installing 4.15 is easy.

If you think it is safe to silently install 4.15 instead of 4.13, you
could add supercedes tags, but that would really surprise me.

We are talking about people administering a dom0, which is a level of
admin competence much higher than expected for random users.