Re: Possible framework for `dpkg-dev/debmake replacement'
On 25 Feb 1997, Manoj Srivastava wrote:
> I was just interpreting the subject, and trying to keep the
> focus on debmake, which is (a) what I am interested in discussing,
> and (b) what the thread had been about.
Having spent a bit of time rethinking my ideas about what we should be
discussing (after somebody (I forget who) quite rightly pointed out that
I was talking about implementations rather than requirements), I've just
caught up on this thread, and it seems to me that there are two major
areas of disagreement here.
1) What are we actually trying to specify? IIRC the original thread was
about some sort of new tool to ease the building of packages; debmake
does this, but not necessarily in the ideal manner. So, the aim was to
construct a replacement for debmake, which had all the features people
wanted.
Once this tool was completed, it was my understanding that it was to be
the standard way of building packages, which I don't know that debmake
was ever intended to be. And hence it goes in dpkg-dev. But it should
have a lot of the (conceptual) functionality the debmake had, and so it
replaces debmake.
Of course, this is just my interpretation of the situation, and so is
MHO. Feel free to tell me I'm wrong. :)
2) How closely do we want to follow the debmake scheme? Following on from
my comments above, I see no reason to necessarily follow the debmake
pattern. There is no reason, so far as I can see, why our `debmake
replacement' shouldn't take the form of a `compiler' for the debian/rules
file, or a set of individually-automated steps, or a single central
binary (using one or more configuration files), or anything else. But
despite the fact that we perhaps should be leery of discussing
implementations at this point, the whole direction of the tool depends on
this, and I'm not sure that we can fulfil the same requirements with
either. At the very least, the overall form of the tool should perhaps be
one of the requirements.
This is just an attempt to clarify things; it may or may not be
successful. But it seems to me that we're laboring under a couple of
misapprehensions, which would benefit from being at least recognised.
Just MHO, again.
&E
--
Andy Mortimer, andy.mortimer@poboxes.com
http://www.netforward.com/poboxes/?andy.mortimer
Finger asm21@asm21.emma.cam.ac.uk for PGP public key
--
When the sunset's glow drifts away from you you'll never know
If any of this was really true at all.
--
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
Reply to: