Re: [AD] Data file directory

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Tim Bird <tbird@xxxxxxxxxx> writes:
> All modern Linux systems include package managers which track file
> locations, library dependencies, and other items, for each of the packages
> on the system.  It is trivial to eliminate a packaged application from a 
> Linux system.  The two most popular forms of packages are debian packages
> and RPMS.  It is not entirely the case now that all programs for Linux 
> come in packaged form, but most do.

True, but we certainly can't count on that. There will be a lot of game 
developers who don't have a clue how to make a nice packaging of their work, 
and even for those who are able to turn it into an RPM, plenty of users will 
still prefer to download a tarball version. I don't have the Unix background 
to really know what I'm talking about here, but my experience of those "fun" 
interactions between the Windows registry, c:\windows\system directory, and 
uninstall.exe, are sufficient to make me a huge believer in having a single 
tree per program so I can just "rm -rvf" the whole thing :-)

There is also a case for saying that in the case of a user who doesn't know 
how to make a clean distribution package, it is a good thing if all their 
files are left nicely in one location, while if they do understand how to 
build an RPM that will uninstall cleanly (including wiping stale config 
files, etc), that person certainly doesn't need a lib to help them with 
coding the file locations, given that they still have to specify all that by 
hand for the package manager in any case!

> Requiring users to install things under their own directories is pretty
> bad. Allowing it is OK.

Very true. We can't dictate policy about things like this, because a) people 
hate libs that do that, and b) it would be a disaster if a single program 
wanted to use two libs that both tried to dictate a different policy! But we 
can certainly try to predict what are the most likely things that people 
will want to do, and make that as easy as possible for them.

> I think what George was looking for was something that would abstract to 
> the developer the path handling, so they wouldn't have to have special 
> case code to deal with the platform. But this requires that everyone learn 
> a new abstraction.  Not necessarily bad, but I think it's unlikely to be 
> used.

This seems to come down to whether learning and using the abstraction would 
be easier than just putting an ifdef around the code in question. I could 
easily go with either point of view on this: on the one hand, conditional 
code inclusion is really ugly, but on the other, those Allegro calls would 
be totally opaque to someone not familiar with them, while different 
sections of paths for each OS is very obvious to read.

There is certainly no harm in including these routines, though: nobody has 
to use them, after all. So if somebody who groks the finer points of the 
FHS/LSB wants to suggest what the code should be, by all means go ahead...


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."