Add conditional commit pinning for packages incompatible with 16.04

[planthaber]

The current version of base/cmake and typelib are incompatible with ubuntu 16.04

I think it is not worth fixing it in the packages in themself as support of ubuntu 16.04 ends next year.

So think pinning these packages on 16.04 systems is good enough as a fix and development can move on without interference.

[doudou]

Official support for Ubuntu 16.04 in Rock ended more than two years ago. I'm more than happy to keep backward compatibility when the cost is reasonably low, but not with such a hacky way.

The best way to handle "backward compatibility" would be to finally start re-releasing Rock Core and finally version its packages. It's on my to-do list for the next months.

In any case what is incompatible ? I'd rather evaluate if we could make the CMake changes compatible (or easy-to-make-compatible)

[2maz]

The best way to handle "backward compatibility" would be to finally start re-releasing Rock Core and finally version its packages. It's on my to-do list for the next months.

@doudou while it might be not exactly what you are after, I still want to point out, that releasing is already happening with the Debian packages, see https://github.com/rock-core/rock-osdeps-package_set

[doudou]

To be honest, I've seen notifications about those and didn't look very deep. This is great and useful work. I only believe it's a pity it's not more advertised on both the website and the mailing list.

Now, is that "a release" from my perspective ?

Is there a tag on the buildconf with the relevant overrides file, that would allow to replicate that release ? If not, people are stuck as soon as you decide to not build on a particular OS version, or remove old debian packages because reasons (e.g. Ubuntu 16.04 here). If not, would it be feasible to add them ?

In fine, what I am really looking to achieve is having a as-close-as-possible semantic versioning and changelogs, which would allow us to have a controlled deprecation path for a lot of very old stuff, and when dropping support for a particular version of a dependency (e.g. CMake), have a version to fallback to that people can pin and use on their old(er) systems.

[doudou]

The good part of having versioning & release is that we should be able to advance version of packages outside the Rock release cycle.

[planthaber]

You could have had a look into the overrides i made. Incompatible are base/cmake and typelib.

You are right, 16.04 ran out of support 2 years ago, exactly that is why I did not solve it the "proper" but in a hacky way. Nobody wants to prepare and maintain a release for a non-supported OS.

base/cmake fails with:

   CMake Error at CMakeLists.txt:2 (project):
      project with VERSION must use LANGUAGES before language names.

and typelib has an incompatible boost version

/opt/workspace/tools/typelib/test/test_display.cc:2:58: fatal error: boost/test/tools/floating_point_comparison.hpp: No such file or directory
    compilation terminated.

My impression was that it is not worth fixing compability issues for non-supported OSes.

[planthaber]

Apart from this a release would have been far better, but we should have done it years ago for 16.04

[doudou]

Apart from this a release would have been far better, but we should have done it years ago for 16.04

Well. If the current version minus a few changes is still compatible with 16.04, we can still do it for 16.04 ...

[doudou]

You could have had a look into the overrides i made.

You want 16.04 compatibility, you take the time to make your case.

[doudou]

My impression was that it is not worth fixing compability issues for non-supported OSes.

Yet, you make instead hacky changes to the rock core build within the package set to keep it building on 16.04. So, you are essentially fixing compatibility issues for non-supported OSes.

The base/cmake incompatibility is due to the usage of DESCRIPTION which actually appeared in CMake 3.9. We should either drop DESCRIPTION or raise the minimum required to CMake 3.9.

And, should we decide to go on with advertising DESCRIPTION, this particular change would be the death of this pull request. Other packages in rock-core will get changed and I definitely won't let you slowly add overrides for these packages one by one. You need a better solution than that. Just generate a versions file for the "last known to work" version "ubuntu-16.09-last" and save it as a tag. Could be saved in the rock-core buildconf.

The boost header used in typelib appeared in boost 1.59. I wouldn't have a problem if you proposed a conditional for typelib. But it will get bad little by little as well.

Now comes one interesting question: you seem to be maintaining an old system, why not use the binary releases you probably helped develop ?

[planthaber]

I thought I'd provide this workaround for all potential users, I guess I'll just keep in in my own buildconf.

[2maz]

To be honest, I've seen notifications about those and didn't look very deep. This is great and useful work. I only believe it's a pity it's not more advertised on both the website and the mailing list.

Regarding the mailing list, apart from announcing each release (master-20.01: was announced in March 2020) and pointing to the package which has documentation in the README.md, what do you need to become interested in just trying it out?

Website, yes, I admit that has been too long an open point on my list, although for users it would basically only replicate what is already found in the README.md.

Now, is that "a release" from my perspective ?

I suggest you refer to it as your aspired way of releasing rock - obviously there a multiple ways of releasing and using binary packages is one. I also do not say there should be only one way.

Is there a tag on the buildconf with the relevant overrides file, that would allow to replicate that release ? If not, people are stuck as soon as you decide to not build on a particular OS version, or remove old debian packages because reasons (e.g. Ubuntu 16.04 here). If not, would it be feasible to add them ?

While you are right to track the it, I had my priorities on other items so far and there has been no feedback that this information is urgently needed / a showstopper. Anyhow, I already started doing so for master-20.01 https://github.com/rock-core/rock-osdeps-buildconf/tree/master-20.01. Note that additional patches are required and gems are also packaged - something autoproj is not snapshotting or is it!? So the overrides files do not necessarily give the full picture for the debian package release - the deb package includes all essential information, in changelog's and patch files.

Regarding removal or addition of packages: that should be no major concern. Packages are hosted with reprepo and anyone can mirror the packages, e.g., using a reprepro instance or apt-mirror.

In fine, what I am really looking to achieve is having a as-close-as-possible semantic versioning and changelogs, which would allow us to have a controlled deprecation path for a lot of very old stuff, and when dropping support for a particular version of a dependency (e.g. CMake), have a version to fallback to that people can pin and use on their old(er) systems.

Definitely a good thing to have, yet I see this and a binary release as complementary.

[doudou]

Regarding the mailing list, apart from announcing each release (master-20.01: was announced in March 2020) and pointing to the package which has documentation in the README.md, what do you need to become interested in just trying it out?

From what I remember, these mails started to appear as "oh guys we've got this binary release". At least something explaining what is going on, what you get and not get and where to find more information. Just "there's a new release" has not been enough to move my lazy ass. If that perspective is inaccurate, just forget what I said.

I am not interested, and that's pretty obvious why since I always use the development of the systems as a way to make Rock progress forward. Now, it seems that you take it as an attack on what you did. I don't know how to add to "This is great and useful work".

I also do not say there should be only one way.

Well. I did say "from my perspective". And that I consider the binary releases "great and useful work." And that it is a pity that it's not more advertised. All signals that I consider the binary releases a very useful thing. So if you feel I attacked your work in any way, please believe me when I say it's not my intention.

yet I see this and a binary release as complementary.

And I never said otherwise. However, for my workflow, it would be more useful to have a binary release that is derived from a source release than the other way around.

The lack of human-made changelogs is a big problem, as people aren't aware of deprecations and possible breakage. Updating is hit-and-miss because there is no information about what changes. And then it's hard to decide whether some deprecated stuff can be removed.

But, again, I think it should rather be a work "from upstream", that is versioning independent packages that are then "packaged" as a single release.

[doudou]

Also,

patches are also required

They (rather obviously) should be only required for the packaging work. I was not referring to a way to replicate a binary release, but a way to build the same software from source.

something autoproj is not snapshotting or is it

It is not, but it could be done rather simply since autoproj v2 is out. Get the Gemfile.lock from the prefix and add a way for autoproj to use an initial Gemfile.lock before running bundler install. bundler (and all the bundling tools that came later) is made to make sure a set of packages can be replicated.

[2maz]

I am not interested, and that's pretty obvious why since I always use the development of the systems

No I was/am not angry, rather confused since you basically suggest/ask for more documentation to read, but create the impression that you have not even looking into the existing. Maybe I misunderstood that you were acting only as advocate of other users. Nevertheless, since you initiated the whole packaging thing (you are still second important contributor to apaka) I would have assumed some interest.

And I never said otherwise. However, for my workflow, it would be more useful to have a binary release that is derived from a source release than the other way around.

Mhm, you asked how to replicate the current release. To clarify how a release is created right now:

1. make a full bootstrap of Rock in say 1. January 2020
2. then I run apaka on this workspace with the patches required for the packaging Ending up having a 'freezed' state of rock packages that are now considered compatible with each other, reflecting the state of 1. January 2020.

So only thing needed as 1. is a fully reproducible state from an autoproj snapshot (including package's retrieved through packages managers such as bundler/gem, pip, ...).

[doudou]

This is widely out of topic here ... can we move this elsewhere ? The team discussions ? Mails ?

[2maz]

Moved to team discussions