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

Re: Questions for Debian packages for GT.M



[Sorry for longer quote of this formerly private discussion]

On Tue, Aug 11, 2009 at 03:18:15PM -0400, K.S. Bhaskar wrote:
> On Fri, 7 Aug 2009, K.S. Bhaskar wrote:
> 
> > Better late than never,
> 
> This is *really* nice because according to an announcement on the Debian
> Med
> list [1] I started thinking *this morning* that having GT.M in Debian would
> be a nice to have goal for Debian Med.  So your mail comes right in time
> (at
> least regarding my institutes mailbox which I was not able to read this
> weekend).
> 
> > I am trying to understand Debian packaging with a
> > view to creating a Debian binary package for GT.M by the end of August
> (if
> > not sooner).  A source package will probably take longer because the way
> GT.M
> > is built is a little unconventional, but a binary package is a good place
> to
> > start.
> 
> Hmmm,  I have to admit that I never builded binary packages without having
> the source properly prepared and so the docs about packaging will be
> perhaps
> not so helpful and the starting point is perhaps not the optimal point to
> start from - but I agree that we probably have no better chance to start
> with this.  I would strongly suggest to move all the discussion to the
> Debian Med mailing list [2] because once it comes to the point where we
> will have to convince ftpmaster to let GT.M through it will be helpful to
> direct him to a public discussion.
> 
> [KSB] Please do post to the list.  I have just subscribed to the debian-med
> list and will participate in discussion (as long as the bandwidth is not too
> high).

The traffic on Debian Med list is not exceptionally high.
 
> And yes, I would really try to reach official inclusion of GT.M into Debian
> because only this gurantees all the advantages you can gain.

Great.

> > Some questions, please:
> >
> > 1. We have the name "gtm" from lanana.org.  It is not clear to me from
> the
> > rules at lanana.org whether this means I can put GT.M in /opt/gtm or
> > /opt/lsb-gtm.
> 
> If you want to build a package confirming to Debian policy then
> architecture
> specific files should go to /usr/lib/gtm and architecture independant files
> go to /usr/share/gtm.  Everything else will not be accepted by ftpmaster.
> 
> [KSB] According to http://www.pathname.com/fhs/pub/fhs-2.3.html#
> OPTADDONAPPLICATIONSOFTWAREPACKAGES
> 
> /opt is reserved for the installation of add-on application software
> packages.
> 
> A package to be installed in /opt must locate its static files in a
> separate /opt/<package> or /opt/<provider> directory tree, where <package>
> is a name that describes the software package and <provider> is the
> provider's LANANA registered name.
> 
> Since GT.M is an optional add-on application software package, doesn't it
> belong under /opt?

This would be the case if you would like to install GT.M by other means
than an official Debian package (for instance if you are using the GT.M
installer).  In case of a Debian package it is no add-on but a part of
the Debian system. 
 
> > 2. Should I call the package fis-gtm (the name we have on Source Forge),
> > lsb-gtm or just gtm?
> 
> Do you mean lsb-gtm in the sense of Linux Standard Base - GT.M?  I would
> not use this.  Each package should confirm to LSB and thus the prefix is
> redundant.  Whether it is fis-gtm or gtm I have no opinion.  Take whatever
> might be fit better for your taste.
> 
> > Thank you very much for your advice.
> 
> You are welcome.
>
> ...
> 
> Some technical hints.  I hope you are aware about the Maintainers Guide[3].
> This document should be really helpful for your task.  I would start with
> creating a "source tarball" which in the GT.M case contains actually no
> source but your precompiled GT.M binaries.  This tarball might get the name
> 
> gtmbinaries_<version>.orig.tar.gz
> 
> or something like this.  Unpack this tarball and create a debian directory
> featuring the usual files like control, copyright, rules.  It might be a
> very good idea for the beginning to keep the rules file a very short file
> using debhelper 7 like:
> 
> -----------------------------
> #!/usr/bin/make -f
> %:
> dh $@
> -----------------------------
> 
> and using a dh_install input file (see man dh_install) which moves all
> the files right into place.
> 
> I would also consider it as a good idea if you would use the Debian Med
> packaging SVN to maintain this debian directory.  This would enable the
> Debian Med team a very quick access to your work having a look on it and
> commit changes.  The only thing you need to do is registering at Alioth[4]
> and tell me your account name.  You will also find a plenty of examples
> how to do the packaging in our SVN.
> 
> [KSB] I think I will need to work on my own for the source distribution for a
> while.  The GT.M build process is quite different from any standard package at
> this time.

This is what I expected and that's why nobody started with GT.M until now.
But finally there will be a state where you move files right into place.
That's the point where you might consider dh_install.

> In short:
> - try to keep the discussion open
> - target at an policy compliant official Debian package
> - join Debian Med team to get most help
> 
> Thanks for working on GT.M Debian packages
> 
> Andreas.
> 
> [1] http://lists.debian.org/debian-med/2009/08/msg00029.html
> [2] http://lists.debian.org/debian-med/
> [3] http://www.debian.org/doc/maint-guide/
> [4] http://alioth.debian.org/

Hope everybody was able to make sense of this nested quoting.

Kind regards

      Andreas.

-- 
http://fam-tille.de
Klarmachen zum Ändern!


Reply to: