Re: CVS commit: pkgsrc/sysutils

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Aug 23, 2023 at 08:22:46AM -0400, Greg Troxel wrote:
> 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.

It may be new behavior; in the past I did run into an installed package
that was not in the new repository (e.g. because it didn't build and
I didn't notice). In this case, pkgin would just ignore it and I ended
up with a non-working binarie (because shared libs of dependancies got bumped).

> 
> 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.

If you end up with a non-working emacs25 you can still edit files with
vi. If you end up with a non-working xentools413 you loose guests,
and the only alternative is to upgrade both xenkernel and xentools to 4.15
with potential fallouts (I always had to do minor adjustement to config files
on major Xen upgrades). It's not the same level of risk.
In the past I even ran into hardware not working with a newer Xen version,
so upgrading Xen did mean upgrading the hardware.

> 
> 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).

No idea. The less I deal with linux, the better

> 
> > 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.

No, it's not safe. This is why we need to have both 4.13 and 4.15
and warn that 4.13 will be removed (this is similar to what happens
with databases, for example).

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--