>> 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
Well, those are different things. If you *claim* you require postfix, when
really you mean "any MTA", it's hardly surprising things go wrong. But
that's not an RPM issue - that's simply the packager not saying what he
meant.
But both of the above can be expressed in an RPM.
>> 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.
That might be a packaging issue, in which case a bug report to the
packager would help, or it might be that the two distributions are
sufficiently forked for it to be impossible to determine automagically
whether or not the dependencies are met - again, that's nothing to do with
the packaging system, it's the fact that the OSes are different...
Nevertheless, rpm allows you to force installations, if you promise it
that you know what you're doing. I've found that forcing installations on
an Ubuntu box causes future installations involving unrelated packages to
fail until the dependency issues are fixed; I see that as a bug. I don't
know if the same is true on other debian-type distros.
> 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.
That's essentially what I do; it's just that I use the rpm as a vehicle to
transport the release around, and I use alien to get it into a (mostly)
useable state ready for packaging on Ubuntu.
> (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.)
The first part of the build has to be done on a Windows box at present. It
is not (yet) a trivial matter to run multiple build machines here...
> You install a lib to /lib
My 32-bit Ubuntu box only has /lib. The 64-bit version installs to /lib32
(and yes, that was a pain to build...)
> and binaries to /usr/lib.
I've just had to log in to check that - they go into /usr/bin. You had me
worried there!
> Those binaries have no external dependencies beyond the expected:
> steve@steve:~/forth/usr/bin$ ldd vfxlin
> linux-gate.so.1 => (0xffffe000)
I don't know what this is, nor where the dependency comes from. "locate
linux-gate" returns nothing...
> 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)
These are all correct - all those libraries are *explicitly* called from
within the binary.
> The first comment I'd have is the section 'alien' would be
> better marked as 'devel'
Yep. That's one of the side-effects of using alien to do my conversion. It
can be set in the debian/control file that alien creates, but I wasn't
sure what to do with it, and it isn't a show-stopper anyway.
> Secondly you install documentation into two directories:
> /usr/share/doc/{vfxforth VfxForth}
> Pick one, and use that.
I meant to use the latter; I'm not entirely sure which bit of the build
process creates the former. That's a packaging bug that I haven't fixed
yet.
I'm not especially worried by it - again, I have bigger fish to fry :-)
> More that the policies of a closed-source distributor aren't likely
> to match those of an open-source developer.
Yes - but the package in question is the libmpeparser package, which could
be open-source (and will be on Monday when I remember to put the srpm on
the ftp site!). But there won't be any debian source packages for it
because I can't create such a thing unless I dibble with the pristine
tarball.
> 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.
Again, that's largely what I'm doing - just using the .rpm as a way to
derive a set of dependencies & to transport the files between boxes.
> Having the source package, given that you don't want to distribute it
> would nice, but overkill.
Not for the Forth compiler - but I do want to distribute it for the parser
library.
Vic.
