Re: RFC: Package build automation tools (debmake replacement?)
On 28 Feb 1997, Manoj Srivastava wrote:
> However, not all the developers can be on the dpkg re-development
> team, for the reason of sheer numbers, or issues with time commitment,
> skill, or predeliction. Some of that number could possibly assist in a
> parallel effort to refurbish debmake, and this is what this effort is
> about.
I'm not sure this is actually the effort which I was trying to take part
in; my understanding was that we were trying to produce a tool to make
package build easier. `Refurbish debmake' makes it sound like all we're
trying to do is to improve debmake, and seems to rule out the possibility
of starting again.
Also, I wouldn't be involved in the dpkg effort anyway, except very
peripherally, because (a) I don't really understand it well enough, and
(b) I think this is at least as important, if not quite so urgent.
> It would be preferable to have an open design and development process
> that works n the basis of some kind of consensus, with deadlock
> breaking the task of the VP engineering, I think.
I'll go with this.
> I am just an interested developer, concerned about debmake, which,
> IMHO, despite being a wonderful package, could do with a few
> enhancements. Christoph does not have a major amount of time right
> now, and I wrangled reluctant blessings from Bruce and him (which is
> *not* a charter) to incorporate stuff if I actually manage to come up
> with an improvement ;-)
Again: are we really trying to improve debmake? Or to (possibly) start
again, making a tool to do the same job but possibly in a completely
different way? This is unclear.
> 1.2. The scope of this endeavor
> === ===== == ==== ========
>
> We are trying here to develop package build automation tools, or, in
> other words, a helper tool suite for the package developer, somewhat
> like debmake does currently.
This seems to answer my points above, but the document is not then
consistent. Can I suggest that you change the paragraphs quoted above?
[For my peace of mind, if nothing else :]
> ---------------------------------------------------------------------------
> 2. Wish lists and other requirements
> ____ _____ ___ _____ ___________
> ==== ===== === ===== ============
>
>
> Finally, here is the current requirements list, in no particular order
> (I have tried to order it partially from the general to the specific)
>
> 1. Make it easier to make a package from scratch
>From scratch being given the upstream tarfile?
> 2. Make it easier to keep a simple debian/rules file up to date, by
> automating a lot of it in a transparent manner.
>
> 3. Make it easier for packages to track standards.
>
> 4. Create an intelligent template
I think this is implied by 2 and 3.
> 5. Create installation script templates
>
> 6. To the greatest extent possible, packaging policy shall be
> plemented by the packaging system.
Yes please!
> 7. Helper programs to automate various aspects of the process. (These
> may or may not be run time tools)
>
> 8. A lint-type tool which checks the constructed package.
>
> 9. Consult a configuration file which can modify the action of the
> tool (guide the creation of templates, for example). For simple
> packages, it may be enough to create such a configuration file, run
> the tool, and create the package. (implementation note: mention has
> been made of M4, Autoconf, Automake, and dist, as well as RPM spec
> files; we could throw in lex/yacc for completeness).
>
> 10.
> On the same lines, maybe there could be a policy file that should
> be looked at, to guide the action of the tool.
>
> 11.
> An automated tool for uploading packages
>
> 12.
> Automatically install DEBIAN files
>
> 13.
> The output of the tools should be audit-able.
If we take the case of, say, debstd, then the output of the tool is a
package, which is clearly auditable. Do we not want the *actions to be
taken on package build* to be auditable? In some cases, this is the
output of the tool; in others, it isn't.
> 14.
> The user may easily override parts of what actions are taken, and
> modify them (customize actions). This should not be an all or
> nothing option, finer granularity than that is desired.
How fine? I think all the proposals so far have split off, for example,
processing of executable files from the rest. Is it fine enough to be
able to say `get your sweaty little mitts off my executable files,' or do
we want it even finer than that?
> 15.
> The utilities/helper tools should be limited in their actions
> (preferably limited to only modifying files in one directory? And
> possibly subdirectories thereof Under no circumstance should they
> modify anything outside the Debian subdirectory except possibly
> /tmp No mucking in system directories
Yes, but are you saying you want to enforce this in some way? Or just
that this is how it should be?
> 16.
> There should be a no exec option, which should not require super
> user privilege to execute
Can we not have a `dummy build' option, which allows a package build as
non-root, but creates a non-installable package, but one which can be
unpacked with dpkg-deb and poked around with a bit?
> 17.
> If at all possible, the commands to be run should also be available
> statically (that is, in a file somewhere), and not only available
> inside an executable image.
Um ... you mean, if the commands to run are a shell script, you want
another copy with no executable bit? ;) I don't really understand this.
> 18.
> The tool should preferably not depend on anything not in the base
> section.
>
> 19.
> There should be no requirement that the tool be installed on a
> system in order to build a package from the sources even if the
> developer had used the assistance of this tool..
Why? It's not as if it's going to be particularly big, or interfere with
the operation of the system in any way. And yes, for a compiler-type
tool, this would work; for a helper-type tool, it might be possible. But
I'm really not convinced that this is useful, and in many cases it would
require having a lot of duplicated information in the packages.
> 20.
> Either automate, or provide hints and templates to install common
> files like info, documentation, cron, init, etc.
>
> 21.
> Either automate, or provide hints and templates to compress
> documents and man pages (ignoring whatever files, for example HTML
> files, that the current policy says should be exempted, this also
> includes file size criteria)
And anything else which happens to be in policy at the time ... this is a
subset of 6, IMHO.
> 22.
> The tools, especially the update tool, if different from the
> initial template creation tool, should be idempotent, and by no
> means loose user configuration.
But we may want to restrict the places the user can edit (see Ian
Jackson's post).
> 23.
> Merely installing a new version of the package should never break a
> package build process. This takes precedence over propagating new
Certainly.
> 24.
> The preference is for automation of routine tasks, to the extent
> that it does not make the rules/script too complex for easy
> auditing.
As opposed to what?
> 25.
> It would perhaps be preferable to have this tool broken up into
> parts, which could then have alternates or additions over time,
> permitting developers to tailor the help tools used for the package
> (a share library searcher is not required for a .pm only package,
> or a pure lisp add-on). If so, there should be a wrapper that
> calls a default set in sequence so that the ordinary developer does
> not have to cope with all these tools. Example: dpkg-buildpackage.
> Even if this is not done immediately, the design should be flexible
> enough to allow this development.
I'm not sure I agree with this; if we use external tools, they should be
called individually, according to a config file or debian/rules template
or whatever. Providing a wrapper like this seems to me to be a waste of
time, certainly with all the implementations we've come up with so far. I
do think it's an implementation issue.
Hope at least some of this is helpful. I know a few of the comments are
rather nit-picky, but that's just me. ;)
Cheers,
&E
--
Andy Mortimer, andy.mortimer@poboxes.com
http://www.netforward.com/poboxes/?andy.mortimer
Finger asm21@asm21.emma.cam.ac.uk for PGP public key
--
I am weak, but I am strong;
I can use my tears to bring you home.
Reply to: