Re: Possible framework for `debmake replacement'
Hi,
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).
>>"David" == David Engel <david@sw.ods.com> writes:
David> On Feb 21, Manoj Srivastava wrote
Manoj> Can we get back to the requirements process now?
David> OK, here is my initial list of requirements. At this point, I
David> am only focusing on the package generation aspects. I will
David> leave the package selection aspects to others for now.
David> Furthermore, although the package installation/removal aspects
David> could use some improvement, they are satisfactory don't need to
David> be changed for the time being.
IMHO, selection/installation/removal are the precinct of the
dpkg rewrite, not the requirements for the debmake replacement.
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)
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.
David> The build process shall be controlled by a single configuration
David> file.
Could you elaborate on this, please?
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.
David> It shall be possible to generate simple binary packages (those
David> that do not require any custom installation/removal support)
David> with only a configuration file.
Like the hello package? Hmm. Ok, though this maybe ambitious
-- but we'll never know unless we try. Agreed.
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?
David> To the greatest extent possible, packaging policy shall be
David> implemented by the packaging system.
Agreed.
David> The build process shall automate the handling of configuration
David> files, e.g. conffiles, SYSV init scripts, crontabs, services,
David> etc.
... to the extent possible. Agreed.
David> The build process shall automate the handling of documentation
David> files, e.g. copyrights, text files, examples, info files, HTML
David> files, etc.
... to the extent possible. Agreed.
manoj
--
"I never let my schooling get in the way of my education." Mark Twain
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: