[ITP] cairomm, as replacement for cairomm1.0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[ITP] cairomm, as replacement for cairomm1.0

cygwin-apps mailing list
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

cairomm.cygport (991 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

cygwin-apps mailing list
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
Reply | Threaded
Open this post in threaded view
|

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

cygwin-apps mailing list
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
Reply | Threaded
Open this post in threaded view
|

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

Yaakov Selkowitz
In reply to this post by cygwin-apps mailing list
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


Reply | Threaded
Open this post in threaded view
|

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

cygwin-apps mailing list
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