Package creation automation
Hi,
Could we come up with what we feel are desirable
goals/features of such a package? The popularity of debmake (yes, I
use it too, except debstd) leads one to believe that its features may
not be a bad place to start from. A general wishlist would be a good
place to start develop a reuirements document 9we can then step to
wrangling over implementation: I have some ideas using make snippets,
and I think I see a way to imlement everything I am stating below, so
this is not a mere pie in the sky [where did that phrase come from,
anyway?])
Desirable feature (not in any particular order)
a) The package would need to create templates of debian/* files
(debmake does this pretty well already). Idea: Would a more
interactive shell script that asked questions about the package
and created more, umm, complete templates (like section/priority
in control file, Descriptions, etc) be desirable?
b) Ease handling of debian/changelog (dch meets my requirements of
ease of use)
c) Release package after comparing md5sum (like debmake's release
tool does). Echo actions taken as they are being taken (release
does this, almost). Have a -no-act option, to see what the
package would do. (I'd prefer to be told what it is doing when it
says announcing to debian-devel-changes [command being run])
d) A todo list manipulator (not named todo ;-) (nice, but not
essential)
e) A package checking tool (like deblint). Announces steps being
taken (and what the test is), and the result thereof (pass,
failed, reason).
f) A creation time package (by this I mean the package is run while
the user is creating the rules file, not everytime the binary
target is invoked) that does things that debstd does, with
these changes:
i) Works at creation time, and produces rules/scripts etc that
maybe studied at leisure.
ii) have a no act option, so one may see *exactly* what
commands are executed when we say ./debian/rules binary.
iii) The user may easily override parts of what actions are
taken, and modify them (customise actions), and not loose
them the next time the utility is run.
iv) Have variable user controlled verbosity levels (nice, but
not essential)
Michael Alan Dorman has an alternative, and I stole some
concepts from this proposal (I delibrately left out implementation
specific details, since I want this to be a requirements phase, and I
don't think that the package meets all the requirements we may
generate).
I would not like to see a run time tool to do mysterious
things behind the scene.
I would also like to break up the monolithic tool like debstd
or Michael's alternative: I'd like things like mkdeb-shlibdeps or
mkdeb-instman, mkdeb-inst chlog, mkdeb-instdocs, mkdeb-gzipman,
mkdeb-gzipdoc, Where I could add or subtract files, use the defaults,
or totally override the selection of the program. (This is likely to
be controversial ;-)
All these programs should be idempotent, auditable, and
restricted in their actions (prferably limited to only modifying
files in one directory?)and not blow away user changes. They should
probably not require anything not in the current base packages (no
prolog ;-).
manoj
Ideas from Michael Alan Dorman
=====================================================================
* Basic foundation
Creating deb files consists mainly of making sure you have two
different sets of files in the right places---the debian files and the
program files.
Thus, the intent of any "package assembly tool" should be to give the
user a variety of simple, easily understood "transformations" (I've
been reading about DSSSL a lot lately, does it show) that help her
automate (and therefore presumably simplify) the process of getting
those files in the right place.
* Debian Files
The debian files are of two primary types---all-deb files and
single-deb files.
In other words, some files, like debian/control, are used during the
construction of all deb files that come from this source package,
while other files, like substvars, are (or should be) specific to a
particular deb file.
One obvious way to make the job of managing the debian files easier is
to use the directory structure to separate nonspecific files from
specific files, and files specific to one package from those specific
to another.
Thus, my utility, and I think common sense, dictates a simple
structure:
debian/
package1/
package1-dev/
package-bin/
Files common to all outputs, including rules, control and no doubt
others that I don't remember, all sit in the /debian directory.
Other files, including conffiles, shlibs, etc, are put in the
subdirectory corresponding to the name of the deb file for which they
are intended.
The utility takes care of dropping these various files (including the
processed control file, etc) into the right place. It insures they
have the correct permissions.
* Program files
The program files, on the other hand, each belong to a particular deb
file.
--
"I just couldn't convince Texans that Dukakis was Greek for Bubba."
Lloyd Benson
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: