On Thu Feb 21, 2008 at 13:43:33 -0000, Vic wrote:
> > I'd be impressed if that were the case.
>
> Be impressed, then :-)
:)
> Errr - but you can. You can express whatever dependencies you like.
OK let me retry that then. What I meant is that the is the
mismatch between saying these two things:
* Package depends upon having /bin/sendmail
* Pckage depends on having postfix
> The only time this will fail is when the dependency name changes between
> distributions such that you can't identify it on a particular platform.
And that's where I've seen problems when it came to installing an
RPM from SuSE upon a Cento machine.
> I either build on a deb-type box & convert to rpm, or build on an rpm-type
> box and convert to deb. That's the only feasible way to run this - and the
> latter means that I have to determine my real dependencies by hand, so
> it's not going to happen.
It seems like either way you should build into a collection of
binaries, then have those be the input to the .rpm, or .deb, creation.
(I'm not sure what kind of build environment you've got, but if
you have a source tree and the ability to run 'make install
prefix=/x/x/x/' then you'd be able to do that easily.)
> It's already packaged - but feel free to comment on what I've done if
> there are improvements to be made.
Thanks. I've grabbed the vxforth alpha9 package, and it looks
mostly OK. You install a lib to /lib, and binaries to /usr/lib.
Those binaries have no external dependencies beyond the expected:
steve@steve:~/forth/usr/bin$ ldd vfxlin
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7fb9000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e88000)
/lib/ld-linux.so.2 (0xb7fca000)
The first comment I'd have is the section 'alien' would be
better marked as 'devel' Patch /usr/share/perl5/Alien/Package/Deb.pm
to do that. (Should be configurable I'd agree.)
Secondly you install documentation into two directories:
/usr/share/doc/{vfxforth VfxForth}
Pick one, and use that.
> That's a binary package.
Sure.
> Well, I'd say that if the Policy Manual is being ignored, it is of limited
> use.
More that the policies of a closed-source distributor aren't likely
to match those of an open-source developer.
My suggestion, now I fully understand things would be to build both
.rpm + .deb packages from the binaries you produce. And not build a
Debian source package, just a binary one. That is a debian/rules file
pretty much consisting of moving the binary files into a given
location.
Having the source package, given that you don't want to distribute it
would nice, but overkill.
Steve
--
http://www.steve.org.uk/
