Re: Possible framework for `debmake replacement'
Hi,
>>"Andy" == Andy Mortimer <andy.mortimer@poboxes.com> writes:
[Basic proposal trimmed]
Dou you mind if I incorporate this into the requirements
document I have started? I already have stuff from Michael Dorman in
it, I think we should consolidate.
Andy> Details -------
Andy> The core of this package would be the helper program(s), which
Andy> for the sake of this proposal will be a set of programs with the
Andy> prefix `dmake-'. So for example, dmake-binary would install one
Andy> or more binaries, according to the current standards (eg,
Andy> stripped). A possible, probably partial, list of these follows:
I think I'd prefer the helper program to insert commands into
the rules file (not necessarily by editing the file in place).
Separate programs also make it very hard to see what would happen if
I just say ./debian/rules -n binary.
I like the creation of categories you have advocated, I'm not
sure I like the categories exactly as you have put them.
Commentary on details:
Andy> binary: installs executable binaries
Hmm. I think for most packages the developer would have to
tell which binary file to install, and where to put it. I think it
would be better to have a make rule like:
install_file= /usr/bin/install -o root -g root -m 644
install_program= /usr/bin/install -o root -g root -m 755
install_game= /usr/bin/install -o root -g games -m 2755
make_directory= /usr/bin/install -d -o root -g root -m 755
And we just call
binary-arch:
...
$install_program) ./src/linux/debian/my_biary $(TMP)/usr/bin
No need for a separate program, IMHO. Also, the rules are
clear, and in place, I don't have to go looking for what the program
does, and we don't have to worry about how to implement a no-act
option.
Andy> library: installs shared libraries
Hmmm, a similar solution as above?
Andy> doc: installs documentation. This would take a switch to specify
Andy> the type (info, manpage, etc), and would install in the
Andy> appropriate place and compress if necessary
Andy> (overridable). Alternatively this could be split into seperate
Andy> programs for each type. This would *not* generate, for example,
Andy> calls to install-info in the relevant installation scripts; this
Andy> is the responsibility of the template and the package
Andy> maintainer.
Hmm. ok.
Andy> instscript: installs preinst, postinst, etc scripts. There is no
Andy> provision for generation of these; this should be done by the
Andy> template at package creation time.
These are standard enough that we can easily fold this into a
standard rule. We definitely don't want to run this all the time.
Andy> cronscript: installs /etc/cron.* scripts in the same manner.
Andy> data: installs data in /usr/lib/packagename, or somewhere
Andy> else. By my understanding, no processing should be done on this
Andy> data, although it may for instance be md5checksummed at this
Andy> stage.
install_data := $(INSTALL) -m0644
$(install_data) $(DATAFILES) /usr/lib/$(packagename)
I don't think we can automate this, there are too many possibe
destinations (site-lisp, site-perl, games, etc), and if we have to
supply source and destination, we don't need a external program.
Andy> All these programs install by default in the /usr hierarchy
Andy> (/usr/bin, /usr/lib/packagename, /usr/info, and so on), although
Andy> this should be overridable using a commandline option. For
Andy> multiple-binary packages, an option to specify the package being
Andy> built could be added.
This is complicated. It would be far simple to have the
helper programs produce rules snippets which do not over write user
modifications, yet are out in the open to audit and modify.
Andy> --
Andy> Then we have a rules template. We will assume here that this
Andy> template is intelligent, and therefore an executable, named for
Andy> example dmake-rules. It should also be the case that the package
Andy> is compilable without the prescence of this template, although
Andy> the helpers above should be present on all systems wanting to
Andy> compile packages. This template must also be idempotent, and so
Andy> and configuration used by the intelligent part of it should be
Andy> stored, for example in the debian directory. If the maintainer
Andy> changes any of the code in debian/rules produced by this
Andy> template, it is her responsibility to either (a) not run it
Andy> again, or (b) clean up herself after rerunning.
Mostly, yes. But this program should not blow away user
changes, and should incorporate the helper programs to update the
template as a routine event (yes, Virginia, this can be done).
[I don't like the appelation ``inteligent''. I have just re-read Mary
Shelley's works]
Andy> The idea is that the volatile bits of code should be in the
Andy> helpers above, and this template should be more-or-less static,
Andy> providing a base for a new package. In this respect, it acts a
Andy> little like debstd, except that it is run once at package
Andy> creation time, and is from then on basically obsolete.
I don't see the need. I want to make the helpers update the
template, but only when invoked by the user *to update the template*,
not while making a new version of the package.
Andy> There should also be another template along similar lines, for
Andy> example dmake-scripts, which constructs things like sample
Andy> preinst and postinst scripts given configuration files similar
Andy> to debmake's. Again, no provision is made for it to be run after
Andy> these scripts have been modified.
Too strong a restriction.
Andy> These two templates are split to allow easier rerunning of one
Andy> without the other. However, some of the configuration files may
Andy> be shared, for example specifying GNU info documents to be
Andy> installed.
I am unconvinced we would need two templates with the changes
I have been suggesting.
Andy> Conclusion ----------
Andy> This seems to me to provide a useful way of hiding some of the
Andy> implementation details, which keeping them (a) accessible and
Andy> (b) not too well buried. It still needs a bit of work---in
Andy> particular, the config files should be defined, and the exact
Andy> steps done by the template, and it would also be nice to be able
Andy> to run it on an edited debian/rules file etc, but it should
Andy> provide some food for thought.
Andy> I hope this turns out to be useful. I would like to make it
Andy> clear, though, that I am *not* volunteering to actually write
Andy> this tool, but I had some ideas and it seemed stupid not to
Andy> share them. If there're more comments I'm quite happy to look
Andy> after this document, though, if people think that is worthwhile.
I will so volunteer, if Christoph, Ian, and other owers that
be are too busy to do so.
manoj
--
Interestingly enough, since subroutine declarations can come
anywhere, you wouldn't have to put BEGIN {} at the beginning, nor END
{} at the end. Interesting, no? I wonder if Henry would like
it. :-) --lwall
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: