Re: CVS commit: pkgsrc/sysutils

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

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

> On Wed, Aug 23, 2023 at 08:22:46AM -0400, Greg Troxel wrote:
>> Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
>> 
>> 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).

jperkin has been working away making pkgin better.  Bug reports help, so
it would be good to try this out.

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

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
what I did when I had production machines.  Now I have a dom0 on an old
box in the basement to run package builders and if it doesn't work for a
week that's ok.

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.

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

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.