Although philosophically more aligned with Debian, I had been a RedHat user for almost 8 years largely pragmatic reasons that aren't relevant. As such, I have developed a large rpm-based infrastructure for releasing my company's own software to our production facilities and have become quite familiar with RedHat's rpm system from the developer's perspective.
Now I'm strongly considering making the switch to Debian and am evaluating moving my whole installation system over to dpkg. dpkg seems superior to rpm in almost all respects (richer dependencies, better documentation, more robustness, apt, etc.), but there's one thing that bothers me. When building an rpm, multiple source files and multiple patch files can be specified, and arbitrary commands can be used to extract sources and apply patches. This makes it easy to build an rpm of a standard package with a handful of separately maintained patches applied. As far as I can tell, a Debian package consists of a single source tarball and a single diff. Is this right, or have I missed something? Coming from an rpm perspective, it seems to me that this would make it much more difficult to manage locally modified versions of packages. I'd appreciate if someone could either explain to me that I've got it all wrong give me a pointer for what to look like, or confirm that my understanding is correct but explain why this isn't really a problem. I'm especially interested in hearing thoughts from other people who have converted an rpm-based infrastructure to a dpkg-based infrastructure. Lastly, please feel free to correct my terminology if I'm using it incorrectly. For example, is it correct to say dpkg-based rather than deb-based? Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
