Status packaging GT.M? (Was: OpenVista for Ubuntu)
On Mon, Nov 23, 2009 at 08:10:31AM -0500, K.S. Bhaskar wrote: > > [KSB] I found I needed to rework some of the user scripts in the GT.M > distribution first, which I will get into the GT.M packages. But it > appears that creating Debian friendly packages - not just binary packages > but Debian source packages that build into Debian binary packages is > somewhat more complicated than I envisioned, and since it is a background > activity, I have not made as much progress as I had hoped. Any news here? I'm keen on helping out in case of problems but I somehow need a starting point because of a lack of GT.M knowledge. So if you stumble upon any problem regarding *packaging* please do not hesitate to ask here. Perhaps you might give a status report and links to work in progres to let us have a look? Thanks for your interest in Debian Med Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status packaging GT.M? (Was: OpenVista for Ubuntu)
Andreas -- Your e-mail is very timely - we just announced a major new GT.M release today (see http://fis-gtm.com)! This release includes the new scripting that makes GT.M easier to run out of the box. There is now a "gtm" script that sets up reasonable defaults for environment variables (the operation of GT.M is controlled by several environment variables), and creates a default database if one doesn't exist already. This database is journaled so that even if the computer crashes (or is just powered down), the database is automatically recovered when someone attempts to use it. To me, GT.M would not have been acceptable for mass distribution from the Debian repository without this scripting. So, this is one important step out of the way. Jon has set up an Ubuntu repository (see https://medsphere.org/docs/DOC-1722) and he is able to build and distribute packages. 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. 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. I hope this gives you a view of where things are. We are making progress, only not as fast as we would like to. If you have any questions, please do ask. Regards -- Bhaskar GT.M - Rock solid. Lightning fast. Secure. No compromises. On 02/02/2010 10:01 AM, Andreas Tille wrote: On Mon, Nov 23, 2009 at 08:10:31AM -0500, K.S. Bhaskar wrote: > > [KSB] I found I needed to rework some of the user scripts in the GT.M > distribution first, which I will get into the GT.M packages. But it > appears that creating Debian friendly packages - not just binary packages > but Debian source packages that build into Debian binary packages is > somewhat more complicated than I envisioned, and since it is a background > activity, I have not made as much progress as I had hoped. Any news here? I'm keen on helping out in case of problems but I somehow need a starting point because of a lack of GT.M knowledge. So if you stumble upon any problem regarding *packaging* please do not hesitate to ask here. Perhaps you might give a status report and links to work in progres to let us have a look? Thanks for your interest in Debian Med Andreas. -- http://fam-tille.de _ 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. _ -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status packaging GT.M? (Was: OpenVista for Ubuntu)
On Tue, Feb 02, 2010 at 03:08:09PM -0500, K.S. Bhaskar wrote: > Your e-mail is very timely - we just announced a major new GT.M release > today (see http://fis-gtm.com)! :) Congratulations to this release. > Jon has set up an Ubuntu repository (see > https://medsphere.org/docs/DOC-1722) and he is able to build and > distribute packages. 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.) I guess you will soon start updating to the latest version. Once you did so I will extract it and move the packaging directory (debian/) to our SVN. 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. > 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. Great. > 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. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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 helpd...@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 signature.asc Description: This is a digitally signed message part --- End Message ---
Re: Status packaging GT.M? (Was: OpenVista for Ubuntu)
On Tue, Feb 02, 2010 at 02:30:52PM -0800, Jonathan Tai wrote: > 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. Thanks for the clarification. > 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. Finally it depends what really makes sense. Maintaining a manual copy of another Vcs does not make much sense to me. The most important thing is IMHO that there is a clear split between the upstream tarball and the Debian packaging. IN Debian Med to Vcs are established: SVN, where we only keep the debian packaging directory + patches, and Git, where the upstream source is maintained using pristine-tar. I have no idea at all about Bazaar but I hope it supports this kind of split as well. If you are interested in the reasons for this strict distinction I might seek for some relevant links. > 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. I admit I have no idea about "Launchpad's build system". Because Bhaskar in a previous mail mentioned an Alioth build system: There is no such thing which deserves such a name. You build packages on your local machine and upload to ftp.upload.debian.org. There are autobuilders which are fetching new incoming packages and build these for different architectures, but Alioth just hosts different Vcs systems where you can keep your packaging stuff. So the question whether to build as root or not on Alioth is void. The Debian building tools are using fakeroot to build packages. > 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. Ahh, that's a shame and now I understand the problem. > 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. So the hint on the new version with rewritten install script enables specifying a destination directory? > 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. That's actually another showstopper. If I imagine that we have difficulties to include gt-m anyway because of its bootstrapping nature we should not overstress ftpmasters patience by providing packages which are not conformant to Debian Policy. > 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. Considering this it sounds reasonable to wait. Many thanks for the clarification Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
