Re: Package creation automation
-----BEGIN PGP SIGNED MESSAGE-----
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
maintainers.
> 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).
Good.
> 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
- ----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMwx4IVX6fc7jcjhFAQHtoQP/TbWuBd2/Ewa5TFS4I+er3cmxmv712hfP
CxRBiHBfk8jDEETkKqdlpEFiLUOMV9886M9uC9xf8nYfKViHiR6QskcGeu59DhY9
2QNvcRA3UTWCOA+2MT3XqwBsMlQPLZq31c1UJp4D9zJNeG3HNps3gnoDK+QRglg4
NqnaTCXL+U8=
=kaew
-----END PGP SIGNATURE-----
--
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: