Re: Possible framework for `debmake replacement'
Hi,
>>"Michael" == Michael Alan Dorman <mdorman@calder.med.miami.edu> writes:
Michael> I don't think David's necessarily limiting himself to debmake
Michael> here---he's really questioning some assumptions about how the
Michael> packaging system is supposed to work, and what its interface
Michael> with and expectations of the maintainer should be.
Oh. I was just confused by the subject line, then. ;-)
David> The build process shall be controlled by a single configuration
David> file.
>> Could you elaborate on this, please?
Michael> I think David's thinking in terms of the .spec file for RPMs.
Michael> I couldn't say whether he's thinking of incorporating all the
Michael> various files we already have into one big file from which
Michael> the appropriate snippets would be snipped and placed in the
Michael> DEBIAN/ directories, but it's a possibility.
Umm, in this case, it is beyond the debmake replacement, and
should go to the dpkg/dselect thread.
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.
Michael> Actually, I don't think he's necessarily thinking about using
Michael> that to generate the rules file, but I agree it has
Michael> potential.
Michael> What I think he's talking about, though, is not having to
Michael> fill your debian/rules with cp's and mv's and ln's and so
Michael> forth, but instead being able to operate at a "high level"
Michael> when it comes to pecifying these things.
In which case I object strongly. One of the things that lead
to my current involvement is all the ``high'' level things happening
behind the scenes. I want an automatic process, which requires less
human involvement, but not necesarily a high level or opaque one.
I like to know what is happeining when I build
packages. Something that reads a run control file and produces
intermediate, human readable output that can be scanned as desired
is, as the vernacular goes, goodness. Direct, or runtime generation
of such output, is not.
Michael> 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?
Michael> In other words, I suspect, they should be official parts of
Michael> dpkg---maintainers could use them with no risk of causing
Michael> problems with people doing new ports or whatever.
If you-all really mean dpkg, this is out of the scope of this
requirements process.
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.
Michael> I don't think he means that it should guess, but that the
Michael> user shouldn't have to worry with creating all those
Michael> individual files.
And what I meant was, short of AI, it may be impossible to do
a complete job for all cases. As christoph has pointed out in the
past, debmake is *not* a magic wand, and there is no substitute for a
careful maintainer, and I guess there is not going to be.
Michael> I'm pretty certain David's taking some of his cues from RPM's
Michael> build process, where, in theory, you just need a .specs file
Michael> and you've got a package. I've looked at .spec files, and I
Michael> personally don't find them pretty or easily intelligible.
Michael> But, I think the idea of having a "meta process" which allows
Michael> you to describe the packages instead of worrying about cp'ing
Michael> individual files is very worthwhile.
This is moot. In theory, this sounds good; in practice ...
Michael> I think David's thrust, and I think it's an important one, is
Michael> to make package building easier, rather than pure or
Michael> orthagonal or modular or whatever. Sort of the Perl theory
Michael> of make easy things easy and hard things possible, except I
Michael> think he wants the hard things to be easy as well.
To an extent. To make hard things easy often entails making
them less powerful and less flexible as well. I have commented
elsewhere on what I think of this trend of glorifying spoon feeding.
Michael> Before everyone decries this lack of mathematical purity, let
Michael> us note that if we build the tools right---and test them
Michael> carefully---then the less the maintainer does, the more
Michael> likely it will be done right.
Yup. This *is* the year that HAL was born, after all.
manoj
--
"If you weren't my teacher, I'd think you just deleted all my files."
an anonymous UCB CS student, to an instructor who had typed "rm -i *"
to get rid of a file named "-f" on a Unix system.
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: