If you can't build ardour2 anymore, use the old package and adapt ardour3 in order to avoid conflicts...

Hey Bernardo

As you can read from the ML, upstream does not want to be bothered about 2.x. We cannot continue to package it as it's a waste of resources. It is already in the AUR. [1] I did look for you (and speps) to get some real user feedback at that time but you weren't around.

The upgrade path is as usual -- you should opt to update to 3.x when pacman offers to do so. Then you are free to install ardour 2.x, however you see fit (they will co-exist just fine). This is the same upgrade scheme we have been using for major revisions, it is not new.

Otherwise, if you simply want to keep ardour 2.x (since the likelihood of a successful new rebuild is slim), then simply ignore the update in pacman. I'll wait before I close this in case you have an idea of a better way to handle this.

[1] https://aur.archlinux.org/packages/ardour2/

OK, I see the point. I can't build `ardour2` myself from aur. The old binary from ARM is in conflict with the current one, they share the same name.

BTW, I prefer to use ardour3, I like it. Although I have older projects I currently need to be able to open them...

Have you tried compiling https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/ardour&id=becec0c1bcb22b457f7bb74083bcf340cc78832e against an older version of lilv? I have no idea what modifications are needed for both versions to co-exits.

If you can get ardour2 to compile then no modification is needed to install it side-by-side; you only need to first "update" to 3.x and then pull in the 2.x package. However, the problem arises when you currently have 2.x, you want to keep it (since current code is broken), but at the same time you want 3.x.

This is an unfortunate by-product of the release model I chose (a convention we had adopted for most major things, like python). If I had pushed a new ardour3 package, you would not have faced this issue. However, the decision was upstream's, not ours. They chose to dump 2.x and move on.

As a distributor, I simply chose to comply with their intentions by upgrading 2.x to 3.x instead of providing a new 3.x. It might have been a better idea to declare 2.x as "dead" and keep the binary in the repos as the "last known working version", but I did not expect that upstream would abandon it like that.

Anyway, tl;dr: this was a lack of foresight on my part and lack of user feedback when I needed it most. The best suggestion I can give now is to ignore the update and keep an external untracked copy (or tracked with a different package name if you like) of ardour 3.x, since in your case 2.x is more important.