>> Cobblers. I build on Whitebox, and the .rpms run on RHEL, Fedora,
>> CentOs, Suse and Mandrake.
>
> I'd be impressed if that were the case.
Be impressed, then :-)
The code is in beta. I personally have run it on Whitebox, Fedora, and
OpenSuse. I've found out about the other disties from feedback through the
beta programme.
> (Primarily because you cannot express dependencies in .rpm files
> in a portable cross-distribution manner.)
Errr - but you can. You can express whatever dependencies you like.
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.
But that's true of any dependency system (i.e. equally true of .debs - and
something I actually ran into at one stage), and it's also a fairly rare
case unless you're building very specific distribution-targetted packages.
> Surely the fact that a .deb contains binaries which don't run upon
> the non-Debian host isn't a problem? I'm a little confused.
If that happens, I have to build on each target that I want to ship for;
given the complexity of the build, that is not going to happen.
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.
> Earlier you said there was a free download available, if you point
> me/us at it
ftp://public:@soton.mpeforth.com . If you're prompted for a password, it's
blank. There's a yum repo file there "mpe.repo" which goes into
/etc/yum.repos.d/ or similar for yum users, or you can add this to apt's
sources.list:
# vfxforth repository
deb
ftp://public:@soton.mpeforth.com/ ./
> I would be happy to wrap it in a minimal Debian package,
> if that is useful?
It's already packaged - but feel free to comment on what I've done if
there are improvements to be made.
>> But you *could* create RPMs fairly easily by getting yourself a working
>> RPM environment. That you don't is your choice - and one to which you
>> are
>> fully entitled - but it says nothing about the packaging system.
>
> I guess that is true. I can install a Xen guest, or similar
You could install rpm on your deb box. You could install a new machine
(it's not like it needs to be anything special). THere are many ways of
doing it...
> but
> the point I was trying to make was that to package for an RPM
> distribution pretty much requires that I have a running RPM-based
> distribution. (And similarly for Debian). Most times a chroot()
> is sufficient though.
Yes - but that's a trivial matter to achieve.
It does not follow that there is anything broken with the packaging system
that you need that system to be able to use it. It *does* follow that
there are problems with a packaging system if creating a package is
difficult or even impossible if you *do* have it.
>> It does appear to be impossible to
>> build the source package I want without re-writing the tools
>
> Without a specific example it seems hard to imagine how that could be
> the case. Ultimately a Debian package is a pair of:
>
> * data.tar.gz
> -> Containing files to be unzipped into your / partition
> * control.tar.gz
> -> Containing some meta-information.
That's a binary package.
A source package consist of a .dsc (that's easy), a .orig.tar.gz pristine
tarball, and a .diff.gz tarball containing patches to that pristine
tarball. So far so good.
Unfortunately, when you run dpkg-buildpackage, all these files are
*required* to have the same base name - so even though the .dsc files
names the components correctly, a package will not be built unless they
have a common name. I either need to change the name of the pristine
tarball (so it is no longer pristine), or I need to re-write
dpkg-buildpackage. Guess what? I don't. I build from a .src.rpm & use
alien to create the .deb files. Debian users don't get a source package.
> Ignoring policies that don't seem relevant is fine.
Well, I'd say that if the Policy Manual is being ignored, it is of limited
use.
> But suggesting
> that you can't create a package of random binaries without modifying
> tools is hard to understand.
See above.
Vic.
