Hi, Daniel Baumann wrote: >>What you are doing is taking upstream's code and adjusting it to >>out-of-tree compilation. Since you are shipping patches (dpatch ...) >>anyway, it still seems to be possible to prevent repackaging (which >>should be tried as far as possible). > > No. Atm you have to repackage it, or how do you want to 'unpack' the > patch when some files (kconfig) coulnd't be patched in a way, that it is > still non-interactive for autobuild?
Provide a kind of kernel source stub, apply the upstream patch and our new package specific patches/changes. Yes, ugly. Thanks for already contacting upstream. :-) >>>Actually true, but imho there shouldn't be any native packages in Debian >>>at all. >> >>This differs from common practice and standards within Debian. Feel free >>to discuss it on [EMAIL PROTECTED] ;-) > > Sorry, no. Native packages are for packages that are specifically > developed for debian. If we just need to rebuild a tarball, common use > is to add +dfsg for the version when we need to rebuild it due to > license issues. For other reasons, mostly a +debian tag is used. We recently had a similar discussion on debian-devel. There are even packages which don't have an orig.tar.gz or diff.gz but nevertheless a Debian revision (which I didn't like, but needed to accept). It's common for cases where upstream is that inactive that the respective Debian developer took over development himself and the diff.gz would be much bigger than the orig.tar.gz, making the latter somehow useless. We need to accept native packages that were not specifically developed for Debian. Thanks for considering, bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
