Did I miss a mail somewhere? I saw nothing from Lorenzo. > > and I would be very glad if you became the new maintainer. As you are > > also part of the upstream team, you could probably transform the > > package into a native Debian package (no .diff would be needed > > anymore).
Don't do that. Native packages are for things which don't have upstream releases. Debian diffs are a good thing. On Fri, Oct 12, 2007 at 02:55:35PM +1000, Paul Gear wrote: > Can i make a request that you store as much of the debian packaging > information and scripts as possible in the Shorewall svn ? I'd really like > to be able to build > proper packages from the development svn tree. :-) This is always a bit tricky, because Debian releases and upstream releases are inevitably out of sync - the branching patterns and release dates just never line up. Trying to maintain a Debian package in upstream revision control always leads to insanity and pain. It seems tempting for somebody who works on both Debian and upstream to only deal with one pile of source, but it *really* isn't easier. (I have probably tried just about every possible combination over the years, including the one where you invent new revision control systems to try to make it work. It's much harder than it looks.) The best approach is usually to maintain the Debian package independently, and then regularly copy the debian/ directory back into the upstream tree - so that part of the tree is actually downstream from the Debian package itself. It sounds a little weird, but it's invariably simpler than any of the other ways, and gets the job done. It's also best if those files are not included in the upstream release tarballs, as that tends to cause user confusion and really doesn't help anybody (all those who can use it, can get it more directly from a Debian mirror). > (tools/build > would be a good place for it) Debian packaging has to be placed in the root of the source tree. Getting anything else to work right requires deep understanding of the very gnarly internals of the package build process, and the three or four layers of abstraction it's usually buried under. There's probably about a dozen people who could pull it off, and none of them would want to. Given the current arrangement of the tree, this means there have to be three batches of it. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
