[Inkscape-devel] Debian 8 compatibility falling apart after one month of Debian 9

[Josh Andler]

http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies indicates
that 3.8 is what should be required for GTK+... This is the official place
this is tracked, so if someone introduced features that are incompatible
it's their problem to fix. This is no different than us being conservative
about C++ features getting introduced into the codebase years after they're
available in compilers... given previous practices and reasoning, this
wouldn't pass the enterprise litmus test as they wouldn't update to a newer
distro version a month after release. There are cases where we did decide
to push past that standard, but they've been very few and far between.

Cheers,
Josh

On Sat, Jul 22, 2017 at 1:49 AM, Michael Soegtrop via Inkscape-devel <

Ok, I am giving up now. The next issue is the change of
"create_popup_menu" in "filter-effects-dialog.cpp". There is no easy way
to patch this for GTK 3.14, because there Gtk::Menu::Menu(const
Gtk::Menu&) is private. Since there are no GTK backports in Debian 8, I
have to update to Debian 9 to build inkscape. Not nice :-(
Best regards,
Michael
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Bryce Harrington]

Post by Josh Andler
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies indicates
that 3.8 is what should be required for GTK+... This is the official place
this is tracked, so if someone introduced features that are incompatible
it's their problem to fix. This is no different than us being conservative
about C++ features getting introduced into the codebase years after they're
available in compilers... given previous practices and reasoning, this
wouldn't pass the enterprise litmus test as they wouldn't update to a newer
distro version a month after release. There are cases where we did decide
to push past that standard, but they've been very few and far between.

+1 agreed on all points.

Would people like to establish a process for periodically considering
proposals for incrementing dependency versions? I'm thinking like a
monthly project meeting to discuss development status and direction.

Bryce

Post by Josh Andler
On Sat, Jul 22, 2017 at 1:49 AM, Michael Soegtrop via Inkscape-devel <

Ok, I am giving up now. The next issue is the change of
"create_popup_menu" in "filter-effects-dialog.cpp". There is no easy way
to patch this for GTK 3.14, because there Gtk::Menu::Menu(const
Gtk::Menu&) is private. Since there are no GTK backports in Debian 8, I
have to update to Debian 9 to build inkscape. Not nice :-(
Best regards,
Michael
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alex Valavanis]

Hi Guys,

This is a result of my overzealous deprecation fixes... sorry about that;
I'll go back and try to insert backward-compatibility patches.

I agree that we should try to support older LTS releases, but there can be
fairly major headaches in simultaneously supporting bleeding-edge distros
(Arch etc) and Debian oldstable. For example, until last month, we needed
to cope with 4 years of API change history (Wheezy released in May 2013).

I think it would be useful to agree a general policy for this kind of
thing... i.e., how long after a new LTS Ubuntu/Debian release will we aim
to allow build compatibility? The "safest" option is to guarantee that all
Debian/Ubuntu releases are supported until their EOL. However, that means
essentially rejecting all use of new library features for ~5 years, which I
can imagine will limit innovation and put off some developers from
contributing.

AV

Post by Josh Andler

Post by Josh Andler
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies indicates
that 3.8 is what should be required for GTK+... This is the official

place

Post by Josh Andler
this is tracked, so if someone introduced features that are incompatible
it's their problem to fix. This is no different than us being

conservative

Post by Josh Andler
about C++ features getting introduced into the codebase years after

they're

Post by Josh Andler
available in compilers... given previous practices and reasoning, this
wouldn't pass the enterprise litmus test as they wouldn't update to a

newer

Post by Josh Andler
distro version a month after release. There are cases where we did decide
to push past that standard, but they've been very few and far between.

+1 agreed on all points.
Would people like to establish a process for periodically considering
proposals for incrementing dependency versions? I'm thinking like a
monthly project meeting to discuss development status and direction.
Bryce

Post by Josh Andler
On Sat, Jul 22, 2017 at 1:49 AM, Michael Soegtrop via Inkscape-devel <

Ok, I am giving up now. The next issue is the change of
"create_popup_menu" in "filter-effects-dialog.cpp". There is no easy

way

Post by Josh Andler

to patch this for GTK 3.14, because there Gtk::Menu::Menu(const
Gtk::Menu&) is private. Since there are no GTK backports in Debian 8, I
have to update to Debian 9 to build inkscape. Not nice :-(
Best regards,
Michael
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------

------------------

Post by Josh Andler
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Eduard Braun]

Post by Bryce Harrington

Post by Josh Andler
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies indicates
that 3.8 is what should be required for GTK+... This is the official place
this is tracked, so if someone introduced features that are incompatible
it's their problem to fix.

This is also the version indicated in the cmake scripts (which should
probably be kept in sync with the wiki page), see
https://gitlab.com/inkscape/inkscape/blob/5198e38c82379f7b87f5cd964d565821a5786a49/CMakeScripts/DefineDependsandFlags.cmake#L250

If this version matches the actual requirement unexpected build failures
like Michael was experiencing should be impossible as cmake would
already warn at the configure stage.

Post by Bryce Harrington
Would people like to establish a process for periodically considering
proposals for incrementing dependency versions? I'm thinking like a
monthly project meeting to discuss development status and direction.

I guess it would be more efficient to

* decide which distributions we want to support as this will
ultimately limit the dependency versions we *can* support (I doubt
that would need to be re-evaluated monthly).
* implement proper checks (likely CI builds) that ensure we do not
accidentally introduce dependencies not. The ppa builds run on older
Ubuntu distributions were always helpful in that regard, so I hope
we can get them (or something comparable using GitLab CI) back up
eventually.

Regards,
Eduard

[Martin Owens]

Post by Bryce Harrington
+1 agreed on all points.
Would people like to establish a process for periodically considering
proposals for incrementing dependency versions?  I'm thinking like a
monthly project meeting to discuss development status and direction.

I would. I had to use some C++11 which is newer than what we have the
wiki. I haven't done as much C++ as I would have liked because of the
restrictions on C++11 and with that being now available, it's made the
process of development easier for me.

Hopefully we can set some reasonable limits and keep the page up to
date. But to make this job easier, we should try and see if we can set
up some automatic support scripts that pull in a summary of the
different distros and their versions of key dependencies.

Does anyone know anything like this?

Best Regards, Martin Owens

[Mattia Rizzolo]

For Debian there are online lists with all packages and versions, e.g.
https://packages.debian.org/stable/allpackages?format=txt.gz
For Ubuntu the lists are e.g.
https://packages.ubuntu.com/de/xenial/allpackages?format=txt.gz
http://packages.linuxmint.com/list.php?release=Sonya
Should be easy to convert with XSLT.
It should take only a few lines of Python to fetch and check these.

All of those are Debian derivates, and they share the same packaging and
repository format.
So it's (imho) way easier to instead get the Sources file (like
https://deb.debian.org/debian/dists/stretch/main/source/Sources.xz for
debian, very similar URI for the others) and use any rfc 822 parser to
read it; there are also debian-specific things like a python-debian
python module and a grep-dctrl thing for bash (both usuable outside of a
debian environment, here "debian-specific" means they are done to parse
debian (and derivative) stuff).

[Martin Owens]

Thanks Michael,

https://packages.debian.org/stable/allpackages?format=txt.gz
https://packages.debian.org/oldstable/allpackages?format=txt.gz
https://packages.debian.org/testing/allpackages?format=txt.gz
https://packages.debian.org/jessie/allpackages?format=txt.gz
(goto https://packages.debian.org/stable/, select a version at the
top
and click at the end on "(compact compressed textlist)")

Looks like you've got a sizable amount of data here.

I guess there are similar lists for the other major distros.
It should take only a few lines of Python to fetch and check these.
What are the relevant distros?

Ubuntu (this covers A LOT of distros)
Mint
Fedora
Debian
openSUSE
Arch / Manjaro (although arch is fairly bleeding edge)

That most of the targets. We'd first have to get a sensible read on
supported versions vs bleeding edge and their relevant dates.

Only then could we calculate the packages we need.

Best Regards, Martin Owens

[Eduard Braun]

I have some experience with creating build systems which use specific
package versions based on Cygwin. Since there is a working MSys build,
it shouldn't be difficult to build with specific package versions - one
just has to create a local cygwin or MSys package repository, which
keeps these specific versions and tell the Cygwin/MSys installer to use
that one. The Cygwin installer creates a suitable repository as a cache
automatically. Not sure how this works with MSys, but I guess it has
similar features. The main issue here might be to get the versions
mentioned in the Wiki. One might have to build them from scratch.
If someone has a years old cache folder of Cygwin or MSys with all the
old package versions, please put is somewhere.
It would make sense to run two builds, one with the latest packages and
one with an archived set of packages.
Best regards,
Michael

(just for clarification: we're using MSYS2, not MSYS! Also we're
creating native builds based on mingw-w64, not Cygwin builds)

While I agree on the idea of having CI with packages using the minimal
version numbers it does not make that much sense to uses MSYS2 as a base
as it's designed to be rolling release and constantly develops. Creating
our own package repository sounds like a lot of unncessary work,
especially as I doubt a "years old cache" of MSYS2 would be able to
build Inkscape at this stage (as a matter of fact I added some packages
myself and fixed some bugs in others along the way).
I assume it'd be much easier to decide on some old but widespread Linux
distro an base CI on that.

Regards,
Eduard

[Tobias Ellinghaus]

Am Sonntag, 23. Juli 2017, 23:22:46 CEST schrieb Michael Soegtrop via

Dear Eduard, dear Inkscape Team

Post by Eduard Braun
If this version matches the actual requirement unexpected build failures
like Michael was experiencing should be impossible as cmake would
already warn at the configure stage.

I would think that CMake allows newer versions than the specified one,
unless explicitly told otherwise. The issue here is that some GTK 3.16
are actually used although only GTK 3.8 features should be used (as far
as I understood).

While I tend to believe that users of ages old stale^Wstable distributions
shouldn't expect bleeding edge development versions of programs to work on
their systems I'd still like to help with at least the glib/gtk part:

Read [0] and [1], then add the defines to CMakeLists.txt to have them set for
all files. Also make sure that the compiler warns about deprecated functions.
That will bring you half way there. Once the code base compiles without
compiler warnings you can enable -Werror for development builds (i.e., when
there is a .git folder) and you will be sure to stay compatible with those
libraries.

The rest can be done with CI, or just crowd source it and wait for people
complaining when builds fail. :-)

[...]

Best regards,
Michael

Tobias


[0] https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS
[1] https://developer.gnome.org/gdk3/stable/gdk3-General.html#GDK-VERSION-MAX-ALLOWED:CAPS

[Alex Valavanis]

I've re-added the listing for Debian oldstable to our "Tracking
Dependencies" page...
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Distros

Post by Tobias Ellinghaus
Am Sonntag, 23. Juli 2017, 23:22:46 CEST schrieb Michael Soegtrop via

Dear Eduard, dear Inkscape Team

Post by Eduard Braun
If this version matches the actual requirement unexpected build

failures

Post by Eduard Braun
like Michael was experiencing should be impossible as cmake would
already warn at the configure stage.

I would think that CMake allows newer versions than the specified one,
unless explicitly told otherwise. The issue here is that some GTK 3.16
are actually used although only GTK 3.8 features should be used (as far
as I understood).

While I tend to believe that users of ages old stale^Wstable distributions
shouldn't expect bleeding edge development versions of programs to work on
Read [0] and [1], then add the defines to CMakeLists.txt to have them set for
all files. Also make sure that the compiler warns about deprecated functions.
That will bring you half way there. Once the code base compiles without
compiler warnings you can enable -Werror for development builds (i.e., when
there is a .git folder) and you will be sure to stay compatible with those
libraries.
The rest can be done with CI, or just crowd source it and wait for people
complaining when builds fail. :-)
[...]

Best regards,
Michael

Tobias
[0] https://developer.gnome.org/glib/stable/glib-Version-
Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS
[1] https://developer.gnome.org/gdk3/stable/gdk3-General.html#
GDK-VERSION-MAX-ALLOWED:CAPS
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alex Valavanis]

Just another +1 for handling this all through CI. It will place an
impossible burden on developers if we need to manually rebuild everything
on a list of "supported" build systems before committing to trunk.

The PPA builds are currently out of date because we don't yet have an
"official" mirror of the git repo on Launchpad. It's not too tricky to set
up though, and we can switch to using git-builder when it's available.


AV

Post by Alex Valavanis
I've re-added the listing for Debian oldstable to our "Tracking
Dependencies" page... http://wiki.inkscape.org/wiki/index.php/Tracking_
Dependencies#Distros

Post by Tobias Ellinghaus
Am Sonntag, 23. Juli 2017, 23:22:46 CEST schrieb Michael Soegtrop via

Dear Eduard, dear Inkscape Team

Post by Eduard Braun
If this version matches the actual requirement unexpected build

failures

Post by Eduard Braun
like Michael was experiencing should be impossible as cmake would
already warn at the configure stage.

I would think that CMake allows newer versions than the specified one,
unless explicitly told otherwise. The issue here is that some GTK 3.16
are actually used although only GTK 3.8 features should be used (as far
as I understood).

While I tend to believe that users of ages old stale^Wstable distributions
shouldn't expect bleeding edge development versions of programs to work on
Read [0] and [1], then add the defines to CMakeLists.txt to have them set for
all files. Also make sure that the compiler warns about deprecated functions.
That will bring you half way there. Once the code base compiles without
compiler warnings you can enable -Werror for development builds (i.e., when
there is a .git folder) and you will be sure to stay compatible with those
libraries.
The rest can be done with CI, or just crowd source it and wait for people
complaining when builds fail. :-)
[...]

Best regards,
Michael

Tobias
[0] https://developer.gnome.org/glib/stable/glib-Version-Informa
tion.html#GLIB-VERSION-MAX-ALLOWED:CAPS
[1] https://developer.gnome.org/gdk3/stable/gdk3-General.html#GD
K-VERSION-MAX-ALLOWED:CAPS
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alex Valavanis]

Hi All,

I've brought the trunk PPA back online... it's currently failing on the
"make test" step:

https://launchpadlibrarian.net/330394206/buildlog_ubuntu-xenial-amd64.inkscape-trunk_1%3A0.92.0+devel+15937+86~ubuntu16.04.1_BUILDING.txt.gz

As an interim measure, I've disabled the test rule in the PPA builder until
someone figures out how to fix it!


AV

Post by Alex Valavanis
Just another +1 for handling this all through CI. It will place an
impossible burden on developers if we need to manually rebuild everything
on a list of "supported" build systems before committing to trunk.
The PPA builds are currently out of date because we don't yet have an
"official" mirror of the git repo on Launchpad. It's not too tricky to set
up though, and we can switch to using git-builder when it's available.
AV

Post by Alex Valavanis
I've re-added the listing for Debian oldstable to our "Tracking
Dependencies" page... http://wiki.inkscape.org/wiki/
index.php/Tracking_Dependencies#Distros

Post by Tobias Ellinghaus
Am Sonntag, 23. Juli 2017, 23:22:46 CEST schrieb Michael Soegtrop via

Dear Eduard, dear Inkscape Team

Post by Eduard Braun
If this version matches the actual requirement unexpected build

failures

Post by Eduard Braun
like Michael was experiencing should be impossible as cmake would
already warn at the configure stage.

I would think that CMake allows newer versions than the specified one,
unless explicitly told otherwise. The issue here is that some GTK 3.16
are actually used although only GTK 3.8 features should be used (as far
as I understood).

While I tend to believe that users of ages old stale^Wstable
distributions
shouldn't expect bleeding edge development versions of programs to work on
Read [0] and [1], then add the defines to CMakeLists.txt to have them set for
all files. Also make sure that the compiler warns about deprecated functions.
That will bring you half way there. Once the code base compiles without
compiler warnings you can enable -Werror for development builds (i.e., when
there is a .git folder) and you will be sure to stay compatible with those
libraries.
The rest can be done with CI, or just crowd source it and wait for people
complaining when builds fail. :-)
[...]

Best regards,
Michael

Tobias
[0] https://developer.gnome.org/glib/stable/glib-Version-Informa
tion.html#GLIB-VERSION-MAX-ALLOWED:CAPS
[1] https://developer.gnome.org/gdk3/stable/gdk3-General.html#GD
K-VERSION-MAX-ALLOWED:CAPS
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Eduard Braun]

Post by Alex Valavanis
I've brought the trunk PPA back online... it's currently failing on

That's because the build is configured to do "make test" which only runs
tests but does not build them.
If you replace it with "make check" we should be all set!

Thanks for bringing this back online!

Regards,
Eduard

[Alex Valavanis]

OK great... I'll wait for the current build to finish first and check there
aren't any further issues, then I'll try to re-enable the tests.


AV

Post by Eduard Braun

Post by Alex Valavanis
I've brought the trunk PPA back online... it's currently failing on the

That's because the build is configured to do "make test" which only runs
tests but does not build them.
If you replace it with "make check" we should be all set!
Thanks for bringing this back online!
Regards,
Eduard

[Bryce Harrington]

Post by Alex Valavanis
Hi All,
I've brought the trunk PPA back online... it's currently failing on the
https://launchpadlibrarian.net/330394206/buildlog_ubuntu-xenial-amd64.inkscape-trunk_1%3A0.92.0+devel+15937+86~ubuntu16.04.1_BUILDING.txt.gz
As an interim measure, I've disabled the test rule in the PPA builder until
someone figures out how to fix it!

Thanks for converting the PPAs, Alex!

Bryce

Post by Alex Valavanis
AV

Post by Alex Valavanis
Just another +1 for handling this all through CI. It will place an
impossible burden on developers if we need to manually rebuild everything
on a list of "supported" build systems before committing to trunk.
The PPA builds are currently out of date because we don't yet have an
"official" mirror of the git repo on Launchpad. It's not too tricky to set
up though, and we can switch to using git-builder when it's available.
AV

Post by Alex Valavanis
I've re-added the listing for Debian oldstable to our "Tracking
Dependencies" page... http://wiki.inkscape.org/wiki/
index.php/Tracking_Dependencies#Distros

Post by Tobias Ellinghaus
Am Sonntag, 23. Juli 2017, 23:22:46 CEST schrieb Michael Soegtrop via

Dear Eduard, dear Inkscape Team

Post by Eduard Braun
If this version matches the actual requirement unexpected build

failures

Post by Eduard Braun
like Michael was experiencing should be impossible as cmake would
already warn at the configure stage.

I would think that CMake allows newer versions than the specified one,
unless explicitly told otherwise. The issue here is that some GTK 3.16
are actually used although only GTK 3.8 features should be used (as far
as I understood).

While I tend to believe that users of ages old stale^Wstable distributions
shouldn't expect bleeding edge development versions of programs to work on
Read [0] and [1], then add the defines to CMakeLists.txt to have them set for
all files. Also make sure that the compiler warns about deprecated functions.
That will bring you half way there. Once the code base compiles without
compiler warnings you can enable -Werror for development builds (i.e., when
there is a .git folder) and you will be sure to stay compatible with those
libraries.
The rest can be done with CI, or just crowd source it and wait for people
complaining when builds fail. :-)
[...]

Best regards,
Michael

Tobias
[0] https://developer.gnome.org/glib/stable/glib-Version-Informa
tion.html#GLIB-VERSION-MAX-ALLOWED:CAPS
[1] https://developer.gnome.org/gdk3/stable/gdk3-General.html#GD
K-VERSION-MAX-ALLOWED:CAPS
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[mathog]

My problem is that in the last week
- 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:

https://linuxlifecycle.com/

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
***@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

[Alex Valavanis]

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

Post by mathog

My problem is that in the last week
- 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
https://linuxlifecycle.com/
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel