[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Package creation automation


	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,
	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

 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

	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 ;-).


		    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


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

 "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: