Re: Q: Location of copyrighted ROM images for emulator packages?
Hi,
>>"Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
Marcus> No, I don't interpret it differently. It is a clear statement
Marcus> that every conf file should reside in /etc, I'm sorry again. I
Marcus> did a quick check if policy is followed:
Marcus> flora$ grep -v /etc /var/lib/dpkg/info/*.conffiles
I show many more violatons, but I think I have a fuller
install ;-)
Marcus> Mmmh. It seems that often files under /var also can be
Marcus> conffiles (if a default file is provided by the package).
Marcus> 1) Zero conf files in /usr/lib/<package> An option to fetch
Marcus> and install the roms via ftp in the postinst and a warning
Marcus> that one should keep the files if dpkg asks to replace them in
Marcus> future upgrades.
>> If they are not conf files, dpkg shall *NOT ASK*. Please read the
>> Packaging manual.
Marcus> Come on, Manoj. I wrote "Zero conf files", because I assumed
Marcus> that they could be conf files, as you well know. If they would
Marcus> be conf files, dpkg *would* ask.
quite so. My apologies for the snippyness.
Marcus> This leads to the simple questions why conf files should
Marcus> reside in /etc. The answer is because they are likely to be
Marcus> subject of modifications, isn't it?
Correct
Marcus> But the ROM images are not subject of modification (only once,
Marcus> when they are downloaded and installed).
I don't think the number of times is relevant. I modify most
conf files only once anyway, a very small handfull need to be updated
on a regular basis. That does not make them any less conffiles.
Also, what if there are new ROM's out there? How are we so
sure that the ROM shall be overwritten just once?
Marcus> So the feature of dpkg (namely conf file handling), could be
Marcus> exploited: the rom images would reside in the /usr area.
Why should they reside in /usr, and not in /etc? I do not
understand why the bitter fight to the end against ROMs in /etc.
Marcus> You are right that policy is clear about the subject, but
Marcus> policy is not applicable to every situation.
Wrong. Until policy is changed, it *is* applicable to all
packages. Change the policy if it is defective, in this case I have
not seen *ONE* technical argument that would justify a change, just
"but we want it in /usr" arguments.
Marcus> We have a special case here and the conf file handling may be
Marcus> appropriate to "mis"-use here. It is only a suggestion, my 2
Marcus> cents, my little unhumble opinion, etc.
I do not agree.
Marcus> What I would like to know is, if there are technical arguments
Marcus> against this procedure I don't see.
There are many, which touch on system local configurastion
files, backup issue, locality of local changes, availability on
system startup, and others.
The Policy and FSSTND wer not just created out of whole
cloth. I do not have time to go into the ramifications of our
decision to constrain all configuration files to /etc; maybe I shall
so expound at a later time.
manoj
--
Everything happens at the same time with nothing in between. -- Paul
Hebig
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: