Re: Possible framework for `debmake replacement'
Please Note: I am not David Engel, I do not speak for him, etc., we
just seem to feel very similarly, and based on past remarks of his, I
think I know what he's getting at. I could be wrong.
Manoj Srivastava <srivasta@datasync.com> writes:
> 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)
I don't think David's necessarily limiting himself to debmake
here---he's really questioning some assumptions about how the
packaging system is supposed to work, and what its interface with and
expectations of the maintainer should be.
> David> The build process shall be controlled by a single configuration
> David> file.
> Could you elaborate on this, please?
I think David's thinking in terms of the .spec file for RPMs. I
couldn't say whether he's thinking of incorporating all the various
files we already have into one big file from which the appropriate
snippets would be snipped and placed in the DEBIAN/ directories, but
it's a possibility.
> 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.
Actually, I don't think he's necessarily thinking about using that to
generate the rules file, but I agree it has potential.
What I think he's talking about, though, is not having to fill your
debian/rules with cp's and mv's and ln's and so forth, but instead
being able to operate at a "high level" when it comes to specifying
these things.
I keep wanting to use the term "gesture" to describe it.
> 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?
In other words, I suspect, they should be official parts of
dpkg---maintainers could use them with no risk of causing problems
with people doing new ports or whatever.
> 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.
I don't think he means that it should guess, but that the user
shouldn't have to worry with creating all those individual files.
I'm pretty certain David's taking some of his cues from RPM's build
process, where, in theory, you just need a .specs file and you've got
a package. I've looked at .spec files, and I personally don't find
them pretty or easily intelligible. But, I think the idea of having a
"meta process" which allows you to describe the packages instead of
worrying about cp'ing individual files is very worthwhile.
I think David's thrust, and I think it's an important one, is to make
package building easier, rather than pure or orthagonal or modular or
whatever. Sort of the Perl theory of make easy things easy and hard
things possible, except I think he wants the hard things to be easy as
well.
Before everyone decries this lack of mathematical purity, let us note
that if we build the tools right---and test them carefully---then the
less the maintainer does, the more likely it will be done right.
Mike.
--
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: