[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: programs by Dan Bernstein



Roberto Lumbreras <rover@lander.es> wrote:
> What I've done is package it as usual but upload only the source
> package. I'm open to suggestions :)

My (not particularly elegant) solution was to add a step to the end of the 
package build that creates a package called qmail-src, which contains the 
.orig,.diff and .dsc files under /usr/src/qmail-src, along with a script 
/usr/bin/build-qmail.

The idea is that a user installs qmail-src, runs qmail-build and ends up with 
a qmail.deb, without needing to know anything about building packages in 
general.
They can then remove qmail-src, and install qmail.deb as a normal package on 
as many systems as they please.

Unfortunately, you currently need to delete the qmail.deb line from the 
changes file by hand before doing an upload, to prevent the binary package 
seeing the light of day, but other than that it seems to work OK.

I really need to have a look at converting it to use debhelper, which should 
allow me to automate that one step (I think).

> BTW: What about ucspi-tcp? Are you working in it? If not, I can
> upload the private package I'm using with rbl support.

I have a package, but it needs the -src treatment.  I guess it would be best 
for me to maintain ucspi-tcp, since its primary use will be in conjunction 
with qmail, but I'd be interested to see your diffs.

Do you think we should produce two packages, ucspi-tcp & ucspi-tcp-rbl so 
people can have the vanilla version as well?  I was going to do this for 
qmail, since you can put the rbl stuff in there for use under inetd.

Cheers, Phil.



--
E-mail the word "unsubscribe" to debian-devel-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble?  E-mail to listmaster@debian.org .


Reply to: