[ITP] cairomm, as replacement for cairomm1.0

[ITP] cairomm, as replacement for cairomm1.0

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

cygport file attached.  I've bumped the version to 1.12.2, which is the latest 
stable upstream release.  Upstream has actually released 1.15.5, but the News 
file says it's unstable and recommends that distros not package it.

I'm proposing an unversioned source package cairomm, as well as unversioned 
devel and doc packages.  This is what we do with many library packages, and it 
is consistent with Fedora's packaging.

It will also ease future maintenance.  I've looked at the upstream git repo, and 
there's been an ABI change from 1.0 to 1.14 and then to 1.16.  It would be 
annoying to have to create a new Cygwin package for each such change.

I'll wait for Yaakov to weigh in on this before I upload anything.

The change might require some manual intervention on sourceware, to rename the 
existing cairomm1.0 directory to cairomm.

Ken

[-- Attachment #2: cairomm.cygport --]
[-- Type: text/plain, Size: 964 bytes --]

inherit gtkmm

NAME="cairomm"
VERSION=1.12.2
RELEASE=1
CATEGORY="Libs"
SUMMARY="C++ bindings for the cairo graphics engine"
DESCRIPTION="cairomm is a C++ wrapper for the cairo graphics library.  It offers
all the power of cairo with an interface familiar to C++ developers,
including use of the Standard Template Library where it makes sense."
HOMEPAGE="http://cairographics.org/cairomm"
SRC_URI="http://cairographics.org/releases/cairomm-${VERSION}.tar.gz"
SRC_DIR="cairomm-${VERSION}"
PATCH_URI="1.12.0-std-c++11.patch"

abi=1.0

PKG_NAMES="lib${NAME}${abi}_1 lib${NAME}-devel lib${NAME}-doc"
libcairomm1_0_1_CONTENTS="usr/bin/cygcairomm-${abi}-1.dll usr/share/doc/${NAME}/"
libcairomm_devel_CONTENTS="usr/include/ usr/lib/"
libcairomm_devel_OBSOLETES="libcairomm1.0-devel"
libcairomm_doc_CONTENTS="usr/share/devhelp/ usr/share/doc/cairomm-${abi}/"
libcairomm_doc_OBSOLETES="libcairomm1.0-doc"

DIFF_EXCLUDES="cairommconfig.h"

BUILD_REQUIRES="libsigc2.0-devel"

Re: [ITP] cairomm, as replacement for cairomm1.0

[Marco Atzeri]

On 15.05.2020 17:30, Ken Brown via Cygwin-apps wrote:
> cygport file attached.  I've bumped the version to 1.12.2, which is the 
> latest stable upstream release.  Upstream has actually released 1.15.5, 
> but the News file says it's unstable and recommends that distros not 
> package it.
> 
> I'm proposing an unversioned source package cairomm, as well as 
> unversioned devel and doc packages.  This is what we do with many 
> library packages, and it is consistent with Fedora's packaging.
> 
> It will also ease future maintenance.  I've looked at the upstream git 
> repo, and there's been an ABI change from 1.0 to 1.14 and then to 1.16.  
> It would be annoying to have to create a new Cygwin package for each 
> such change.
> 
> I'll wait for Yaakov to weigh in on this before I upload anything.
> 
> The change might require some manual intervention on sourceware, to 
> rename the existing cairomm1.0 directory to cairomm.
> 
> Ken

added to the package list and assigned cairomm1.0 to you
as will make any package movement easier

Regards
Marco

Re: [ITP] cairomm, as replacement for cairomm1.0

[Marco Atzeri]

On 22.05.2020 20:58, Ken Brown wrote:
> On 5/15/2020 1:42 PM, Marco Atzeri via Cygwin-apps wrote:
>> On 15.05.2020 17:30, Ken Brown via Cygwin-apps wrote:
>>> cygport file attached.  I've bumped the version to 1.12.2, which is 
>>> the latest stable upstream release.  Upstream has actually released 
>>> 1.15.5, but the News file says it's unstable and recommends that 
>>> distros not package it.
>>>
>>> I'm proposing an unversioned source package cairomm, as well as 
>>> unversioned devel and doc packages.  This is what we do with many 
>>> library packages, and it is consistent with Fedora's packaging.
>>>
>>> It will also ease future maintenance.  I've looked at the upstream 
>>> git repo, and there's been an ABI change from 1.0 to 1.14 and then to 
>>> 1.16. It would be annoying to have to create a new Cygwin package for 
>>> each such change.
>>>
>>> I'll wait for Yaakov to weigh in on this before I upload anything.
>>>
>>> The change might require some manual intervention on sourceware, to 
>>> rename the existing cairomm1.0 directory to cairomm.
>>>
>>> Ken
>>
>> added to the package list and assigned cairomm1.0 to you
>> as will make any package movement easier
> 
> I've decided to hold off on this for now.  There's no real need to 
> update cairomm1.0 at the moment, so any packaging change can wait until 
> there's a good reason for it.
> 
> Ken

noted

Re: [ITP] cairomm, as replacement for cairomm1.0

[Yaakov Selkowitz]

On Fri, 2020-05-15 at 11:30 -0400, Ken Brown via Cygwin-apps wrote:
> cygport file attached.  I've bumped the version to 1.12.2, which is the latest 
> stable upstream release.  Upstream has actually released 1.15.5, but the News 
> file says it's unstable and recommends that distros not package it.

GNOME still uses the development/stable odd/even-minor versioning
scheme (like the Linux kernel used to long ago).

> I'm proposing an unversioned source package cairomm, as well as unversioned 
> devel and doc packages.  This is what we do with many library packages, and it 
> is consistent with Fedora's packaging.

I would strongly recommend against this rename, and in fact it is
Fedora that might have to adapt, because:

> It will also ease future maintenance.  I've looked at the upstream git repo, and 
> there's been an ABI change from 1.0 to 1.14 and then to 1.16.  It would be 
> annoying to have to create a new Cygwin package for each such change.

1.0 isn't an ABI version, it's an API version, and like many GNOME
libraries, the GTKmm bindings carry the API version in all its
directories and library names, so that multiple versions may be
installed in parallel.  (Any given application can use only one stack,
but you can have some apps using the new and other apps using the
current until they update.)  Cairo is relatively newer than the rest of
the stack, and so it hasn't been through this process before, but the
others have.

(That's they the current versions are e.g. 2.4 instead of 2.0, because
the upcoming versions will be the third or even fourth API version for
most of these packages; the previous versions were obsolete a LONG time
ago.  In fact, just remembering going through this last time, and then
realizing how long ago that was, isn't making me feel any younger. :-)

With the introduction of libsigc-3.0, this and the rest of the GTKmm
stack is going to undergo a(nother) API version bump, with the new
versions should be parallel installable with the current:

Current: libsigc-2.0, glibmm-2.4, cairomm-1.0, atkmm-1.6, pangomm-1.4,
gtkmm-2.4 and -3.0, 

New: libsigc-3.0, glibmm-2.66, cairomm-1.16, atkmm-2.30, pangomm-2.44,
gtkmm-4.0, etc.

We're going to want to be able to have both for a period of time, and
of course this could always happen again in the future.  That's why
they always been, and should remain, versioned.

--
Yaakov

Re: [ITP] cairomm, as replacement for cairomm1.0

[Ken Brown]

On 5/25/2020 11:31 PM, Yaakov Selkowitz wrote:
> On Fri, 2020-05-15 at 11:30 -0400, Ken Brown via Cygwin-apps wrote:
>> cygport file attached.  I've bumped the version to 1.12.2, which is the latest
>> stable upstream release.  Upstream has actually released 1.15.5, but the News
>> file says it's unstable and recommends that distros not package it.
> 
> GNOME still uses the development/stable odd/even-minor versioning
> scheme (like the Linux kernel used to long ago).
> 
>> I'm proposing an unversioned source package cairomm, as well as unversioned
>> devel and doc packages.  This is what we do with many library packages, and it
>> is consistent with Fedora's packaging.
> 
> I would strongly recommend against this rename, and in fact it is
> Fedora that might have to adapt, because:
> 
>> It will also ease future maintenance.  I've looked at the upstream git repo, and
>> there's been an ABI change from 1.0 to 1.14 and then to 1.16.  It would be
>> annoying to have to create a new Cygwin package for each such change.
> 
> 1.0 isn't an ABI version, it's an API version, and like many GNOME
> libraries, the GTKmm bindings carry the API version in all its
> directories and library names, so that multiple versions may be
> installed in parallel.  (Any given application can use only one stack,
> but you can have some apps using the new and other apps using the
> current until they update.)  Cairo is relatively newer than the rest of
> the stack, and so it hasn't been through this process before, but the
> others have.
> 
> (That's they the current versions are e.g. 2.4 instead of 2.0, because
> the upcoming versions will be the third or even fourth API version for
> most of these packages; the previous versions were obsolete a LONG time
> ago.  In fact, just remembering going through this last time, and then
> realizing how long ago that was, isn't making me feel any younger. :-)
> 
> With the introduction of libsigc-3.0, this and the rest of the GTKmm
> stack is going to undergo a(nother) API version bump, with the new
> versions should be parallel installable with the current:
> 
> Current: libsigc-2.0, glibmm-2.4, cairomm-1.0, atkmm-1.6, pangomm-1.4,
> gtkmm-2.4 and -3.0,
> 
> New: libsigc-3.0, glibmm-2.66, cairomm-1.16, atkmm-2.30, pangomm-2.44,
> gtkmm-4.0, etc.
> 
> We're going to want to be able to have both for a period of time, and
> of course this could always happen again in the future.  That's why
> they always been, and should remain, versioned.

I'm convinced.  Thanks for the detailed explanation.

Ken