Re: Possible framework for `debmake replacement'
On Feb 24, Michael Alan Dorman wrote
> 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.
You were pretty much dead on.
> 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.
Right!
> 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.
Pretty close. IMO, it should be *possible* to combining all the
various (usually little) files into a single one. For exmaple, if I
only need a 5-line postinst script, I might put something like the
following into the .spec-like file:
Postinst:
<in-line-contents-of-postinst-script>
However, if I need to do something complicated that needs a 200-line
postinst script, I might put something like the following into the
.spec-like file:
Postinst-File: <path-to-actual-postinst-script-file>
> 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.
Yes, yes, yes!
> > 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.
Right. I want be able to say "Here, I'm providing these types of
files in this package. You do the rest to make sure they get
installed or removed properly when the package is installed, removed,
purged, etc."
> 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
Right again. Other cues come from debmake and elsewhere.
> 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,
I couldn't have said this better myself.
> except I think he wants the hard things to be easy as well.
Maybe hard things easier.
> 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.
Yes.
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: