Allow version "revert" of packages

[kallisti5]

We're seeing a missing make package in Haikuports. The cause is haikuporter buildmaster doesn't "revert to obsolete packages" when the newer version is removed.

Example:

1. We're using make 4.1 for 3 years
2. 4.2.1 is disabled as untested
3. a 4.3 version gets added
4. the 4.3 version gets disabled due to bugs.
   haikuports/haikuports@a82ebc2

In the situation above, make 4.1 was dropped from haikuports due to step 3.

When step 4 occurred. make-4.3 was removed from the repos, but 4.1 (the last building version) was silently never put back in place.

Workaround:

• manually bump the revision of 4.1 forcing it to rebuild (inefficient, hack, prevents tracking these issues)
• force master-4.1 out of obsoletes somehow in repo

[kallisti5]

fyi @korli @mmlr This one is pretty serious since "packages quietly disappear from our repos"

[kallisti5]

looks like the older version of make is completely gone from the repo:

[root@limerick ci-packages]# find . -name "make-*"
./data/instances/master/x86_64/.obsolete/make-4.1-3-x86_64.hpkg
./data/instances/master/x86_64/.obsolete/make-4.3-1-x86_64.hpkg
./data/instances/master/x86_gcc2/.obsolete/make-4.1-3-x86_gcc2.hpkg
./data/instances/master/x86_gcc2/.obsolete/make-4.3-1-x86_gcc2.hpkg
./data/build-packages/master/packages/make-4.1-2-m68k.hpkg
./data/build-packages/master/packages/make-4.1-3-x86_64.hpkg
./data/build-packages/master/packages/make-4.1-2-sparc.hpkg
./data/build-packages/master/packages/make-4.1-2-arm.hpkg
./data/build-packages/master/packages/make-4.1-2-ppc.hpkg
./data/build-packages/master/packages/make-4.1-2-riscv64.hpkg
./data/build-packages/master/packages/make-4.1-3-x86_gcc2.hpkg

(notice the absence of ./data/repository/master/x86_64...)

[kallisti5]

See haiku/infrastructure@461403d for my temporary workaround

[mmlr]

This seems somewhat arbitrary to me.

The packages don't just vanish silently, they are obsoleted because a new package is made available with an explicit action. So getting back another version of a package should be done with a deliberate action as well.

That the packages remain in .obsolete is a safety mechanism that remained from the early days, to be able to restore in case something would go wrong with dependency resolution and clear packages erroneously. It should not be relied on to restore packages and manage repo state IMO. I've previously removed obsolete packages to make space, as we cannot keep everything indefinitely. So such a mechanism would depend on the timespan between the obsoletion and the "unobsoletion", which seems undesirable.

Instead, rebuilding the desired old package is the right thing to do. Since there is no guarantee that the rebuilt package is exactly the same as the one previously available (build tools and dependencies may have changed to produce slightly different versions), changing the revision is also the right thing to do. Otherwise you end up with possibly slightly different released packages where that difference isn't obvious from the package name, which is a nightmare to figure out later on if there turn out to be problems with those packages.