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

Re: Package creation automation


On 20 Feb 1997, Manoj Srivastava wrote:

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

Agree, but debian/rules should be kept quite simple to don't lost new 

>  b) Ease handling of debian/changelog (dch meets my requirements of
>     ease of use)

Totally agree.

>  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])

Right! I lost so much time to figure out what release really does. But 
I think I will appreciate it if my computer was online. Can we request 
that the -no-act option (or another one) will create a subdirectory with
special instructions (or script) to done on a specific machine. Something
like send this file with scp at master.debian.org; post this file to 
this mailing-list. TFM are not always clear, or sometime we just need a 
good example to understand ;) 

>  d) A todo list manipulator (not named todo ;-) (nice, but not
>     essential) 

Request: Bugs management tool. :)

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

Nice, keep dpkg-dev to build and debmake to ~help~ *creation*. 

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

Is it ;) That break you're own proposition. Some people prefer to catch 
the source (may be from the original upstream), build the package and 
then install it. They are already too much tools in dpkg-dev. People must 
can build each package with a ~minimal~ (relatively to the debian parts 
of a package) debian installation. If they can build a debian source 
on a redhat or slackware installation, this could be great. May be 
can we put it as a requirement (only source building including putting 
them in debian/tmp or whatever destination, not package building)?   

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

Definitely yes.

[some good other stuff snip]

It seems that not that much work need to be done. debstd are the main 
piece to be change. In place of a do-anything tool, it looks like it must 
be transform to a configure or generation tools and not be use directly 
in debian/rules file.

Whatever, Christoph already does a great job and I don't think we need to 
redone an entirely new debmake package. We must clarify the policy about 
what debian/rules can done and with which tools. The policy already say 
it in a way but all this stuff about debmake prove they are still some 
clouds in the sky. ;)

- ---------------------------------------------------------------------
 "It's just zeros and ones, it cannot be hard"
- ---------------------------------------------------------------------
Fabien Ninoles aka le Veneur aka le Corbeau     
E-mail: fab@tzone.org
WebPage: http://www-edu.gel.usherb.ca/ninf01 
E-mail me with "get pgp key" in the subject to get my public key
PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99  4F 80 2D 2D 1F 85 C1 70 
- ----------------------------------------------------------------------

Version: 2.6.2


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: