On Mon, Mar 13, 2006 at 11:18:15AM -0500, Justin Pryzby wrote:
> > > > > If that is the case, install to to debian/<package> (replacing
> > > > > package with the name of the binary package) instead of debian/tmp.
> > >
> > > When using debhelper, dh_install will do that for you sortof
> > > automatically. If you have defined a binary package foo in
> > > debian/control, and there is a file debian/foo.install, then putting
> > > this in dh_install:
> >
> > I did not have a debian/foo.install. I am wondering, if I need to all all
> > files manually in debian/foo.install... So I would put the files in
> > debian/tmp (using the DESTDIR variable in the makefile) and the copy it
> > from debian/tmp to debian/foo by listing all files in debian/foo.install
> > and running dh_install? Installing directly into debian/foo looks like a
> > shortcut to me and listing all files in debian/foo.install looks like
> > tedious work to me, but maybe I miss something...
You can use wildcards in the *.install files. For example, you can put a line
with "debian/tmp/usr/bin/*" (or just "debian/tmp/usr/bin") in it and it will
recursively install all those files into the package.
> No; if possible, you probably want to $(MAKE)
> DESTDIR=$(CURDUR)/debian/package/ install, and then add/remove some
> special-case files from there. But sometimes there are just too many
> files to do this well, expecially for splitted packages ("multiple
> binary") in which case it can make sense to install to ./debian/tmp/
> (or any other arbitrary directory, tmp has no relation to the previous
> DH_COMPAT=1 use of tmp), and then use foo.install to the real
> locations.
AFAIK, there can be a few reasons to use *.install files instead of directly
installing things into the package directory:
- Multiple binary package. One source produces multiple binary packages, and
the files must be distributed over them. Installing in one of the packages
and moving files for other packages out seems hackish, although it would
work as well. dh_install is more clean in such a situation IMO.
- Detect upstream changes. In that case, use --list-missing (or better,
--fail-missing), possibly with -X to explicitly say that some files should
not be installed (by dh_install: when installing manpages with
dh_installman, --*-missing will not know about it for example).
- Have the same rules file everywhere. I don't think this is a very good
reason, but some people may like the idea of not having different rules
files for different packages.
Note that all of these reasons are a matter of taste: if you want to use
dh_install, go ahead. But if you prefer manually moving files around, or
directly installing into the package directory, there's nothing wrong with
that.
> > > debian/tmp/usr/bin/bar will install that file to the same path, minus
> > > "debian/tmp/", if it is at the start, in debian/foo. Of course there's
> > > nothing against doing that by
> >
> > Hmm... what you do mean with if it is at the start, the start of what?
> I guess this is the stuff talked about in dh_install(1).
Yes.
> > > In fact, your build must have warned you about all the files in
> > > debian/tmp, because you use the --list-missing option.
> This seems like a good idea to use ..
>
> There's also a bug which I can't find right now requesting that ./tmp/
> be empty otherwise some command triggers a warning/failure, the idea
> being that upstream changes can be more easily detected.
As far as I know, that's what --fail-missing is for. It wouldn't work with
dh_install anyway, since that copies the files. So they will still be in
debian/tmp after they are installed in the package directory. I suppose this
was a request for an extension to dh_movefiles (which is now deprecated).
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
Attachment:
signature.asc
Description: Digital signature