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

Re: Possible framework for `debmake replacement'

>>"David" == David Engel <david@sw.ods.com> writes:

David> Note that I'm not saying that everything *must* be in one file,
David> just that it *can* be.  If I ever said otherwise, it was
David> unintended.

 Ok, as long as this is not a requirement, I'll shelv debate till we
 get to implementations.

David> I think we have a philosophical difference here.  I agree that
David> the process should make it *easy* for you to modify things, but
David> not by allowing you to pull out it's internals and customizing
David> them to suit your needs.  This would severely restrict the
David> ability to change those internals as the need arises without
David> risking breaking every package that uses those internals
David> directly.

	Not necessarily, if the process was *designed* to have parts
 of it modified. I have posted one posible implementation before, but
 I'm reluctant to be held to just that; I just aver that it is
 possible to change the snippets without breaking packages. The way I
 envisage it, the package would never break just because of an

	In fact, once the automated part is finalised by the
 developer, it would remain so; upgrading the debmake like package
 *should never* break a package (this is not true at the moment).
 Only delibrate action will change the rules file behaviour; and even
 then we should not blow away the maintainers changes. (Of course,
 when you make this delibrate effort, you should audit everything to
 make sure nothing broke, but at least everything is laid out before
 your eyes, and there is nothing hidden insode a run time script in a
 language [which I love dearly] that looks like animated line noise
 with a purpose).

	I think that in all but the simplest packages the best we can
 do is provide templates for the developer that can be modified
 easily, hints for the hard/variable parts, and take out the drudgery
 of packaging, I just don't believe we can sweep a magic wand over the

	Is not ``severely restricting the ability to change those
 internals as the need arises without risking breaking every package
 that uses those internals directly'' satisfy you? 


 Try to be the best of what you are, even if what you are is no
 good. Ashleigh Brilliant
Manoj Srivastava               <url:mailto:srivasta@acm.org>
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

Reply to: