>>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
>> And we need to scope the effort invovled -- and whether the
>> effort has to be so heavy and deep reaching.
Ben> SO you would reather break this down into 3 or four solutions to
Ben> handle each type of case, thus making it more complex and less
Ben> general at the cost of saving you a few lines of code in
Ben> debian/rules? I mean how hard is it to do :
Umm, should I rephrase (perhaps english is not your first
language?) Scoping the effort involved does not necesarily mean
breaking down into 3 or 4 solutions. It means determining the amount
of work involved, establishing boundaries and limits, and figuring if
the effor involved in changing every package is worth the benefits.
Ben> +include /etc/dpkg-dev/dirs.$(DEBIAN_GNU_HOST_TYPE)
Ben> - ./configure
Ben> + ./configure --sbindir=$(sbindir) --bindir=$(bindir) --etcdir=$(etcdir)
Fine and dandy if you use configure. Now I am trying to
package globus, and they do not use configure. there is not clean
bindir, and they have a heirarchy of independent Makefiles, which
shall each have to be edited.
Have you really thought this throush?
Ben> - install -m 644 myREADME.txt debian/tmp/usr/share/doc/foo/
Ben> + install -m 644 myREADME.txt debian/tmp$(docdir)/foo
Ben> Is this really that much work?
Not this strawman case, no. But not all code is nice and easy
as all that to modify.
Ben> Any more so than implementing your relocation stuff in dpkg and
Ben> then worrying about people filing bugs on packages that can't be
Ben> relocated and trying to hack them up so they can?
Actually, we do need to study the feasibility of this ion the
first place, before it is made policy.
Ben> Even considering that not every package can be relocated
Ben> (gcc?). Your solution probably solves less than 10% of the cases
Ben> that I initially listed. Plus it requires someone to actually
Ben> implement this incredibly fragile things into an already fragile
Ben> package management tool.
And you would do what for the packages that can't be relocated
easily even at build time? And you want us to make all this effort
for systems that do not follow policy in the first place (no FHS)?
I am not convinced that this should be made policy in absence
of widespread practice. I suggest you go and create this system, and
create a bunch of packages that fdllow it (perhaps convince the
debhelper folks to follow suit). And then come back when this is
established practice, and there are tangible benrfits -- in my
personal opinion, you are asking for a lot of work to be done for
dubious returns.
manoj
--
I've always made it a solemn practice to never drink anything
stronger than tequila before breakfast. Nesson
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
