On Thu Feb 21, 2008 at 13:10:58 -0000, Vic wrote:
> >   Sure, unless you want to use them on Fedora Core, Centos, Mandrake,
> >  etc.  Releasing an .rpm for one distro is easy.  Releasing one for
> >  N distributions is doomed to failure.
> 
> 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.  I've seen multiple people
 fail to release a working .rpm file for  project including multiple
 libraries and binaries.
  (Primarily because you cannot express dependencies in .rpm files
 in a portable cross-distribution manner.)
> >   alien is a hack.  It works a lot of the time, but there is no
> >  sane way to convert from .rpm -> .deb and expect it to work.
> 
> That certainly appears to be true. So what do I do with the library files
> where the Policy Manual prevents me from creating a source package without
> some very inappropriate dibbling? What do I do when the dependencies
> creating by building on my .deb system mean the binary won't run on my
> RHEL system?
  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.
  Earlier you said there was a free download available, if you point
 me/us at it I would be happy to wrap it in a minimal Debian package, 
 if that is useful?   At the very least having a concrete idea of
 your problems would be useful in trying to help you.
> 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, 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.
> If you installed a working RPM system and it prevented you from building
> RPMs, it would be broken. But that's not the case you're arguing.
  No, it wasn't.
> Familiarity is certainly a part of this - it's getting easier every time I
> release - but it's not the whole of it. It does appear to be impossible to
> build the source package I want without re-writing the tools (and even
> then I'd have packages that don't meet "policy").
  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.
 
  Ignoring policies that don't seem relevant is fine.  But suggesting
 that you can't create a package of random binaries without modifying
 tools is hard to understand.
Steve
-- 
# Commercial Debian GNU/Linux Support
http://www.linux-administration.org/