Re: CVS commit: pkgsrc/sysutils

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

On Wed, Aug 23, 2023 at 08:53:06AM -0400, Greg Troxel wrote:
> >> 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.
> 
> Lots of things have lots of issues.  I am coming at this from the
> broader pkgsrc viewpoint.
> 
> It is certainly good to be loud about this on port-xen.  Given how
> complicated xen is, it does not seem prudent to run netbsd/xen without
> being on that list.
> 
> But my point is that this "upgrade and it doesn't work" does not just
> happen with pkgin.  When you try, you get an error, and you get to
> decide what to do.
> 
> If we have a hint that 4.15 is going to leave a certain class of CPUs
> behind that 4.13 supports, that should also be loud on port-xen.  I have
> not been aware of this.

It was more a bug than a CPU support issue (maybe a BIOS bug), and as it was
not a critical system so I didn't spend much time to get it working
again

> 
> I feel that you are simultaneously expecting admins to do
> professional-level sysadmin in terms for preparing to avoid downtime and
> also needing to be completely protected in ways I find strange.  If you
> are using xen in true production, you really need a staging server with
> the same hardware with staging domUs and to qualify updates.  That's

That would be an ideal world. Unfortunably I have to manage systems with
different CPUs generations, from different vendors and we don't have enough
money to have twice the hardware. Reproducing a complete domU setup
with the same workload on a test system is also not that easy.


> 
> Also, I view anybody on 4.13 as at least a year overdue for moving to
> 4.15.  However 4.13's DESCR says it is the recommended version in
> pkgsrc.  Surely that can't be if you are about to remove it.

thanks, I removed it.

> 
> >> 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
> 
> It's still an interesting source of potential info about dealing with
> hard issues.
> 
> >> 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).
> 
> So we have established that SUPERCEDES support is a red herring.

For some packages yes, that's not the correct way to deal with
upgrade. Again there are the same issues with databases, where major upgrades
sometime needs heavy manual intervention

> 
> Perhaps you could propose a deprecation warning mechanism (that doesn't
> abuse MESSAGE :-) where there are variables in packages that are
> machine-readable, and various operations in pkgsrc and pkgin would print
> warnings.

this is more time than I want to put on the issue

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