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

Re: Status packaging GT.M? (Was: OpenVista for Ubuntu)

The information contained in this email may be confidential and/or may be covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions.. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please contact the sender by reply email and destroy all copies of the original message. To contact our email administrator directly, send to an email message to helpdesk@medsphere.com. Thank you.
--- Begin Message --- 
On Tue, 2010-02-02 at 14:10 -0800, Andreas Tille wrote:
> I had a look into
> 
>   http://mirrors.medsphere.org/pub/apt/ubuntu/pool/main/f/fis-gtm-5.3004/
>   http://mirrors.medsphere.org/pub/apt/ubuntu/pool/main/f/fis-gtm-5.3004a/
> 
> (the distinction with 'a' in the end is unclear to me - an explanation
> would be welcome.)

It's just another version of GT.M -- 5.3004 and 5.3004A are different
versions.  (Debian packaging doesn't allow capital letters in the
version number, IIRC, so I lowercased it.)  We support multiple versions
of GT.M simultaneously because production sites may not want to upgrade
to the latest version.  It's like having both PostgreSQL 8.3 and 8.4 in
the repository. 

> I guess you will soon start updating to the latest version.  

It may not be that soon, but eventually, yes.

> Once you
> did so I will extract it and move the packaging directory (debian/) to
> our SVN.  

We're currently keeping these files with the rest of the files from our
Project[1] (of which packaging GT.M is just one part) in Bazaar on
Launchpad.net.  Of course, you're welcome to import them into your own
system.

> Alternatively we might move also this stuff to SVN (or Git at
> your preference) for historic reasons if you think this makes sense.  It
> might be a reasonable idea to maintain a common Debian / Ubuntu
> changelog anyway.
> 
> Once the packaging directory is in our VCS I will be able to have a look
> into it and try my luck with building the packages.

Currently, the package requires root to build (the package, not to
compile GT.M itself), which is why I have not pursued upstream
inclusion.  Launchpad's build system won't allow us to build as root,
and I suspect Debian's won't, either.  That's the main reason we're
hosting them in our own repository.

> > The next step is that I need to write a GT.M install script that will
> > provide for a cleaner installation of GT.M from a .deb package.  Now that
> > we have the V5.4-000 release out, I plan to work with Jon on that.

To elaborate on this: the packaging process requires root because the
install script (called "configure" in GT.M) essentially doesn't support
"make DESTDIR=" functionality.  Bhaskar has hinted at supporting this
kind of usage in the future -- I didn't want to rewrite the install
script and diverge significantly from upstream.

Another hurdle to upstream inclusion is proper support for the FHS.  I
believe Bhaskar had some some work in the area, but I won't speak for
him.  I haven't tried to make GT.M conform to the FHS -- I just install
it in /opt.

> > Once we have a tested installation script, then we can look at doing
> > builds on alioth and getting it included in the Debian repositories.  At
> > this point, we will almost certainly need your help because among other
> > things, we will need to create some meta packages.  Also, we will
> > probably need help in setting something up under /etc/alternatives.
> 
> Sound like a doable task for me ...
> 
> > I hope this gives you a view of where things are.  We are making
> > progress, only not as fast as we would like to.
> 
> Sore.  No problem.  This kind of projects always take more time as
> expected.
> 
> > If you have any questions, please do ask.
> 
> See above:
> 
>   1. 'a' in the end
>   2. It is reasonable to put current stuff into Debian Med VCS even
>      if it does not build a valid Debian package.  Sometimes it make
>      sense to keep the history - but it is finally your decision.

If you don't mind the build-package-as-root requirement and the lack of
conformance to the FHS, go ahead and add it -- of course, if you make
any substantial changes, please do let us know so we can make them in
our Project as well.  As I mentioned before, we're already keeping
history in Bazaar, so if that's the only reason for adding it, then you
may want to wait a while longer.

- Jon

[1] https://medsphere.org/community/project/gtm

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: