Re: Possible framework for `debmake replacement'
>>"Kai" == Kai Henningsen <email@example.com> writes:
Kai> firstname.lastname@example.org (Andy Mortimer) wrote on 21.02.97 in
Kai> Have a special --update mode to the tool. Have it do rudimentary
Kai> detection of user stuff.
Kai> Have it *not* write a new rules file, but instead have it write a
Kai> rules.new file, and have it also write a rules.diff file by
Kai> automatically invoking diff -u or maybe even diff -ubBiw or
Kai> something like that (that is, whitespace differences are usually
Kai> not interesting).
This is moving in the right direction, but doesn't quite go
far enough, see my mail in another htread for more detail on a
possible implemetation (I think we should determine what we want
before we start talking about how to implement it)
In short, generate rules *snippets*, and include either the
snippet, or a user modified version, the differences acn then be
isolated and separated into sections (corresponding to each snippet)
Kai> This enables the maintainer to easily check what that update
Kai> does, and decide what he wants to keep, and what he wants to
Precisely. But breaking it up into snippets allows a finer
granularity about what to keep and what to junk.
>> And if you're worried about them not realising their package is
>> going to break, well, they should be reading the changes files if
>> they're installing the new versions. ;)
Kai> They first need to be aware that the version has changed. Imagine
Kai> a multi- developer machine.
I find shoving this off to the developer unacceptable.
Manoj Srivastava <url:mailto:email@example.com>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
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