Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[roarde]

The scenario:

• Upstream screws up royally on foo-2.0.5
• They produce a new release of the 1.x series, foo-1.4.87
• They change the API/ABI totally and produce foo2-2.1.0
• They announce that foo-2.0.x (not foo2-*) is dead and should be replaced with latest foo-1.x
• Without the new foo-1.x, users' systems are vulnerable. 1.x will deal with data written by foo-2.0.5, but foo2 won't

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?

[M0E-lnx]

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.

[roarde]

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.

• The packages repo is made up of only those packages which were included on the Standard release. It has no added priority, thus its priority is "normal", or "default".
• The extra repo contains packages that are not included with the ISO release, or that have been upgraded only because a newer version is available, and not because they're actually bugfixes or security patches. Extra's priority is the same as packages.
• The patches repo holds packages that were created to address specific problems like plain 'ol bugs or security fixes. The packages here almost always were present in other versions in packages or extra. In our default slapt-getrc, patches carries the OFFICIAL tag, which gives it a higher priority than the other two stable repos, or untested.
• The untested repo isn't active in the slapt-getrc as shipped with FINAL releases. It's the only repo available to releases still in development. That difference is where my confusion started, I think. Untested has normal priority like packages or extra but, again, it's off by default for stable releases.

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.

[M0E-lnx]

Wow.  That's a bit hard to grasp.  Even after reading it twice,  I still dont see how this solved the packages changing names.

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

[roarde]

I'll expand the time line a little bit.

• The original foo is produced and versions climb to foo-1.1
• It's a good time to implement new, incompatible features, and two file formats should be deprecated for security reasons. That branch gets a new major version number, which is the correct thing to do. That's foo-2.0.
• Maintenance of the foo-1.x series continues and versions increment normally there.
• We switch our foo package to the 2.0 series. Any of our users who use foo convert any incompatible data files they have to the foo-2.0 format. The foo-2.0 package becomes part of the release itself, shipping on our ISO.
• Upstream developers introduce both an API and an ABI break in the foo-2.0 series, and the protocol that foo implements has been changed by its standards body.

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.

Instead:

• The basename of the new series is changed from foo to foo2, and the new version is called foo2-2.1.
• Under the circumstances, full maintenance of foo-1.x continues.
• Full maintenance of foo-2.0 continues! It's now at foo-2.0.87 and that patchlevel will continue to climb.
• We package foo2-2.1.x and that is what's shipped on the following release ISO. The foo-2.0.x package is updated and retained for users who still have old data. That can be done because foo and foo2 have different executable, library, and symbol names. The packages don't conflict with each other, but just with user understanding and common sense.
• Both development and maintenance of foo2-2.1 continue.

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.

• At last, End-Of-Life is announced for the foo-2.0 series. Foo2-2.1 can't directly import all of foo-2.0's data directly yet; it has to be exported by foo-2.0 first.
• Foo-1.x is expanded to cover formats 2.0 has, but foo2-2.1 doesn't! Maintenance continues on this, now at foo-1.4.0.

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.