Re: debstd trouble with multi-binary package
As the author of one of those documents, (Will Lowe is the other but I
don't know if he is still working on it.) I agree completely. I no longer
use debstd in my own packages and don't recommend it to others.
Since around February off and on, I've been working on a revised edition
which would be debhelper based and much more ambitious in scope.
Unfortunately I didn't reckon with the hell which is Y2K taking over all
my spare time at work. When I did get a little time to work on debian
stuff, I unwisely let my self get sidetracked into debianizing TWIN.
But really really soon now, there will be an update. I promise :-)
Jaldhar H. Vyas <email@example.com>
On 6 Jul 1998, Adam P. Harris wrote:
> Martin Schulze <joey@tapiola.Infodrom.North.DE> writes:
> > debstd is depricated, use the debhelper instead.
> Incidentally, if you look at the Debian Developer's corner
> (http://www.debian.org/developers_corner), you can see why a lot of
> new maintainers start using debstd instead of debhelper. We have two
> different documents suggesting debmake/debstd and zero suggesting
> Joey Hess, as the maintainer of debhelper, do you see this as a
> situation that should change? I think we should eliminate any manuals
> suggesting debstd (or put it under a "historic" section), and try to
> get someone working on a debhelper equivalent. Perhaps a discussion
> of the pros and cons of debhelper, hand-roll (a la Manoj), and
> cvs-buildpackage and the like could be discussed also.
> I'm probably going to take over the developers reference; I've
> considered widening the scope a little to talk about package practices
> (not a HOWTO, however!) which might discuss these high level issues,
> i.e., what methods are available to developers to help them package
> stuff, which ones are deprecated and which are supported, etc., all
> the while sticking with objective fact and leaving the valuation up to
> the maintainer herself.
> Comments please.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com