[Gfs-devel] Packaging gerris for Fedora and EPEL: questions
Jonathan Underwood
I am in the process of packaging gerris and gfusion for the Fedora and
EPEL repositories and have some questions.
(1) Fedora/EPEL already has packages of the GTS library, version 0.76
(from 2006) + a couple of patches, from the gts.sourceforge.net
website. Gerris seems to have forked GTS and is continuing developing
it. Should gerris now be regarded as the upstream for GTS? For info, I
have opened a bug in the redhat/fedora bugzilla on this requesting the
package maintainer update to the gerris version of GTS. He has
expressed a number of concerns. Some clarification and help with his
concerns from you guys would be very helpful. The bugzilla is
https://bugzilla.redhat.com/show_bug.cgi?id=759319
(2) The current method of release management you guys are using is
slightly difficult from a downstream packaging perspective. At present
you're dropping snapshots of the development tree onto the website as
unversioned tarballs. It would help tremendously if you could (i)
include a version number in the tarball name; and (ii) properly
indicate with the versioning and SO name of the libraries whenever the
ABI changes. For example, at present, it's unclear if your GTS is ABI
compatible with the 0.76 ABI.
I'm very keen to get your work packaged up and available to Fedora and
EPEL users, so any help will be very much appreciated.
Cheers,
Jonathan.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel
Stephane Popinet
> I am in the process of packaging gerris and gfusion for the Fedora and
> EPEL repositories and have some questions.
Sounds good. Thanks in advance for this.
> Gerris seems to have forked GTS and is continuing developing
> it. Should gerris now be regarded as the upstream for GTS?
I am also the original author of GTS. So, yes the "official" GTS darcs
repositories and packages are now at:
http://gerris.dalembert.upmc.fr/darcs/gts-stable
the corresponding tarball is still at:
http://gts.sourceforge.net/tarballs/
but is always synchronised with the darcs repository.
These links have also been added at gts.sf.net
> (2) The current method of release management you guys are using is
> slightly difficult from a downstream packaging perspective. At present
> you're dropping snapshots of the development tree onto the website as
> unversioned tarballs.
Hmm I am not sure I understand this, the current tarball at:
http://gts.sourceforge.net/tarballs/gts-snapshot-111025.tar.gz
so does include a version number? I think you are referring to:
http://gts.sf.net/gts-snapshot.tar.gz
which is just a symbolic link to the latest tarball.
> (ii) properly
> indicate with the versioning and SO name of the libraries whenever the
> ABI changes. For example, at present, it's unclear if your GTS is ABI
> compatible with the 0.76 ABI.
Yes, I agree but maintaining ABI compatibility is difficult (for
Gerris which is evolving quickly) and is not something I put much
effort into (although I try to maintain API compatibility as much as
possible). For GTS the current version should be ABI compatible with
0.7.6 and I don't see that changing much in the future as there is
little development going on in GTS.
For Gerris, it is safer to assume that any new version is not ABI
compatible with the previous one.
> I'm very keen to get your work packaged up and available to Fedora and
> EPEL users, so any help will be very much appreciated.
Do not hesitate to ask if there is anything I can do to help.
cheers
Stephane
Jonathan Underwood
[snip]
> I am also the original author of GTS. So, yes the "official" GTS darcs
> repositories and packages are now at:
>
> http://gerris.dalembert.upmc.fr/darcs/gts-stable
>
> the corresponding tarball is still at:
>
> http://gts.sourceforge.net/tarballs/
>
> but is always synchronised with the darcs repository.
>
> These links have also been added at gts.sf.net
>
OK, thanks for the clarification, that will help a lot.
>> (2) The current method of release management you guys are using is
>> slightly difficult from a downstream packaging perspective. At present
>> you're dropping snapshots of the development tree onto the website as
>> unversioned tarballs.
>
> Hmm I am not sure I understand this, the current tarball at:
>
> http://gts.sourceforge.net/tarballs/gts-snapshot-111025.tar.gz
>
> so does include a version number? I think you are referring to:
>
> http://gts.sf.net/gts-snapshot.tar.gz
>
Ah, yes. I had not spotted the versioned tarballs - the second link
results in downloading a tarball with the name of the link, rather
than the versioned tarball it links to. Now I know there are versioned
tarballs, I'll use them - thanks for pointing me in the right
direction.
> Yes, I agree but maintaining ABI compatibility is difficult (for
> Gerris which is evolving quickly) and is not something I put much
> effort into (although I try to maintain API compatibility as much as
> possible). For GTS the current version should be ABI compatible with
> 0.7.6 and I don't see that changing much in the future as there is
> little development going on in GTS.
>
OK, so we'll assume the ABI of gerris is unstable for now, but that
the GTS SOname will be bumped for GTS if the ABI changes - that's
helpful as there is at least one other package built against GTS in
the repositories already.
> For Gerris, it is safer to assume that any new version is not ABI
> compatible with the previous one.
>
OK.
Thanks for the reply Stephane.
Cheers,
Jonathan