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

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

   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.


Andy Mortimer, andy.mortimer@poboxes.com
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: