Re: RFC: Package build automation tools (debmake replacement?)
Hi,
I have come with a revision of the RFC. This incorporates the
following changes. (The full document follows). I'll be away from
home for the coming week (visiting the frozen northlands); I should
be back on the 15th or so ..
manoj
-------------------------------------------------------------------------
Language clearing the scope and nature of this effort:
+ It make sense, at least in the phase of trying to define what we are
+ trying to build to not limit ourselves to any particular
+ implementation. However, deciding whether debmake would or would not
+ provide a suitable base to build upon should best be left to after
+ we decide the desirable features of the tool we are building. I
+ think requirements should define the implementation, not the other
+ way around. In other words, if the new tool has to be written from
+ scratch, so be it.
...
+ If this tool is easier to write from sctratch
+ rather than modifying debmake, well, that's the way the cookie
+ crumbles.
------------------------------------------------------------------------
- 1. Make it easier to make a package from scratch
+ 1. Make it easier to make a package from scratch. This should be
+ geared towards enabling a novice maintainer to build a Debian
+ packagewith the least effort possible and allow a gradual
+ development of package maintainence skills.
...
+ 6. The tools, especially the update tool, if different from the
+ initial template creation tool, should be idempotent, and by no
+ means loose user configuration.
+ 9. If multiple tools are present, then this package shuld bear in mind
+ name space pollution, and implement a common prefix, like dpkg has
+ done.
12.
+ Implement a version number that is kept with the templates
+ (debian/Rules/version), and the upgrade tool should not modify
+ anything unless the version number in that file is less than or
+ equal to the version number built into the tool -- on upgrade, the
+ version number is brought into sync). This will prevent accidental
+ downgrades of the rules. This may also be used to take special
+ actions for older versions of the templates, if needed.
...
18.
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.
+ nothing option, finer granularity than that is desired. The details
+ of this wil be decided partly in the implementation phase, but I
+ envisage that a typical binary target in the rules file may have
+ half a dozen _chunks_, any one of which maybe separately over-ridden
+ by the user.
+ 21.
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. Even in a shell or perl script, the
+ actual actions taken could quite likely be hard to determine (a
+ series of case statements would make tracing arduous).
...
25.
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). This should of course have to track
+ policy, and keep up with the changes.
28.
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.
+ enough to allow this development. Whether this is implemented
+ remains an implementation issue.
--
"Don't think; let the machine do it for you!" Berkeley
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
Reply to: