Interesting. At first glance, I'm not a huge fan of "legacy" packages, but it does make life a lot easier whenever a package changes its build system. @tgamblin @alalazo how do we feel about this being the official approach to handling a build system change?

Possible caveats:

• What happens when a package changes its build system twice? foo-legacy-legacy?
• There could be problems with dependency resolution. We could make both legacy/non-legacy versions virtual providers, but that seems complex.
• What do other package managers do?

What happens when a package changes its build system twice? foo-legacy-legacy?

I think at some point - maybe when the release process will be more stable / frequent? - we should start deprecating the oldest versions of packages (meaning removing the versions and cleaning recipes from anything that is specific to them).

There could be problems with dependency resolution. We could make both legacy/non-legacy versions virtual providers, but that seems complex.

There could be another approach based on repositories. If, instead of naming the old package mesa-legacy, we move it to a new repository builtin-legacy we avoid the issue with dependencies. Ideally builtin-legacy should have lower precedence than builtin so that if a user wants the old package he needs to specify e.g. foo ^builtin-legacy.mesa. What do you think?

What do other package managers do?

I'm not aware of other package managers doing that, but I can have a look around and report here what found 🙂

Rather than just resurrect the previous package, I think better would be to create a mesa18 package that uses the autotools build and only contains the last 18.x release before autotools was deprecated. The initial motivator for the mesa package rework was to address numerous problems with how variants, options, and virtual packages were handled and much of that has already been plummed through downstream dependents, thus the previous mesa package won't really suffice. Making a "legacy" package with the new variants will produce a more compatible result.

What do other package managers do?

This does happen often enough. Most package managers I've seen use an unversioned name for the current package and a versioned name for the previous version when the break occurred. For example, for package foo had a major break between v2 and v3 then you would have package foo2 for Foo v2.x and package foo for the current Foo v3.x A good example of this is how Qt is often handled. Many package managers will now have the packages qt3, qt4, and qt, for handling Qt versions 3, 4, and 5 (current) respectively. Hence my suggestion for creating a mesa18 package.

I can very quickly pull one together that builds the same as the new meson one with the same variants and options. I'll push it up shortly.

#11553, I believe is likely a better solution since it uses the same variants and configurations as the new meson build, just with the autools configuration.

I really like @alalazo's builtin-legacy suggestion!