VL Solutions => Packager training and help => Topic started by: roarde on October 12, 2017, 05:49:11 am

Title: [SOLVED]Install a lower-numbered version with --upgrade as a bugfix
Post by: roarde on October 12, 2017, 05:49:11 am
The scenario:

How is foo-1.4.87 packaged so that users who've installed foo-2.x pick it up automagically when they do slapt-get --upgrade?
Title: Re: Install a lower-numbered version with --upgrade as a bugfix
Post by: M0E-lnx on October 12, 2017, 10:51:54 am
I dont think VL ( or slack, for that matter) have a way to handle this internally for the end user.  The closest thing to a sane approach is probably to list the packages known to be broken/dead/vulnerable in slack-conflicts.  This will result in the package manager uninstalling the listed packages if the user chooses to install the new package.

This approach, however does nothing to 'automatically' make this change happen on an --upgrade via the package manager.
Title: Re: Install a lower-numbered version with --upgrade as a bugfix
Post by: roarde on October 13, 2017, 09:54:53 pm
After mulling this over a bit longer, I recalled that the answer is in our default slapt-getrc, as shipped with final releases. I seem to recall my complaining somewhere about the effect when that answer is used by something different -- I don't remember what. But the method as-is does work. Here's how it goes. If I get something wrong, let me know; I'll edit this post.

There's an implicit rule to be remembered here. The list of packages already installed on the system is treated as if it were a repo with normal priority. That is to say that the highest-numbered version present in a higher-priority repo, patches in our case, is what is chosen as what should be on the system. Between packages, extra, and the target system, highest-numbered version is what ends up as installed, period. For the higher-priority patches repo, you're going to end up having whatever its highest-numbered version is, regardless of the version already installed on the system. That's something to keep in mind when upgrading software locally. While this seems like a mistake, it does give us the option of using a lower-versioned software as a patch. With the development practices of projects degrading generally, this is happening more and more now.

The answer to my initial question, then, is this:
A packager should base a bugfixing package on whichever version of the software is proper, regardless of the version number already in use. For any package, mention in the commiit message whether this is a package that's new to us, a feature/version upgrade, or a bugfix or patch. Include that same info when it's time to request the package be moved from untested to stable repos. New packages or feature upgrades will be placed in extra (packages is fixed at release time), and fixes will go in patches. If a higher-versioned package is already in patches, the repo maintainer will remove that manually so that your patch will take effect.

It took some unthinking to sort this out, and I had to resort to a live test. Easy when you know it, not so easy if you're me and you don't.
Title: Re: [SOLVED]Install a lower-numbered version with --upgrade as a bugfix
Post by: M0E-lnx on October 16, 2017, 08:37:33 am
Wow.  That's a bit hard to grasp.  Even after reading it twice,  I still dont see how this solved the packages changing names.

Upstreams screws up on foo-2.0
They decide to go back and fix their mistakes on foo-1.9.99, and now decide to produce foo2-2.0

In slapt-get, this creates a problem, because while you *can* upgrade from foo-2.0 to foo-1.9.99 given the procedure you explained above, you cannot *cannot* upgrade from foo2-2.0 back to foo-1.9.99

As far as slapt-get is concernted those are 2 completely different packages and as such, one will not replace (upgrade) the other.
Title: Re: [SOLVED]Install a lower-numbered version with --upgrade as a bugfix
Post by: roarde on October 16, 2017, 12:59:51 pm
I'll expand the time line a little bit.
Bad situation. Some of it could have been prevented by a bit of foresight, but not all of it. There's still a right thing to do from where things are: Announce a faster-than-normal deprecation of the foo-2 series immediately, and roll out the new code as foo-3.0. Maintain 2.0 for a minimal amount of time and have it print loud warnings about the deprecation and the risks.

This is based on a true story, btw. As convoluted as it looks here, the actual details are far worse, especially after this point. I leave those details out because they don't apply as directly to the question here.

And that was the status when the question was asked. So people having foo-2.0.87 need foo-1.14.87 as a bugfix and carryover. The method above would accomplish that. To this point, foo2 isn't involved in the fix, except that poor decisions about it led to us being here.

Of course you're right that you can't exchange one package for a differently named package this way, M0E-lnx. And yes, stuff that happened or was learned after this thread started have us dealing with just that, and more.

This is not the first package this has happened with, which is why I wanted to get myself clear on how to "upgrade" to a lower-numbered version, and leave a bit of a trail for whoever encounters it later. This kind of thing has been happening more often, and the frequency of that will continue to climb.