Re: Possible framework for `debmake replacement'
Hi,
>>"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
upgrade.
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
process.
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?
manoj
--
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: