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
Reply to: