guile-gtk-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Some thoughts on Debian packaging of guile-gnome


From: Andreas Rottmann
Subject: Some thoughts on Debian packaging of guile-gnome
Date: Mon, 21 Jun 2004 12:15:20 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Hi!

[ Cc'ing address@hidden, since people there might have
  suggestions ]

Now that G-Wrap 1.9.0 and Debian packages of it are within reach, I
thought I'd think a bit about packing guile-gnome. It would be easiest
for me to have only one source package, i.e. build upon a "big
tarball" release, which we could offer additionally the individual
tarballs. Building from a single source package would make things
really simpler on the Debian side.

This, however, imposes some issues for versioning: If we release a
guile-gnome "big tarball" versioned 2.7.0, all (Debian) binary
packages built from it will also have version 2.7.0, which is not
ideal since according to the Platform Binding Rules:

,----
| Try to use the same major.minor numbers that GNOME uses. For instance,
| GTK+ 2.4.x would be wrapped by gtkmm 2.4.x, and libgnomeui 2.6.x would
| be wrapped by libgnomeuimm 2.6.x.
`----

[ Given the recent discussion (on address@hidden) about GTK+
  not releasing for GNOME 2.8 and the resulting version/API
  implications, I wonder if the above rule even makes that much sense
  (i.e. wouln't it be better for language bindings to follow their own
  versioning scheme). ]

This will mean that for the GTK+ bindings, the Debian packages'
versions will differ from upstream; i.e.

binding tarballs: guile-glib-2.5.0.tar.gz, guile-gtk-2.5.0.tar.gz
                  guile-libgnome-2.7.0.tar.gz
big tarball:      guile-gnome-2.7.0.tar.gz
Debian packages:  guile-glib_2.7.0, ...
                             ^^^^^

This is unfortunate. I can think of the following choices:

1) Use more than one source package. I'd like to avoid this, since it
   complicates packaging.

2) Don't care about the version mismatch.

3) Use a different versioning scheme for the big tarball, like
   starting from 0.7.0. This will mean again a version mismatch, but
   one is less likely to confuse the low numbers with the GNOME
   versions; also, we could increase major and minor numbers along
   with the GNOME platform; i.e. GNOME 2.7 -> 0.7, GNOME 2.8 -> 0.8,
   GNOME 3.0 -> 1.0. This is (I think) similiar to what GStreamer
   does.

I lean towards 3). Thoughts?

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth




reply via email to

[Prev in Thread] Current Thread [Next in Thread]