Re: Relocatable packages
This is really debian-offtopic. And debian-devel is crowded enough.
(it's also fhs offtopic). But I would like to have this discussion.
> On Wed, Jan 30, 2002 at 03:05:28PM -0500, H. S. Teoh wrote:
> > Of course, it can be argued that such paths shouldn't be hard-compiled
> > into the program -- and I'd tend to agree with that -- unfortunately, this
> > convention is too widespread and likely isn't going to change anytime
> > soon.
You are right. And the benefits are minimal.
On Wed, Jan 30, 2002 at 04:41:01PM -0500, Matt Zimmerman wrote:
> Please don't say "environment variables", as one variable per installed
> program is not workable. Determining the installation prefix
> dynamically from the path to the executable is evil, and breaks many useful
> constructs.
"environment variables", sorry. How about dividing paths in 2 parts:
- System-dir (/, /usr, /var, /usr/local)
- Datatype-dir (/lib, /bin, /doc, /etc/foo-1.3-1/somedata.dat)
I think the Datatype should be hardcoded, and the System-dir could be
some sort of $PATH. I mailed idea also to the fhs mailinglist some time
ago($ALLPATH).
You can always override anything with environment variables or
commandline options, that would be a user customization.
Hurd would probably shadowfs the systemdirs. I don't really know
anything about bsd unionfs, but that would probably union them.
but,
What are the benefits?
----------------------
- It allows users to override any configuration, data, binaries in
a consistent way.
- Users can install anything anywhere they want, and it works.
- System-dirs are easily added and removed. (/usr/X11R6 -> /usr)
The not-benefits.
-----------------
- not feasible, too much has to change.
- I'll be flamed by people who have to change their cide or
people who don't find it beautiful at all.
- It'll likely break well established standards.
I'm not expecting anyone to change their code based on this.
Please comment, or suggest what the right place is to discuss.
Gerhard.
Reply to: