Linux packaging system and file hierarchy

[Patrice Dumas]

On Wed, Nov 12, 2008 at 01:28:05PM +0200, Eugene Gorodinsky wrote:
> 
> By letting the distro decide where to place files contained in the package
> we can solve the problem of maintaining multiple repositories of the same
> packages but for different distros, and also allow developers of different
> distros to create thir own file hierarchies - ones they think are better
> (for example a file hierarchy used by GoboLinux or a file hierarchy in the
> user's own language). I'm not sure how feasible that is, though. One problem
> I can think of is when a program tries to open it's own config file or image
> file etc. using a path like '../etc/program.conf' or
> '../share/program/image'. So my question is: what other problems does anyone
> else see in implementing something like that?

There are 2 different issues. On the upstream side, the builds have to
be set such that the paths can be overriden, both the install paths and
the paths registered in the applications, if possible using a consistent 
interface (notably ./configure and cmake). Many projects rely
on manual install or makefiles, and some hardcode paths. On the
packaging side, it may possible to specify the paths such that they may
be customized, and the packaging should be done such that the paths are
changed everywhere they should, either by using what upstream provides,
or by doing careful substitutions.

Speaking only about fedora, there is already some kind of independency
embedded in the use of rpm macros for packages, like %_bindir,
%_sysconfdir and so on and so forth. It doesn't cover everything (/sbin,
or /bin are not in macros), sometime the maintainers prefer to harcode
paths instead of using macros, especially when the upstream project
hardcodes the path, and, as you mentioned, relative paths will break if
the rpm macros are changed such that their relative paths are changed.

But it would indeed be an interesting experiment to rebuild fedora with
different macros and see what breaks.

Also keep in mind that some standards, that may be inherited from the
past dictates where some command line utilities (mostly POSIX utilities)
are to be located.

--
Pat