Re: Problem to create the orig tarball
Ok, thanks for the answers. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1297952910.4d5d308e87...@imp.free.fr
Problem to create the orig tarball
Hello, What's the proper way to package a plug-in that require the application's sources to compile and both come in a separate tarball ? Note : The application and the plug-in will be built in a separate package. Regards, Fred. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1297869140.4d5be95483...@imp.free.fr
Re: Problem to create the orig tarball
On Wed, Feb 16, 2011 at 04:12:20PM +0100, fre...@free.fr wrote: Hello, What's the proper way to package a plug-in that require the application's sources to compile and both come in a separate tarball ? Note : The application and the plug-in will be built in a separate package. Try to convince the maintainer of the application package to provide an additional package, usually named foo-source or something, which basically contains the archived source of the application just as it is before the build is started (e.g. after applying patches and similar). For an example, pick any of the packages listed by e.g.: apt-cache search --names-only -- -source | fgrep -ve 'kernel module' -e driver I believe the gcc*-source packages are provided for this exact purpose - a base for cross-compiling development environments for embedded systems and such. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. signature.asc Description: Digital signature
Re: Problem to create the orig tarball
On Wednesday 16 February 2011 09:12:20 fre...@free.fr wrote: What's the proper way to package a plug-in that require the application's sources to compile and both come in a separate tarball ? First, make sure it requires the full application sources, and not just some headers. If it just requires the headers, have the main application source package build two binary packages: $app and $app-plugin-dev (or something like that). Then, you can have the plugin source package build-depend on $app-plugin-dev. If it requires the full, possibly patched, but unconfigured sources, has the main application source package build two binary packages: $app and $app- source. Then, you can have the plugin source package build-depend on $app- source. If it requires some intermingling of the build process, then things get sticky. E.g. if the plugin requires that ./configure (or similar) is already run in the source tree before its ./configure (or similar) will work properly, the builds need to happen concurrently. In this case, you might be best served by using multiple .orig files in a single source package.[1] Of course that massive source package will build multiple binary packages $app, $app- plugin-$plugin. [1] This might actually not be fully supported, yet. I'm not sure about the status, but I believe 3.0 (quilt) source packages can handle it. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
