Re: Possible framework for `debmake replacement'
On 21 Feb 1997, Manoj Srivastava wrote:
> 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.
Go for it. I don't envy you the job. ;)
> 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.
The idea of the helper programs was that they were, in some way, hidden,
so that things like compression of docs could be added without any effort
on the part of the maintainer, but that they would be simple enough that
(a) in most cases, the effect would be obvious, and (b) if it wasn't,
five lines of shell script (if that) shouldn't be too difficult to
manage. Adding a --no-act option shouldn't be that tricky, though, but
would be harder to integrate with debian/rules -n.
However, reading through this, a thought occurs. ISTR somebody mentioning
makefile `fragments,' little pieces of makefile that you could include.
You, here, are talking about the same sort of thing. So: how about this
as a way to go? As you rightly point out, the fragment
--
INSTALL=/usr/bin/install
install_program=$(INSTALL) -o root -g root -m 755 -s
.
.
.
$(install_program) foo bar $(prefix)/usr/bin
--
should install a program with no problems. The docfiles are more
difficult; you'd probably have to create different macros for info, man,
etc. This isn't really a problem. The problem, so far as I can see, comes
with Makefile semantics. (Consider a complex command which we want to
pass multiple files to, for instance.)
So instead, perhaps, we can define *rules* in a file somewhere which can
be included in debian/rules with the include statement. Then all the
debian/rules file has to do is to assign dependencies to these rules, and
then make the binary target depend on them. So, for example:
-- rules file
install_doc:
install -d $(prefix)/usr/doc/$(package)
install $^ $(prefix)/usr/doc/$(package)
if [ -n "$(compressdocs)" ]; then \
find $^ -size +5K -exec gzip -9 $(prefix)/usr/doc/{} \;; \
fi
--
and then in debian/rules,
--debian/rules
include /usr/lib/dpkg-dev/rules.global
install_doc: changelog copyright
binary: install_doc
--
I can't promise to have the commands right, but this should give the
general sort of idea.
> I like the creation of categories you have advocated, I'm not
> sure I like the categories exactly as you have put them.
No, nor am I; they were more in the way of examples than a suggestion for
the final layout.
> 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.
No, in this case there is very little problem.
> 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.
You wouldn't run it all the time; you'd comment it out if you had none of
these scripts.
> 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.
But the whole point of the helper programs was that they didn't need to
change the debian/rules when the policy changed; if we use helper rules
as above, this wouldn't be a problem.
> 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).
Again, this is solved by the above rules ... I just didn't want to have
to invent a way to preserve changes at the same time. So I'm lazy. You're
right; we shouldn't blow away user changes, although the idea of the
template programs was that they were really only meant to be run once.
> [I don't like the appelation ``inteligent''. I have just re-read Mary
> Shelley's works]
;-) How about a DWIM template, then?
> 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.
No! The template is provided for the maintainer, for her own use. Nothing
should change it afterwards; this is the whole point of a template. If we
want to dynamically modify debian/rules, then call it a compiler, or a
constructor, or something. Then the helpers can be changed when necessary
(not that I would imagine they would be very often) to correct mistakes,
or to (say) compress manpages; the maintainer doesn't need to do
anything.
And if you're worried about them not realising their package is going to
break, well, they should be reading the changes files if they're
installing the new versions. ;)
> 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.
Or that I've been suggesting, for that matter ... especially if the
template is just that. A template.
> 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.
You're a better man than I am. ;) Or braver, at any rate. See what you
think of these suggestions, though.
Cheers,
&E
--
Andy Mortimer, andy.mortimer@poboxes.com
http://www.netforward.com/poboxes/?andy.mortimer
Finger asm21@asm21.emma.cam.ac.uk for PGP public key
--
It goes dark, it goes darker still; please stay.
But I watch like I'm made of stone, as you walk away.
--
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: