[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Changing how you do things: Was Re: merged /usr



On Mon, 16 Aug 2021, David Kalnischkies wrote:

/usr/bin/apt exists for 8 years now and the release notes advice using
it in every section. So, how come people are still typing apt-get
interactively to upgrade?

Best regards

David Kalnischkies

P.S.: For the avoidance of doubt: apt-get is of course going nowhere,
but that cuts both ways: It isn't changing as your fingers hate change ?
so e.g. no new interactive questions fingers aren't trained to answer?


One of the problems is that the "upgrade" path is never easy for
experienced users. One thing that could help would be something like:

-o APT::NewCommand=yes option (or something like that) that to
apt-get/apt-cache which took the command line and told you exactly what
apt incantation you need to achieve exactly the same results.

I'm looking at a script of mine that can take around 20 minutes to
complete and has 9 apt-get incantations.

I have things like;
DEBIAN_FRONTEND=noninteractive apt-get -q -y install \
  -o APT::Architecture=${ARCH} -o APT::Install-Recommends=false \
  -o APT::Get::Simulate=true -o RootDir=image apt | tee apt-simulate.log

and then the rest of the script depends on the contents of
apt-simulate.log

I could update it to apt - but the script currently supports four
releases across four architectures. So even if the changes are all
"no-brainers" it's going to take an overnight run to confirm that
everything still works. And if, inevitably, there are tweaks required,
then it becomes a long drawn out red queen's race. This is a personal
project "for fun" and "because I can" and time taken updating this
script to apt "because the documentation says I should" is time I cannot
spend on more interesting stuff (from my PoV)

Even upgrading from buster to bullseye is potentially fraught - perhaps
apt-simulate.log will change. One of my projects over the last few years
has been to slowly change so that everything now runs in VMs and each VM
should only do one thing - that way upgrades can be managed and breaking
changes can be handled one by one. I think I'm finally in position to
consider adopting systemd. I had dozens of init scripts, udev rules etc,
some of which have barely been touched for a couple of decades that will
all need to be rewritten, some of which I need to "just work" (and some
of which possibly don't do anything any more but I've never noticed...)

The script I commented on above is part of my project to ensure that any
and all changes to the default debian install are done via packages. I'm
not there yet but, for example, I can now rebuild a VM from scratch and
then diff things like /etc to check that I've captured everything in a
package. I started this project two years ago today (coincidence!) and
last week I finally got into the state where I can do that for
everything I use at home. I still have changes I need to package, and I
still have VMs that are running too many unrelated services, but I'm
slowly getting there.

Ironically, the /usr-merge is almost a "no brainer" for me. It's only
after reading the comments here that I realize it's actually a difficult
problem to solve cleanly because it's so easy for me to deal with. I can
see why Guillem is frustrated.


Reply to: