[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] Package build time config for installation directories.



>>"Ben" == Ben Collins <bcollins@debian.org> 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   <srivasta@debian.org>  <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



Reply to: