Re: debhelp

[Joey Hess <joey@kitenet.net>]

Todd Graham Lewis wrote:
> /usr should not be hardcoded; I'm making a bunch of packages for our
> server environment according to our local file system standard, and even
> though I've modified your debian/rules to reflect the use of /ms instead of
> /usr, your scripts do not reflect this.  For a good example of how to do this
> well, take a look at the debian/rules file for make.  At the top of the
> rules file, Manoj has:

This seems to be a different issue. We're not talking about a debian/rules
file here, debhelper is a set of programs that are designed to use data files
in /usr/lib/debhelper. This includes some helper scripts that I want off the
standard path, thus the path setting you mention. But that's not the only
place /usr/lib/debhelper is coded into the debhelper programs, anyway.

Debhelper is really a debian-specific thing, so I never really considered
location independance something that was necessary (after all, on a debian
system, all you have to do is comply with the fsstnd). I don't see anything
at all wrong with these programs having a hardcoded directory in them. After
all, they arn't only used in debian/rules files, people will occasinally run
them at the command line first, and in that case, they shouldn't have to
fiddle with enviroment variables to make them work right.

> It might be asking too much to have path-independence be a matter
> of policy, but I know that if it were, I could have gone home a few
> hours ago.  FYI.

Is perl -i.bak -pe 's:/usr/lib/debhelper:whatever:' dh_* so difficult?

I would be willing to make the source package substitute in the location you
want debhelper to use, at build time. That's about as far as I want to go
down this road. Good enough?

-- 
see shy jo


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .