on de-supporting deb-make
> We have just done, and continue to do, a whole lot of conversion of
> packages to the new package format. Much of this has been done using
> deb-make. I think we need to be a bit more careful before we decide to
> de-support deb-make, and we can almost certainly not afford to do it on
> what looks to me like a 4-month schedule.
I don't mean to say that in 6 months it will be gone; in 6 months it
will be obsolete, in that no new package should use it.
> First, I'd like to see the replacement for deb-make completed, and tested,
> before we announe the de-support of deb-make. Second, I'd like to see debstd,
> the run-time component of debmake, supported for a good long time, so that
> we don't have to re-convert a whole bunch of packages that have been converted
> only days ago. Surely this is technically feasable.
I would expect to support debstd for some time to come.
> We shouldn't forget why debmake happened. It happened because the Debian
> developers, myself and Ian Jackson for the most part, made a mistake and
> missed an obvious opportunity to improve the system. It happens that Ian
> was busy with his thesis and I am just always busy, but it's one of the
> virtues of Debian that someone else can step forward and repair that sort
> of problem.
I disagree with this analysis. We should not ask `why does a tool
like debmake exist at all ?' After all, a tool whose purpose is
roughly that of debmake is a good thing.
We should ask how the design and implementation of this tool came to
be done in a way that so many developers, myself included, are unhappy
I think this happened because there was insufficient discussion of the
issues on debian-devel, and because the package was initially billed
as a fringe experiment which core developers need not pay atention to.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com