Re: [MoM] Packaging fis-get

["Bhaskar, K.S" <ks.bhaskar@fisglobal.com>]

On 01/29/2012 05:48 PM, Karsten Hilbert wrote:
> On Sun, Jan 29, 2012 at 04:50:56PM -0500, Bhaskar, K.S wrote:
>
> > > > Also, users routinely have multiple GT.M
> > > > releases or versions installed on their computers, and multiple GT.M
> > > > releases peacefully co-exist on the same computer.
> > > Like PostgreSQL 8.4/9.0/9.1 and GNUmed 0.7, 0.9, and 1.1 ?
> > >
> > > Surely there must be a way to
> > >
> > > - release a bug fix version
> > [KSB] Bugs are only fixed in new versions/releases.
> I am not sure I quite understand what you are saying. There
> will, of course, be a new version number and a proper
> release when "recompiled" code is packaged up even if the
> one and only change is in fixing one character in one line
> of one file (a bug, that is). That would seem standard Good
> Practice to me (not that everyone follows that, though). I
> do not foresee any problems from that regarding Debian
> packges. How would this release approach influence packaging
> fis-gtm?

[KSB] I think the only interaction is that we would expect a Debian major 
release to use (say) libicu44 and not switch to libicu46 (or libicu48) 
till the next major release.  And there is a series of updates to 
libicu44.  With GT.M, it will be reasonable and customary to have 
fis-gtm-5.4-002a, fis-gtm-5.4-002b and fis-gtm-5.5-000 to all be 
available for the same Debian release.

This is not incompatible with Debian package management.  I was only 
point out that it is different from many other packages in that regard.

> > > - enable a user to "transfer" her data/configuration
> > >    to 5.5-000 who initially ran 5.3-017g-whatnot
> > [KSB] We are very particular about regressions.  So, it's usually
> > just a matter of recompiling the code, and if a database upgrade is
> > required, running the database upgrade.  On those rare occasions when
> > we must make something not 100% upward compatible (and it is indeed
> > very rare), we flag it in the release notes.
> I agree what you describe here is Best Practice (as done in,
> say, GNUmed as well).
>
> So, when I install fis-gtm 5.3-017g today and next week
> Debian delivers a package containing the code for 5.5-000
> will there be a way for me to upgrade my database/M code ?
> If so, then I fail to see the problem with Debian providing
> the new GT.M version to me via a package ?  And later
> providing me with a 5.6-002z package allowing me to run,
> say,
>
> 	/sbin/fis-gtm-upgrade

[KSB]  Yes, that's the general idea.  But it's a little more complicated 
than that because, for example, you may want to build new shared 
libraries for the code, and occasionally other configuration files may 
need to be tweaked or extended.

Regards
-- Bhaskar

> ?
>
> Thanks,
> Karsten

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.