Debian 8 compatibility falling apart after one month of Debian 9
Dear Inkscape Team,
I wanted to start a general discussion on compatibility. I um using Debian 8. Ok maybe I shouldn't since Debian 9 is out since a month (June 17th, 2017), but I still like it. My problem is that in the last week quite a few changes came in, which are not compatible with Debian 8:
- Requirement for CMake 3.2+ (Debian 8 has 3.0.2) specific syntax of add_custom_target
- Requirement for GTK 3.16 (Debian 8 has 3,14) use of gtk_label_set_xalign
- Requirement for some rather late libg++ using isinf without :: or std:: qualifier See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891 Not sure which version introduced the fix, but Debian 8 doesn't have it.
The first two are just build issues, but the GTK issue will result in binary incompatibilities.
I just did an update to master after a week and now sitting here since two hours to get it build again (there were some additional dependencies added last week which are ok in Debian 8 but still required installing the packages). The build stopped now at 59%, not sure how much is still ahead.
Is this wanted that compatibility with the previous version of Debian breaks after one month?
On what kind of system do the CI tests run? Ubuntu 16.04?
Best regards,
Michael
On 22-Jul-2017 01:14, Michael Soegtrop via Inkscape-devel wrote:
My problem is that in the last week quite a few changes came in, which are not compatible with Debian 8:
- Requirement for CMake 3.2+ (Debian 8 has 3.0.2) specific syntax of add_custom_target
Developers who do not work on production systems frequently do not give much thought to backwards compatibility. These developers often run the absolute latest releases of Fedora or Ubuntu, and so most of the packages they see are on the bleeding edge of the release set. Machines used in production environments in business and academia usually run much more conservative and stable releases, and that translates to much older, versions of software. As an example, Centos 6 (basically the same as RHEL 6 but free), a fairly common platform in scientific circles, was released in 2011, full updates just ended in May, and security updates will continue until November 2020. Version 6.9, the last update in that version, currently has cmake 2.8.12 and it will never have an official upgrade beyond that. 2.8.12 was released Oct 2013, so is not quite five years old, but close. Centos 7.3 also has cmake 2.8.12. Cmake 3.2.1 (was there a 3.2.0?) was released Mar 2015, which in my view is much too recent to require.
As a rule of thumb, if there is a requirement for a library version, language version, or tool which is younger than 5 years old it will almost certainly not be satisfied in these environments with default packages. It _may_ be possible to find alternative packages, but a simple download, build, and run will not work, and hours to days scrounging up the newer requirements will need to be expended. Now I can already hear some developers screaming about using archaic tools, but that's the difference between having to work in production environments and messing about with one's own computers, where that constraint does not exist. For serious software if the oldest green check for any of the OS's here:
does not have the version of the package you want to use, then that package is too recent to employ in a project. That's how I feel, anyway. For Inkscape I would add in the same constraint for Mingw and whatever environment people are using to build on OS X.
Whatever new cmake feature that 3.2 provides can certainly be worked around using older versions. That is almost always the case with the latest and greatest of every package. The primary, and quite rare, exception being where some showstopper of a security bug exists and the only way around it is to use a later release.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Sure... I appreciate that business/academic users will want to run stable LTS/enterprise versions of distros. However, they also usually either stick with old versions of applications or spend large sums of money on upstream/distro maintenance contracts for back-porting business-critical software, whereas Inkscape has no paid developers. As such, we rely on voluntary developers working at home on their own PCs to maintain compatibility with old distros, so unfortunately it's quite a difficult task!
Speaking personally, I try my best to avoid breaking compatibility but it's very hard without good CI.
Perhaps, then, part of the solution is to offer paid maintenance contracts? I can think of a couple of the other devs who would be willing to support users in this way.
AV
On 24 July 2017 at 17:57, mathog <mathog@...1176...> wrote:
On 22-Jul-2017 01:14, Michael Soegtrop via Inkscape-devel wrote:
My problem is that in the last week quite a few changes came in, which are not compatible with Debian 8:
- Requirement for CMake 3.2+ (Debian 8 has 3.0.2) specific syntax of add_custom_target
Developers who do not work on production systems frequently do not give much thought to backwards compatibility. These developers often run the absolute latest releases of Fedora or Ubuntu, and so most of the packages they see are on the bleeding edge of the release set. Machines used in production environments in business and academia usually run much more conservative and stable releases, and that translates to much older, versions of software. As an example, Centos 6 (basically the same as RHEL 6 but free), a fairly common platform in scientific circles, was released in 2011, full updates just ended in May, and security updates will continue until November 2020. Version 6.9, the last update in that version, currently has cmake 2.8.12 and it will never have an official upgrade beyond that. 2.8.12 was released Oct 2013, so is not quite five years old, but close. Centos 7.3 also has cmake 2.8.12. Cmake 3.2.1 (was there a 3.2.0?) was released Mar 2015, which in my view is much too recent to require.
As a rule of thumb, if there is a requirement for a library version, language version, or tool which is younger than 5 years old it will almost certainly not be satisfied in these environments with default packages. It _may_ be possible to find alternative packages, but a simple download, build, and run will not work, and hours to days scrounging up the newer requirements will need to be expended. Now I can already hear some developers screaming about using archaic tools, but that's the difference between having to work in production environments and messing about with one's own computers, where that constraint does not exist. For serious software if the oldest green check for any of the OS's here:
does not have the version of the package you want to use, then that package is too recent to employ in a project. That's how I feel, anyway. For Inkscape I would add in the same constraint for Mingw and whatever environment people are using to build on OS X.
Whatever new cmake feature that 3.2 provides can certainly be worked around using older versions. That is almost always the case with the latest and greatest of every package. The primary, and quite rare, exception being where some showstopper of a security bug exists and the only way around it is to use a later release.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (3)
-
Alex Valavanis -
mathog -
Michael Soegtrop