Re: Possible framework for `debmake replacement'
Mike did a pretty good job of answering this for me, but just to be
sure I'll do so myself anyway.
Aside to Mike: would you like a permanent job answering my email? It
would sure give me a lot more time to do other things. :-)
On Feb 24, Manoj Srivastava wrote
> I think we should distinguish between the build, or package
> generation, process (which involves the contents debian/rules file,
> and the dpkg* tools), and the debmake-like tools, which create the
> rules file.I think some of your requirements are focussed more
> towards the former than the latter (please correct me if I'm wrong).
I don't think we should limit ourselves to just replacing debmake. As
far as I'm concerned, reworking some or all of dpkg-dev should be
considered as well.
> David> The entire build process starting from Debianized source to the
> David> generation of source and binary packages shall be possible via
> David> the execution of a single, high-level command.
>
> Not the scope of debmake (a script using source-dependencies,
> and dpkg-buildpackage may be a step in that direction)
See above. Reworking dpkg-buildpackage is definitely in the scope of
problems I'm trying to solve.
> David> It shall be possible to execute the component steps of the
> David> build process individually.
>
> Ok, already present in the policy/programers guide to an
> extent about contents of rules. This should belong to the policy
> guide; the debmake replacement should adhere to the policy in affect
> at the time.
>
> David> The build process shall support the generation of multiple
> David> binary packages from a single source package.
>
> Again, this is policy.
Again, anything dealing with dpkg-dev, including policy, is subject to
rework.
> David> The build process shall be controlled by a single configuration
> David> file.
>
> Could you elaborate on this, please?
I'm thinking of something alongs the lines of parts of RPM's .specs
file. My goal here is not to be like RPM. Rather, my goal is to
enhance ease of use. I would like to be able to give a potential
package developer a single, configuration file, template and say
"Here, take a look at this and fill it out for your package. If your
package is fairly simple, this is all you'll need."
> David> To the greatest extent possible, the configuration file shall
> David> consist of a description of the source and binary packages
> David> rather a series of commands of commands to be executed to
> David> generate binary packages.
>
> debian/control? I think you are talking about something else
> here. Are you saying that the developer creates a .debmake file at
> the top level of the package source tree, and that is used by debmake
> and debstd replacements to direct generation of the rules file? This
> definitely has potential.
I'm talking about combining all of the "standard" debian/* files
(control, rules, changelog, etc.) and the myriad debmake files into a
single file. This doesn't mean that everything has to be in a single
file, just that in the simple cases, it can be. Again, I'm thinking
of easy of use here. In most cases one file is easier to manage then
10.
> David> To the greatest extent possible, the infrastructure needed by
> David> the build process shall be provided by and stored with the
> David> packaging system.
>
> Could you elaborate with a simple example of what you mean,
> please?
You keep saying you want a utility that will spit out the "list of
commands" to be executed rather than actually executing them so you
can paste them into your own rules files and edit them. I contend
that this list of commands should be designed such that they are
applicable to all packages and shouldn't need to be edited. Since the
list is the same for all packages, they shouldn't be stored in every
package. This makes it easier to change them when needed.
David
--
David Engel ODS Networks
david@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
--
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: