Re: Q: Location of copyrighted ROM images for emulator packages?
Hi,
>>"Branden" == Branden Robinson <branden@purdue.edu> writes:
Branden> [1 <text/plain; us-ascii (7bit)>] On Thu, Feb 19, 1998 at
Branden> 11:52:37PM -0600, Manoj Srivastava wrote:
>> I think that the proper path should just be /usr/local/lib/ or
>> /usr/local/lib/xtrs/ or something. Emacs adds stuff to the load
>> path like "/usr/local/lib/emacs/site-lisp".
>>
Branden> I think the user should be able to call the ROMs whatever
Branden> (s)he wants if the path to them includes /usr/local,
Branden> absolutely yes. If the ROMs are going under /usr proper,
Branden> then no -- the user doesn't get to control the names of
Branden> anything that goes there anyway.
Interesting distinction.
POLICY:
______________________________________________________________________
3.1.1. Linux Filesystem Structure
---------------------------------
The location of all installed files and directories must comply fully
with the Linux Filesystem Structure (FSSTND). The latest version of
this document can be found alongside this manual or on tsx-11.mit.edu
in /pub/linux/docs/linux-standards/fsstnd/. Specific questions about
following the standard may be asked on debian-devel, or referred to
Daniel Quinlan, the FSSTND coordinator, at <quinlan@pathname.com>.
______________________________________________________________________
The FSSTND states that /usr is deemed shareable, /etc is
machine local.
FSSTND:
______________________________________________________________________
4. The /usr Hierarchy
/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between
various machines running Linux and should not be written to. Any
information that is machine-local or varies with time is stored
elsewhere.
______________________________________________________________________
Branden> So, really, xtrs is itself limiting the user's flexibility in
Branden> naming the ROMs, at least for the search-on-startup method.
Branden> If we put the ROMs in /usr/local I have no business telling
Branden> the user what to call them, but then I might as well chuck
Branden> the search-on-startup compile options. Then the user will
Branden> have to specify a path to the ROMs every time the program is
Branden> invoked. (Sure, they'll just hack up an alias, but I still
Branden> see that as inelegant.)
I do not think it follows. Just tell them where the programs
look for it. If they don't like that, they can use the command line
option. They (or you) can write a wrapper script that looks at
/etc/something.conf and uses the cli as needed.
I think I do not like users overwriting things in /usr/lib. It
is verndor space, and I do not think the users should be messing
around in there.
Should you treat these roms as conf files then? if users are
to replace the original file with a local one, then an update should
not wipe their roms. Correct?
I would hate it if I got the roms myself, and there was an
upgrade to the package, and I upgraded, and my rom was replaced by a
zero length file.
So the zero length files have to be conf files. That answers
your question.
POLICY:
______________________________________________________________________
3.3.7. Configuration files
--------------------------
Any configuration files created or used by your package should reside
in `/etc'. If there are several you should consider creating a
subdirectory named after your package.
It is almost certain that any file in `/etc' that is in your package's
filesystem archive should be listed in dpkg's `conffiles' control area
file. (See the *Debian Packaging Manual*).
______________________________________________________________________
Branden> Another advantage to providing zero-length roms with a fixed
Branden> path is that I could possibly build an automated FTP grab of
Branden> the ROMs into the postinst (this would have to be an
Branden> interactive thing only, with a legalese question in it -- if
Branden> the install is non-interactive, the grab is skipped).
>> I think that when I fiddle with stuff on my machine it should be
>> pretty much in /usr/local only: firstly, that area is guaranteed to
>> be under my control, and it shall not conflict with future debian
>> plans (which may need the file name [unlikely in this case, i
>> know]) Thirdly, If I backup /home. /usr/local/, /var/lib/dpkg and
>> /etc, I can recover my machine fully (/usr is huge for me, and so
>> far, there is no local modifications there.
Branden> Yes, I am very much in sympathy with that backup strategy. I
Branden> don't back up as often as I should, but when I do, I backup
Branden> /etc, /var, /home, and /usr/local only.
>> In short, I hate fddling in /usr, local stuff should be in
>> /usr/local.
Branden> I agree.
Umm. so you think the roms shall go into /usr/local?
>> As you have not mentioned any arguments against that that are not
>> equally valid for your solution, I think you should stick with
>> this.
Branden> I think I just did... :)
Branden> I guess what I'm really saying is, I think I should put them
Branden> somewhere other than /usr/local. Given that, where should
Branden> they go? /usr/lib/xtrs? /usr/X11R6/lib/xtrs? /var/lib/xtrs
Branden> (can't see why, the ROMs *can* change, but they're unlikely
Branden> do so very often)?
None of the above, I think ;-(, /var is indeed wrong, the roms
do not chage that frequently.
/etc, or /usr/local: your choice.
manoj
--
"Times are bad. Children no longer obey their parents, and everyone
is writing a book." Cicero
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: