Consider making libstatgrab parallel-installable

[atsampson]

Since we're currently heading for a 1.0 release with a different API, we should consider making libstatgrab parallel-installable for future releases -- i.e. install the library as libstatgrab-1.so, and the headers into include/libstatgrab-1 (see http://ometer.com/parallel.html for more details). This is largely transparent to the pkg-config-using programmer, but it means we can have multiple versions of libstatgrab installed at the same time.

I'm not sure if this is actually worth the effort, but if we're going to do it, then now would be the time...

[tdb]

This is an interesting idea. With my FreeBSD packagers hat on, this would make the migration to the new API easier. I could create devel/libstatgrab1 installing stuff as you describe, then work with each dependent port to migrate them to the new API, and finally remove devel/libstatgrab. But I do see a number of issues;

1. What do we do about the statgrab and saidar binaries? They'd conflict between the two versions. I don't want to end up with saidar0 and saidar1. Sadly there's no alternatives support in FreeBSD.
2. Everyone who has the old port installed for the binary utilities needs to explicitly install the new port.
3. More generally, every piece of code using libstatgrab needs to change the way they build to find the new headers and includes. Probably not too much of an issue if they use pkg-config, and I suppose they have to change their code for the new API too.
4. Are we realistically ever going to do a libstatgrab-2?

Definitely an idea worth exploring though.

[rehsack]

Am 27.09.2013 um 12:43 schrieb Tim Bishop notifications@github.com:

This is an interesting idea.

Yes, it is - but this can be easily done today with some options playing.
What would be the result:

• we could install several shared objects as intended and libtool manages it in the way it's invented:
  $PREFIX/lib/libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.9.0 -> libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.9 -> libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.10.0.0
  $PREFIX/lib/libstatgrab.so.10.0 -> libstatgrab.so.10.0.0
  ...
• we need to specify a dedicated include target, eg.
  $PREFIX/include/libstatgrab-0.90/libstatgrab.h
  $PREFIX/include/libstatgrab-1.0/libstatgrab.h
  ...
• Man-pages should always represent recent version

With my FreeBSD packagers hat on, this would make the migration to the new API easier. I could create devel/libstatgrab1 installing stuff as you describe, then work with each dependent port to migrate them to the new API, and finally remove devel/libstatgrab. But I do see a number of issues;

• What do we do about the statgrab and saidar binaries? They'd conflict between the two versions. I don't want to end up with saidar0 and saidar1. Sadly there's no alternatives support in FreeBSD.

Split it in two or more packages.
There is no reason to keep an old saidar - maybe an old statgrab (even if I think we're compatible on that level).

• Everyone who has the old port installed for the binary utilities needs to explicitly install the new port.

pkgsrc supports SUPERSEDES=old-pkg1 old-pkg2 …
Has ports a similar thing?

• More generally, every piece of code using libstatgrab needs to change the way they build to find the new headers and includes. Probably not too much of an issue if they use pkg-config, and I suppose they have to change their code for the new API too.

hacks.mk:
CFLAGS+= -I$PREFIX/include/libstatgrab-0.90/
LDFLAGS+= -Lstatgrab.9

(both could be expressed with suitable PKG_* flags)

• Are we realistically ever going to do a libstatgrab-2?

Surely. We're in the middle of 64->128 bit expansion, at least for storage.
Currently, there're no native 128 bit data types available, but this might
change or we decide always work with multipliers (like block sizes * blocks).
For long running systems with proper systems management API, 128-bit stats
might be available sooner than expected. Or we internally find a way to count
overflows …

The world is changing from dedicated hosts to [\w]aaS - we might have to deal
with stats from a farm/grid of machines instead of single machines in not to
distant future.

Storage technology is changing a lot. We're moving away from disks in local
machines to flash (which might evolve to "slower" virtual memory at some
point and superfluous disks in local machines. Then we have to deal with
disks in storage backends for what-ever-kind-of systems and care for much
more differentiating picture of memory stats (maybe obsoleting mem_stats and
swap_stats and improve vm_stats as successor?)

Definitely an idea worth exploring though.

We should very carefully think about the technology we choose to reach that goal.
But the goal is worth to be reached.

Cheers

Jens Rehsack
rehsack@gmail.com

[tdb]

On Fri, Sep 27, 2013 at 04:06:12AM -0700, Jens Rehsack wrote:

What would be the result:

• we could install several shared objects as intended and libtool
  manages it in the way it's invented:
  $PREFIX/lib/libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.9.0 -> libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.9 -> libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.10.0.0
  $PREFIX/lib/libstatgrab.so.10.0 -> libstatgrab.so.10.0.0

If we're going to do this, they should be distinctly separate libraries
probably.

$PREFIX/lib/libstatgrab-1.so.1.0.0
$PREFIX/lib/libstatgrab-2.so.1.0.0 (at some point in the future)

...

• we need to specify a dedicated include target, eg.
  $PREFIX/include/libstatgrab-0.90/libstatgrab.h
  $PREFIX/include/libstatgrab-1.0/libstatgrab.h

$PREFIX/include/libstatgrab-1/statgrab.h
$PREFIX/include/libstatgrab-2/statgrab.h

...

• Man-pages should always represent recent version

Ditto for binaries, I guess? I'm not sure what the normal thing to do is
in these cases.

• What do we do about the statgrab and saidar binaries? They'd
conflict between the two versions. I don't want to end up with saidar0
and saidar1. Sadly there's no alternatives support in FreeBSD.

Split it in two or more packages.

No, we don't split binaries off from libraries... that's the Linux way.

There is no reason to keep an old saidar - maybe an old statgrab (even
if I think we're compatible on that level).

Yes, I agree. The most recent version installs binaries and man pages,
previous versions only install the library and headers.

• Everyone who has the old port installed for the binary utilities
needs to explicitly install the new port.

pkgsrc supports SUPERSEDES=old-pkg1 old-pkg2 …
Has ports a similar thing?

We have a file which shows when a port is moved to another location,
which is commonly used in cases like this. But I'm not sure how well the
package tools handle that - maybe pkgng does a better job (I haven't
looked).

• More generally, every piece of code using libstatgrab needs to
change the way they build to find the new headers and includes.
Probably not too much of an issue if they use pkg-config, and I suppose
they have to change their code for the new API too.

hacks.mk:
CFLAGS+= -I$PREFIX/include/libstatgrab-0.90/
LDFLAGS+= -Lstatgrab.9
(both could be expressed with suitable PKG_* flags)

Something like that. Probably -llibstatgrab-1 actually? Anyway, all I
mean, is all the people that may have done something with libstatgrab by
hand will need to change their build tools. Probably not a huge issue.

[Snip points about 2.0 - looks like it may happen!]

This does generally sound like a good idea. We should resolve #24 first
though, then look at this.

Tim.

Tim Bishop
http://www.bishnet.net/tim/
PGP Key: 0x6C226B37FDF38D55

[tdb]

A point I didn't make. The versioning is really about the API. So when 1.0 is released the API doesn't change in any incompatible way. I guess it's possible to make changes that are compatible - extra functions, for example. ABI changes are handled by the shared library version, and I guess we don't worry about breaking that?

For incompatible API changes 2.0 would be needed.

Think that's what I implied, but wanted to be explicit.

[rehsack]

Am 27.09.2013 um 16:42 schrieb Tim Bishop notifications@github.com:

On Fri, Sep 27, 2013 at 04:06:12AM -0700, Jens Rehsack wrote:

What would be the result:

• we could install several shared objects as intended and libtool
  manages it in the way it's invented:
  $PREFIX/lib/libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.9.0 -> libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.9 -> libstatgrab.so.9.0.0
  $PREFIX/lib/libstatgrab.so.10.0.0
  $PREFIX/lib/libstatgrab.so.10.0 -> libstatgrab.so.10.0.0

If we're going to do this, they should be distinctly separate libraries
probably.

$PREFIX/lib/libstatgrab-1.so.1.0.0
$PREFIX/lib/libstatgrab-2.so.1.0.0 (at some point in the future)

This is a Linux way. Shared library versioning works great, why
adding extra information? The libstatgrab-1.pc and libstatgrab-2.pc
could solve all extra things above.

...

• we need to specify a dedicated include target, eg.
  $PREFIX/include/libstatgrab-0.90/libstatgrab.h
  $PREFIX/include/libstatgrab-1.0/libstatgrab.h

$PREFIX/include/libstatgrab-1/statgrab.h
$PREFIX/include/libstatgrab-2/statgrab.h

...

• Man-pages should always represent recent version

Ditto for binaries, I guess? I'm not sure what the normal thing to do is
in these cases.

• What do we do about the statgrab and saidar binaries? They'd
conflict between the two versions. I don't want to end up with saidar0
and saidar1. Sadly there's no alternatives support in FreeBSD.

Split it in two or more packages.

No, we don't split binaries off from libraries... that's the Linux way.

When it's reasonable (and it looks in this special case it is),
then we do the same thing in pkgsrc to allow parallel installation
of different software (e.g. net/samba*).

There is no reason to keep an old saidar - maybe an old statgrab (even
if I think we're compatible on that level).

Yes, I agree. The most recent version installs binaries and man pages,
previous versions only install the library and headers.

• Everyone who has the old port installed for the binary utilities
needs to explicitly install the new port.

pkgsrc supports SUPERSEDES=old-pkg1 old-pkg2 …
Has ports a similar thing?

We have a file which shows when a port is moved to another location,
which is commonly used in cases like this. But I'm not sure how well the
package tools handle that - maybe pkgng does a better job (I haven't
looked).

• More generally, every piece of code using libstatgrab needs to
change the way they build to find the new headers and includes.
Probably not too much of an issue if they use pkg-config, and I suppose
they have to change their code for the new API too.

hacks.mk:
CFLAGS+= -I$PREFIX/include/libstatgrab-0.90/
LDFLAGS+= -Lstatgrab.9
(both could be expressed with suitable PKG_* flags)

Something like that. Probably -llibstatgrab-1 actually? Anyway, all I
mean, is all the people that may have done something with libstatgrab by
hand will need to change their build tools. Probably not a huge issue.

Exactly. We only had to make a decision if we rely on what's the common
way or if we want to follow the API/ABI breakers in Linux world.

I prefer not breaking to much and stay on what libtool and alike allow
easily (read: no include/libstatgrab-1/ by default).

Cheers

Jens Rehsack
rehsack@gmail.com

[tdb]

On Fri, Sep 27, 2013 at 07:57:53AM -0700, Jens Rehsack wrote:

This is a Linux way. Shared library versioning works great, why
adding extra information? The libstatgrab-1.pc and libstatgrab-2.pc
could solve all extra things above.

I prefer not breaking to much and stay on what libtool and alike allow
easily (read: no include/libstatgrab-1/ by default).

Did you read the page referenced in the original issue?

http://ometer.com/parallel.html

It highlights the issue.

We can't parallel install two copies of libstatgrab unless they have
different names. The only reason to install parallel copies is because
their APIs are different such that applications can only support one or
the other.

Tim.

Tim Bishop
http://www.bishnet.net/tim/
PGP Key: 0x6C226B37FDF38D55

[tdb]

I've got some feedback on this issued, based on my work updating libstatgrab to 0.90 in FreeBSD.

The problem for me was that there are a number of consumers of libstatgrab in FreeBSD that haven't yet been updated to the new API. This is fairly straightforward to sort out for applications that make one or two function calls, but it's much harder for language bindings. Therefore I needed to have both the old and new API libstatgrab libraries installed in parallel.

These are the options I went through, in order.

Installing the libraries in the same directory

So my first attempt just relied on the fact that the shared libraries have different versions. There's no reason they can't sit side-by-side in the normal lib directory. For runtime stuff this is fine. If you assume the consuming binaries are built in a clean environment with only one version of libstatgrab installed, they be linked against the correct library and it'll work fine.

This is fine until you want to install them both side-by-side for building stuff, headers and all. It's not that straightforward to control the linker to make sure it picks the right one at build time.

Installing in to a separate directory

So I next tried putting the old API library in lib/libstatgrab-0/ and the headers in include/libstatgrab-0. This works fine, you pass in the relevant -I and -L flags at build time and it picks up the correct files. No code in the consumer needs changing. You need to modify the runtime linker (or use -R) so it can find the library at runtime, but that's fine.

The problem comes when trying to get the -I and -L flags in the right place in the compiler line. If you're doing it by hand it's fine, but working with a consumer that has an exotic build system that's tricky to control and it becomes tough. At least one package (ruby stuff, maybe) kept putting the main system directories before the ones I'd specified.

Installing with a different name

Next I patched the old libstatgrab to install the library as libstatgrab0.so and the header as statgrab0.h (with hindsight, that could have been libstatgrab0/statgrab.h, it doesn't really matter). Then it installs side-by-side and old consuming applications just need to be tweaked to include the right header and link the right library. There's no confusion over which one they're getting.

This last approach is similar in nature to what was originally suggested, just with the emphasis flipped. The old version changes, and the current version keeps the normal and expected naming. The idea being that the old version will eventually disappear.

Both ports are available to view here:

http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/
http://svnweb.freebsd.org/ports/head/devel/libstatgrab/

I decided that the tools (statgrab, saidar, etc) and manual pages should come from the main port, and that the old compatibility port should only install the header and library files.

I'm not sure what to suggest for libstatgrab going forward. Hopefully this won't happen too often (we should try to keep such API changes to a minimum and group them together for major releases) either.

I can see some benefit in consistent behaviour going forward. If 0.90 had been released with headers in include/libstatgrab-1/ and the library as libstatgrab1.so, any updated consumers of libstatgrab would already have been tweaked accordingly. So there'd be less work as a package maintainer or end user getting things compiled.

But it also creates more churn with applications having to change their include lines and build systems to find the new libraries.

If any third parties are reading this I'd love to hear your views.

[tdb]

Bumping this issue to 1.0. In my mind that's the point by which we need to make a decision one way or the other regarding parallel installation.. I'm happy we've done enough for now with these pre-1.0 releases.

[rehsack]

The caption is misleading: you proved that parallel installation works. What this topic covers is parallel development (can libstatgrab-2 while libstatgrab-1 is there and i-scream develops on both).

I strongly vote against that - we don't have the manpower.

[tdb]

No, I think you're misunderstanding. It's about parallel installation, not development. I've proved it works by hacking the code. What this issue proposed is that we do the changes in libstatgrab so that the code doesn't need hacking. So when there's next an incompatible API change we make sure things install in libstatgrab-2 (or whatever the specifics are) so that it doesn't conflict with the previous version. That would then avoid the hacks I needed to do in the FreeBSD port.

I don't think it's proposing we maintain separate branches and backport fixes etc.

[rehsack]

You didn't need to hack libstatgrab, do you? You needed to hack depending software which wasn't pkg-config aware (so probably ancient itself and not maintained anymore).

The proposed strategy in http://ometer.com/parallel.html is for parallel maintaining - which is kind of parallel development. I think I have to re-read your explanation what you finally did in detail...

[tdb]

Yes, I did need to hack libstatgrab to get it to install with different names. Minimally, but still had to do it:

http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/Makefile?revision=353876&view=markup (two post- targets)
http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/files/patch-Makefile.in?revision=353876&view=markup
http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/files/patch-libstatgrab.pc.in?revision=353876&view=markup
http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/files/patch-src__libstatgrab__Makefile.in?revision=353876&view=markup

All those changes are about renaming the library, the header and the pkg-config file. Depending software, whether pkg-config or not, needed hacking to change the include and pkg-config lookups.

The strategy on that page is about parallel installation. So you can install two versions with different APIs side-by-side. Not every single version, of course, just those with incompatible APIs where you might need both installed. Yes, this could then of course lead to parallel development, but it doesn't have to...

[rehsack]

Am 13.06.2014 um 18:05 schrieb Tim Bishop notifications@github.com:

Yes, I did need to hack libstatgrab to get it to install with different names. Minimally, but still had to do it:

http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/Makefile?revision=353876&view=markup (two post- targets)
http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/files/patch-Makefile.in?revision=353876&view=markup
http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/files/patch-libstatgrab.pc.in?revision=353876&view=markup
http://svnweb.freebsd.org/ports/head/devel/libstatgrab0/files/patch-src__libstatgrab__Makefile.in?revision=353876&view=markup< /a>

All those changes are about renaming the library, the header and the pkg-config file. Depending software, whether pkg-config or not, needed hacking to change the include and pkg-config lookups.

The strategy on that page is about parallel installation. So you can install two versions with different APIs side-by-side. Not every single version, of course, just those with incompatible APIs where you might need both installed. Yes, this could then of course lead to parallel development, but it doesn't have to...

Reviewing your changes (and I think, some of them wouldn't be necessary when --includedir and --libdir would have been used and depending software would search those paths before standard paths...) I think, adding active support for above renaming actions would satisfy the requirement.

Usually, PKG_CONFIG_* macros in autoconf check for name[]_CFLAGS/name[]_LIBS (as we do for log4cplus_CFLAGS/log4cplus_LIBS). So properly written configure scripts won't need any patching.

I don't remember why it wasn't possible to install libstatgrab-0.17 into $prefix/include/lsg017 and $prefix/lib/lsg017.

Cheers

Jens Rehsack
rehsack@gmail.com

[tdb]

On Fri, Jun 13, 2014 at 09:30:20AM -0700, Jens Rehsack wrote:

I don't remember why it wasn't possible to install libstatgrab-0.17
into $prefix/include/lsg017 and $prefix/lib/lsg017.

Then you need to re-read my longish explanation above :-) In summary,
you can't always control the build system to ensure that the above
directories are searched first.

By renaming header to statgrab0.h and library to libstatgrab0.so they
can sit in normal prefixes without problem.

The idea (if this was done properly) is that when we changed the API we
should have also changed libstatgrab to install the header as
statgrab1.h and the library as libstatgrab1.so. Then as part of people
porting their code to the new API they change their #include lines and
linker flags to the new names.

[rehsack]

Am 13.06.2014 um 18:37 schrieb Tim Bishop notifications@github.com:

On Fri, Jun 13, 2014 at 09:30:20AM -0700, Jens Rehsack wrote:

I don't remember why it wasn't possible to install libstatgrab-0.17
into $prefix/include/lsg017 and $prefix/lib/lsg017.

Then you need to re-read my longish explanation above :-) In summary,
you can't always control the build system to ensure that the above
directories are searched first.

Which sounds to me more as a bug in the build system. A better workaround
than renaming the library would be to use a different subdirectory for
all packaged versions. So no default include path contains a statgrab.h.

By renaming header to statgrab0.h and library to libstatgrab0.so they
can sit in normal prefixes without problem.

Call it resign :)

The idea (if this was done properly) is that when we changed the API we
should have also changed libstatgrab to install the header as
statgrab1.h and the library as libstatgrab1.so. Then as part of people
porting their code to the new API they change their #include lines and
linker flags to the new names.

I think this solution is bad at all. I allows broken software being used
for ages because there is no need to update.

gtk can do that - because the have dozens of full-time developers. They
decided to support gtk-1 and gtk-2 in parallel and later gtk-2 and gtk-3.

We don't.

So what we should develop is a solution which helps installing several
libstatgrab versions. And it's most likely not our i-scream job but our
job in ports/pkgsrc :)

Cheers

Jens Rehsack
rehsack@gmail.com

[tdb]

On Fri, Jun 13, 2014 at 09:44:05AM -0700, Jens Rehsack wrote:

Am 13.06.2014 um 18:37 schrieb Tim Bishop notifications@github.com:

On Fri, Jun 13, 2014 at 09:30:20AM -0700, Jens Rehsack wrote:

I don't remember why it wasn't possible to install libstatgrab-0.17
into $prefix/include/lsg017 and $prefix/lib/lsg017.

Then you need to re-read my longish explanation above :-) In summary,
you can't always control the build system to ensure that the above
directories are searched first.

Which sounds to me more as a bug in the build system.

Maybe, but we can't fix all build systems :-)

A better workaround than renaming the library would be to use a
different subdirectory for all packaged versions. So no default
include path contains a statgrab.h.

No, not for all packaged version, just ones with incompatible APIs.
Otherwise it turns in to a nightmare to maintain. Even after 0.91 is
released there's still only two different versions (0.17 and 0.90+).

But yes, nothing in the default include path would go some way to fixing
it, I just don't particularly like it. You have to mess with the runtime
linker too.

And in practice, what's the difference? Does it matter whether you
rename it or put it in another directory? As a consumer you're either
changing -I and -L flags, or changing -l and #include. You still have to
do something different to use the different API versions.

The idea (if this was done properly) is that when we changed the API
we should have also changed libstatgrab to install the header as
statgrab1.h and the library as libstatgrab1.so. Then as part of
people porting their code to the new API they change their #include
lines and linker flags to the new names.

I think this solution is bad at all. I allows broken software being
used for ages because there is no need to update.

Not at all. It allows users to use both old and new software at the
same time. Pretending that every package will get updated the instant we
change API is silly... it just won't happen. Even someone trying to
update their own application to the new API might want both installed at
the same time.

gtk can do that - because the have dozens of full-time developers. They
decided to support gtk-1 and gtk-2 in parallel and later gtk-2 and
gtk-3.

You're again mixing up parallel development and support with parallel
installation. They're not the same thing. I never intend to change the
code in libstatgrab 0.17, but I made a separate port for it on FreeBSD
because users may need it.

It would have made my life a lot easier if 0.90+ had installed headers
and libraries in a way that doesn't conflict with 0.17, which is what
this issue was originally about.

[rehsack]

Am 13.06.2014 um 19:04 schrieb Tim Bishop notifications@github.com:

On Fri, Jun 13, 2014 at 09:44:05AM -0700, Jens Rehsack wrote:

Am 13.06.2014 um 18:37 schrieb Tim Bishop notifications@github.com:

On Fri, Jun 13, 2014 at 09:30:20AM -0700, Jens Rehsack wrote:

I don't remember why it wasn't possible to install libstatgrab-0.17
into $prefix/include/lsg017 and $prefix/lib/lsg017.

Then you need to re-read my longish explanation above :-) In summary,
you can't always control the build system to ensure that the above
directories are searched first.

Which sounds to me more as a bug in the build system.

Maybe, but we can't fix all build systems :-)

We had a similar discussion about RPATH in Linux and a weird clang
installation, too ... - and we decided we're not responsible
for weird build systems. So blaming the build system is a reasonable
fix, showing 1-2 ways to workaround is impressive customer service.

A better workaround than renaming the library would be to use a
different subdirectory for all packaged versions. So no default
include path contains a statgrab.h.

No, not for all packaged version, just ones with incompatible APIs.
Otherwise it turns in to a nightmare to maintain. Even after 0.91 is
released there's still only two different versions (0.17 and 0.90+).

But yes, nothing in the default include path would go some way to fixing
it, I just don't particularly like it. You have to mess with the runtime
linker too.

Same same, but different - use lib subdirectory :)

And in practice, what's the difference? Does it matter whether you
rename it or put it in another directory? As a consumer you're either
changing -I and -L flags, or changing -l and #include. You still have to
do something different to use the different API versions.

Renaming has to happen at the source (read: i-scream had to deploy it
distinguish named). Relocating can be done by packagers who need to.

IIRC invented FreeBSD (portupgrade?) the idea of lib/compat - which is
always prepended. Could be also a nice place - talk to ports infrastructure
guys ...

The idea (if this was done properly) is that when we changed the API
we should have also changed libstatgrab to install the header as
statgrab1.h and the library as libstatgrab1.so. Then as part of
people porting their code to the new API they change their #include
lines and linker flags to the new names.

I think this solution is bad at all. I allows broken software being
used for ages because there is no need to update.

Not at all. It allows users to use both old and new software at the
same time. Pretending that every package will get updated the instant we
change API is silly... it just won't happen. Even someone trying to
update their own application to the new API might want both installed at
the same time.

I told you send me all software at the time I worked on related stuff in
Perl and pkgsrc and I patch them (beside pystatgrab). But limited tuits
led to ETIMEDOUT :(

I would prefer updating upstream - and where not possible, use parallel
subdirectories instead of increasing name parts.

gtk can do that - because the have dozens of full-time developers. They
decided to support gtk-1 and gtk-2 in parallel and later gtk-2 and
gtk-3.

You're again mixing up parallel development and support with parallel
installation. They're not the same thing. I never intend to change the
code in libstatgrab 0.17, but I made a separate port for it on FreeBSD
because users may need it.

It would have made my life a lot easier if 0.90+ had installed headers
and libraries in a way that doesn't conflict with 0.17, which is what
this issue was originally about.

But there is already - you just decided not to walk that way. It's a fair
interim step to use 2 parallel directories (include/0.90 vs. include/0.17).
You probably run into it again for 0.91? I wouldn't expect, but API isn't
compatible.

Cheers

Jens Rehsack
rehsack@gmail.com