Unable to install GrandOrgue on Ubuntu 23.04

[oleg68]

As discussed at #1478, an attempt to install GrandOrgue on Ubuntu 23.04 fails with error that libwxbase3.0-0v5 is not available.

Only libwxbase3.2 (libwxgtk3.2) is available there.

On Ubuntu 22.10 both libwxgtk3.0 and libwxgtk3.2 are available. Only On libwxgtk3.0 is available on Ubuntu 22.04 and before.

[oleg68]

In order to fix this issue I'm going to build two linux packages on github: grandorgue that would require wxWidgets 3.2 and grandorgue-wx30, that would require wxWidgets 3.0.

Users of most recent linux distributions should download install grandorgue, but users of older versions where 3.2 is not abvailable yet should download and install grandorgue-wx30 instead.

@larspalo @rousseldenis Do you agree with that approach?

[larspalo]

I absolutely agree with providing different binaries, but I do have some concerns about the naming of the packages.

From what I understand the 22.04 LTS will be supported for 10 years, so it will be hanging around for a long time... Thus we'll have wxWidgets 3.0 coming with it all that time.

Currently the ubuntu-latest still use 22.04 and most likely will until next LTS is released, but I could be wrong about that.

So, I wonder if your suggested package naming is really the best option. Maybe we should change the package naming overall to reflect the actual toolchain used on GitHub when building the packages. Also, since the wxWidgets 3.2 is not normally included with the build tools here on GitHub yet, I think that it's the 3.2 version that should have special naming so that it's obvious that it's not built with the standard distribution tools available here.

[oleg68]

@larspalo I don't like the idea of giving the package name dependent on the GitHub technical stuff. Package names should be relevant for users, not for GitHub. So I propose grandorgue for the most modern libraries and grandorgue-something for the compatibility mode. We should intend users to use binaries with the most modern libraries and to use the compatibility ones only if grandorgue can not be easy installed.

Some linux distributions (ex. Ubuntu 22.10, Fedora 37) have both wx3.0 and wx3.2 libraries. It is better that their users would install 3.2 by default.

[jason-barba]

Being a cautious person I tend to wait for LTS distributions of Ubuntu. I can also see two user groups. One with the cautious users like myself. The other have eager users that strive to always have the latest versions. With this in mind, I would support something along @larspalo 's line. I think that you will find the most unexperienced users in the first group, and they will - like I - be confused if there are two distributions where one is named with an extra extension and the distribution for the cautious is the one with the extension.

I would therefor suggest naming the distributions so that it is clear which version LTS users should use, and the other could be named lets call it something more experimental. With your naming suggestion @oleg68 I myself would see the version with the extension being the "experimental" one, and therefor will stumble.

(I am not sure I make my point clear here but I hope so ...)

Just my 2 pence
//Jens

[vpoguru]

Are the people who prefer to stay with an OS LTS release interested in the very latest version of GO?

[jason-barba]

Good summary of my post @vpoguru :-)

[larspalo]

@oleg68 So, I just suggest that you switch things around until Github will provide next LTS version. Release the grandorgue-wx32 as the newer specially built version and keep the standard naming for what is provided by default.

[oleg68]

@larspalo I understand your suggestion but I disagree with the relation between Github runner versions and grandorgue package naming.

I think we should build a default go package on top on the latest wx, and a specisal package for compatibility with the previous wx. In my approach, when Github provide the next LTS, we will change the build scripts, that aren't visible for users, but won't change the package names, that are visible for users.

[oleg68]

@vpoguru

Could you test installing a deb package from the intermediate build on you ubuntu 23 system?

[larspalo]

I think we should build a default go package on top on the latest wx, and a specisal package for compatibility with the previous wx. In my approach, when Github provide the next LTS, we will change the build scripts, that aren't visible for users, but won't change the package names, that are visible for users.

I understand your idea, but still I'd rather see that they who want to live on the bleeding edge of development are the ones that should know to search for the different package (or know better to compile it by themselves). I don't think we should by default move to a more recent stable version of wxWidgets than is supported by default on a LTS system either. On the other hand I do think that it's perfectly ok to provide packaged builds done with a later wxWidgets and explicitly state that.

Also I note that we still use ubuntu-20.04 for all Linux based builds and not any with ubuntu-latest (except the cross compile to windows). Personally I think that we should by default provide linux vanilla builds for the latest LTS version, with the exception of the appimages that should be done on the oldest still supported LTS version. Anything other than that should be explicitly marked as the exception. This is of course just my opinion...

[oleg68]

I understand your idea, but still I'd rather see that they who want to live on the bleeding edge of development are the ones that should know to search for the different package (or know better to compile it by themselves).

Personally I try to use the most recent versions of any software because I hope that any new version is better than the old one. Unfortunally, it is not always true. After compiling grandorgue with wxWidgets 3.2 at this build I installed it at my Fedora 37 system and noticed that not everything was all right. There was some undesired visual artifacts that need to be fixed in grandorgue.

So for now I agree with you that wx30 should be the main variant and wx32 - an experimental with an extra package suffix.

I don't think we should by default move to a more recent stable version of wxWidgets than is supported by default on a LTS system either.

When you talk about LTS you mean Ubuntu. But the users have different linux distributions, not only ubuntu. So linking the package name policy to the ubuntu LTS releases is not obvious.

On the other hand I do think that it's perfectly ok to provide packaged builds done with a later wxWidgets and explicitly state that.

OK. I will build grandorgue with wx3.0 and grandorgue-wx32.

Also I note that we still use ubuntu-20.04 for all Linux based builds and not any with ubuntu-latest (except the cross compile to windows). Personally I think that we should by default provide linux vanilla builds for the latest LTS version, with the exception of the appimages that should be done on the oldest still supported LTS version. Anything other than that should be explicitly marked as the exception. This is of course just my opinion...

We build grandorgue not only for certain releases of ubuntu, but for any debian or redhat based linux distributions with compatible libraries. Usually the libraries are backward compatible, so grandorgue built with an old system can run on any newer system with newer libraries, but not vice versa. So I have to use the oldest availavble ubuntu for making the range of compatible systems as much as wide.

The exception is the wxWidget 3.0 library because ubuntu maintainters got it rid in the newest versions. I think it would be better to include both wxWidget versions, at least, for the next LTS release.

[larspalo]

I think it would be better to include both wxWidget versions, at least, for the next LTS release.

You're right. There might be small adjustments needed to get both the 3.0 and 3.2 versions to work as they should (if at all possible), and eventually we should of course switch towards the newer version, but for a while they will co-exist and during that time it's best to support them both.