Re: multiple binary packages (again)
Domenico Andreoli wrote: debstd (i hate it, it is stupid) wants to debianize all packages you are building *at once*. so when i build the first binary package (say the plain one) it tryes to debianize also the ssl one (which i have not even built yet!). OT i think debstd would be more friendly if it could care about a package at time, wouldn't it? /OT I suggest you take a look at debhelper. -- see shy jo
RE: multiple binary packages (again)
When non-US was divided into non-US/main etc. it was decreed, that /main non-US/main together are the free part, as determined by license. Placement into /main or non-US/main is determined by export control laws which have no bearing on licenses. So it is perfectly permissible to have in /main a binary package whose sources are in non-US/main. (It only means that the sources are in that part of main that is not hosted in US.) t.aa Hamish Moffatt [EMAIL PROTECTED] Fri, Aug 20, 1999 5:05 PM On Mon, Aug 16, 1999 at 06:11:59PM -0400, James Mastros wrote: On Sun, Aug 15, 1999 at 01:55:33AM +0200, Domenico Andreoli wrote: On Sat, 14 Aug 1999, Raphael Hertzog wrote: Apart from that, isn't there a non-US problem with the SSL support ? Take care not to install in main something that could not be exported by US residents. right, i have to break source in two anyway. i can't put source in main distribution that require some non-US packages, can i? No, but you can put source in non-US/main that builds both main and non-US/main binary packages. Can you? Isn't main supposed to be free standing? Clearly the source can't go in main, so the binaries can't either. xpdf and xpdf-i have the same .orig.tar.gz. Mind you, I wouldn't build them from the same source package even if I could; too hard to apply the -i patches during build.
Re: multiple binary packages (again)
On Mon, Aug 16, 1999 at 06:11:59PM -0400, James Mastros wrote: On Sun, Aug 15, 1999 at 01:55:33AM +0200, Domenico Andreoli wrote: On Sat, 14 Aug 1999, Raphael Hertzog wrote: Apart from that, isn't there a non-US problem with the SSL support ? Take care not to install in main something that could not be exported by US residents. right, i have to break source in two anyway. i can't put source in main distribution that require some non-US packages, can i? No, but you can put source in non-US/main that builds both main and non-US/main binary packages. Can you? Isn't main supposed to be free standing? Clearly the source can't go in main, so the binaries can't either. xpdf and xpdf-i have the same .orig.tar.gz. Mind you, I wouldn't build them from the same source package even if I could; too hard to apply the -i patches during build. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: multiple binary packages (again)
Domenico Andreoli [EMAIL PROTECTED] writes: i'm trying to package curl. curl is tool to download anything from the net in all sort of ways (http, ftp, gopher, https). it comes also with ssl support, i can tell it to compile ssl support by a switch after ./configure. in order to get both version i have to configure/make sources (for plain version), save somewhere plain binary and clean reconfigure/remake all (for ssl flavour). ... moreover, dpkg-buildpackage wants to do make build and then make binary. i can build a curl flavour at time. to do a binary package i must to have just built that flavour. i can't make both of them and then pack them. unless i have to copy all the source tree somewhere and proceed to parallel work. If the source's Makefile isn't to braindead, you can build the binaries in a different directory than the sources. Usually debian packages build the bins in build and install them to debian/tmp. You could use build and build-ssl to actually do two builds. Alternatively, and superior to the current implementation of curl, you could put the ssl support in a library and eigther write a dummy fo US or use dlopen to open the lib if present. That way you would have only one curl package and a curl-ssl add-on for people who need it. ... have i to do a source packages for each flawour of curl? it sounds dull to me. The xserver packages should have the same problem. Looking at them might help. May the Source be with you. Goswin
Re: multiple binary packages (again)
On Sun, Aug 15, 1999 at 01:55:33AM +0200, Domenico Andreoli wrote: On Sat, 14 Aug 1999, Raphael Hertzog wrote: Apart from that, isn't there a non-US problem with the SSL support ? Take care not to install in main something that could not be exported by US residents. right, i have to break source in two anyway. i can't put source in main distribution that require some non-US packages, can i? No, but you can put source in non-US/main that builds both main and non-US/main binary packages. -=- James Mastros
Re: multiple binary packages (again)
On Sat, 14 Aug 1999, Gopal Narayanan wrote: Curl is already packaged and available for potato. If you are packaging this for your own edification, you can take a look at this package to see how it was done. http://www.debian.org/Packages/unstable/non-us/curl.html i know, i took over the actual maintainer, Leon Breedt. i'm not a debian devel yet... he did only ssl version, i want to do both. by the way, upstream maintainer says curl-ssl was based upon ssleay. now he wants change to openssl. actually curl can be compiled with both, in the future support will be granted only for openssl. i can't compile it neither with ssleay nor openssl. i have to install libssl package. i'm not understanding the point. openssl package is installed but dpkg-shlibdeps says my binary is dynamically linked against libssl again. what a mess with theese libraries, shouldn't be them all mutually exclusive? -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://cavok.freeweb.org
Re: multiple binary packages (again)
On Sat, 14 Aug 1999, Raphael Hertzog wrote: Why don't take a look a other sources building many packages ? Vim was listed as an example ... you may want to take a look at perl-5.005 too. That's the best source of information in general, look what has already been done. i took apache-1.3.3-7, it seems having same my matters with ssl Apart from that, isn't there a non-US problem with the SSL support ? Take care not to install in main something that could not be exported by US residents. right, i have to break source in two anyway. i can't put source in main distribution that require some non-US packages, can i? -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://cavok.freeweb.org
Re: multiple binary packages (again)
Le Sun, Aug 15, 1999 at 01:55:33AM +0200, Domenico Andreoli écrivait: care not to install in main something that could not be exported by US residents. right, i have to break source in two anyway. i can't put source in main distribution that require some non-US packages, can i? No. Cheers, -- Hertzog Raphaël 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Re: multiple binary packages (again)
On Sat, Aug 14, 1999 at 09:36:22PM +0200, Domenico Andreoli wrote: i'm trying to package curl. curl is tool to download anything from the net in all sort of ways (http, ftp, gopher, https). it comes also with ssl support, i can tell it to compile ssl support by a switch after ./configure. Curl is already packaged and available for potato. If you are packaging this for your own edification, you can take a look at this package to see how it was done. http://www.debian.org/Packages/unstable/non-us/curl.html -- Gopal Narayanan Ph #: (413) 545 0925 Five College Radio Astronomy Observatory Fax#: (413) 545 4223 University of Massachusetts e-mail: [EMAIL PROTECTED] Amherst MA 01003 ---
Re: multiple binary packages (again)
Le Sat, Aug 14, 1999 at 09:36:22PM +0200, Domenico Andreoli écrivait: in order to get both version i have to configure/make sources (for plain version), save somewhere plain binary and clean reconfigure/remake all (for ssl flavour). well, multiple binary packages support goes well when with a build you get all you need to make all binary packages. [...] have i to do a source packages for each flawour of curl? it sounds dull to me. Why don't take a look a other sources building many packages ? Vim was listed as an example ... you may want to take a look at perl-5.005 too. That's the best source of information in general, look what has already been done. Apart from that, isn't there a non-US problem with the SSL support ? Take care not to install in main something that could not be exported by US residents. Cheers, -- Hertzog Raphaël 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
