Re: Possible framework for `debmake replacement'
Hi
>>"David" == David Engel <david@sw.ods.com> writes:
David> I don't think we should limit ourselves to just replacing
David> debmake. As far as I'm concerned, reworking some or all of
David> dpkg-dev should be considered as well.
I agree. But I can't do all things at once, and I am limiting
myself to debmake replacements. Bruce is putting together a team of
people to handle that, and I'm sure that team, when it forms, will
have their own requirements phase.
I want to get what people think are requirements for a debmake
like tool. This is not just talk or vaporware: I think we can push
this and create the ehancement to debmake, and will even volunteer to
lead coding (I'll of course defer to Christoph if he wants to do
this, but I fear that he may heve time constraints).
So I'm focussing on debmake like stuff, not dpkg-dev, ok? (I
don' want to get side tracked by a worthy enough cause like dpkg
improvement that I cannot commit myself to; any day now my employers
might jerk my leash and I'll be off again ;-)
David> I'm thinking of something alongs the lines of parts of RPM's
David> .specs file. My goal here is not to be like RPM. Rather, my
David> goal is to enhance ease of use. I would like to be able to
David> give a potential package developer a single, configuration
David> file, template and say "Here, take a look at this and fill it
David> out for your package. If your package is fairly simple, this
David> is all you'll need."
Hmmm. Let me think about this.
David> I'm talking about combining all of the "standard" debian/*
David> files (control, rules, changelog, etc.) and the myriad debmake
David> files into a single file. This doesn't mean that everything
David> has to be in a single file, just that in the simple cases, it
David> can be. Again, I'm thinking of easy of use here. In most
David> cases one file is easier to manage then 10.
I'm not sure I agree. A single file can tend to get
overwhelming (I managed several 10's of Ultrix machines once,
rc.local was ... daunting. You couldn't even share bits, since it was
just a huge monolithic file).
I think doing it this way would make any customization a
nightmare, in fact, since it is al so high level anyway, you probably
can't modify much of anything. I could be wrong.
David> You keep saying you want a utility that will spit out the "list
David> of commands" to be executed rather than actually executing them
David> so you can paste them into your own rules files and edit them.
Not in the default case. But if I do have to edit something,
I should only have to edit a part of the rules (not the take it or
leave it attitude of debstd or single megalith files). The process
should make it *easy* for me to change things, but not require me to
take any action unless I have to. No editing required for simple,
default cases.
David> I contend that this list of commands should be designed such
David> that they are applicable to all packages and shouldn't need to
David> be edited. Since the list is the same for all packages, they
David> shouldn't be stored in every package. This makes it easier to
David> change them when needed.
Right, but we are not talking about the very simplistic
commands that are common across packages anyway. Those should be
merged in with dpkg-dev and such. I don't want these common commands
in my rules file.
That is beyond the scope for this thread (please note the
subject).
manoj
--
And the crowd was stilled. One elderly man, wondering at the sudden
silence, turned to the Child and asked him to repeat what he had
said. Wide-eyed, the Child raised his voice and said once again,
"Why, the Emperor has no clothes! He is naked!" "The Emperor's New
Clothes"
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: