On Mon, Jun 18, 2012 at 10:52:36AM +0200, Guenter Milde wrote: > > I am not sure whether this is a policy violation, but it is most > > probably a surprise for most users. In Debian I expect all files under > > /usr to come from packages, and thus be static. This is not the case > > for the *.slc files that are written to /usr/share/jed/lib during > > postinst with a call to /usr/share/jed/compile/jed-common install. > > The *.slc files are bye-compiled versions of the corresponding *.sl files in > the packages jed-common and jed-extra. > > Placing them alongside the sources is common practice and prevents > surprises when customizing the editor (using a custom jed-library-path, > using drop-in replacements from jed-extra or locally installed).
It might be easy for packaging, but is confusing for users. One usually expects that dpkg --search is able to give an owner for every file under /usr sans /usr/local. > The same scheme is used by Python-2 packages: the generated *.pyc files are > stored alongside the *.py source under usr/lib/... python-support tries hard to place those files in /var, but not all packages do already use it. > > In my expectations, such files should be in /var/lib since they're > > variable data and not registered with the packaging system. > > The byte-compiled filea are no more variable than the rest of the > package, as they are only generated/deleted when the package is > (de)installed or updated. But they do not originate from a package, cannot have their checksum verified, dpkg --search doesn't find them. All of those are usually signs for a file that was put there in an unauthorized way, and one cannot find out whether it was a dumb colleague, a postinst or an attacker. Greetings Marc -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
