Re: Name clash in prospective package
Lars Wirzenius writes (Re: Name clash in prospective package ): ... For instance, there's no guarantee that /usr/local/lib exists, or that the admin wants it to exist, or that it won't cause any trouble if it does exist. I can't think of anything that would break, but admins are allowed to do funny things in /usr/local. The problem with this strict approach is that we want (for obvious reasons) our tools to search local directories too when looking for commands, Perl modules, lisp files or whatever. Therefore we can't avoid making some assumptions about what's in /usr/local. The point of not putting things in /usr/local isn't, as I see it, so that the sysadmin can put a baroque thing there and have everything work - it won't - but so that they can put their own software there (installed well or badly) without fear of it being destroyed by the packaging system. ... I quite agree that it should be easy to set up such complex things [like directory structures c in /usr/local], but not without asking. I don't think we need to bother the user with one more question, if we provide a way for an expert to have us leave /usr/local alone. I propose the following resolution: * A policy that packages should include in their .deb files empty directories for path-searched directories. Files are not allowed, and packages aren't allowed to touch /usr/local at all in their maintainer scripts. * When dpkg has the `ignore files matching pattern' option (this will be read from a configuration file) you'll be able to stop it installing things in /usr/local at all. I'm afraid this will be a while coming, but in principle it's not too hard. Ian.
Re: Name clash in prospective package
Lars Wirzenius writes (Re: Name clash in prospective package ): Ian Jackson: The point of not putting things in /usr/local isn't, as I see it, so Well, I'm not in full agreement, but it's not important enough. Fair enough. I propose the following resolution: I can live with the what you propose. Good. I've added the section below. Ian. sect1tt/usr/local/ - for the use of the system administrator p As mandated by the FSSTND no package should place any files in tt/usr/local/, either by putting them in the filesystem archive to be unpacked by prgn/dpkg/ or by manipulating them in their maintainer scripts. p Every package that searches a number of directories or files for something (for example, looking for shared libraries in tt/lib/ or tt/usr/lib/) should search an appropriate directory in tt/usr/local/ too. p In order that the system administrator may know where to place additional files a package should create an empty directory in the appropriate place in tt/usr/local/ by supplying it in the filesystem archive for unpacking by prgn/dpkg/. The tt/usr/local/ directory itself and all the subdirectories created by the package should have permissions 2775 (group-writeable and set-group-id) and be owned by tt/root.staff/. p In the future it will be possible to tell prgn/dpkg/ not to unpack files matching certain patterns, so that system administrators who do not wish these directories in tt/usr/local/ do not need to have them.
Re: Name clash in prospective package
I think it would be better to change the name of the Mercury Compiler to something like mercc. The reasons are: 1) Minimal disturbance to current debian users. They now use mc to launch Midnight Comander. 2) Seniority (?). Midnight Commander took the name first (within Debian, I don't know which program is older). 3) Compatibility with other Linux distributions. They usually include the Midnight Commander (and they call it mc). 4) Popularity. Midnight Commander is more popular among Linux users than Mercury Compiler. More people in this community use mc to mean the former. 5) Personal preference :-) (This point is questionable, I know). Cheers, Fernando.
Re: Name clash in prospective package
Not completely alone---I'd prefer prompting about /usr/local. Why? Because /usr/local on all our machines here (not just debian) is an nfs-mounted directory, and typically mounted readonly or root-squash so that I know nothing on the client machines is going to be able to diddle with it. Prompting about /usr/local is one of the little things packages could do that make life easier on those of us that try to maintain large numbers of debian machines. Should this be solved by moving all /usr/local dir structure to the postinst prerm scripts and be created there after prompting the installer? Erick
Re: Name clash in prospective package
It seems obvious from the responses I've had, that one of the programs needs to be renamed (no other solutions were presented, and, frankly, I can't really think of one that won't cause problems). If we assume this is the case, it is fairly obvious which one should be renamed: the Mercury one. Mercury's mc probably isn't often invoked by the average Mercury user - it's normally called by the automated build tools that come with it. This means that many users won't notice the change anyway. For anyone who's interested, the new name will be merc (chosen by consultation with the Mercury authors). Warwick Warwick Harveyemail: [EMAIL PROTECTED] Department of Computer Sciencephone: +61-3-9287-9171 University of Melbourne fax: +61-3-9348-1184 Parkville, Victoria, AUSTRALIA 3052 web: http://www.cs.mu.OZ.AU/~warwick
Re: Name clash in prospective package
BCW == Brian C White [EMAIL PROTECTED] wrote: BCW I don't see a problem with packages creating directories and BCW other necessary framework in /usr/local. In some cases, this can BCW be quite complex and without which it isn't possible for there to BCW be local extensions. Besides, it let the users know where to put their local elisp code, Perl modules, etc. ECL. -- Emilio C. Lopes mailto:[EMAIL PROTECTED] Instituto de Fisica da Universidade de Sao Paulo Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)
