Hi guys, firstly, I think it's great that you're tackling this sort of thing. If there's one thing I hate it's the way software get's installed - even today I know of no system that get's it just right (and I'm even using Mac OS X :-).
That said, I have the feeling that you're jumping to the specification and implementation without checking the requirements first. Your policy states where things are to go, but hardly refers to a problem trying to be fixed. Personally I live in a twilight zone between (effectively) single user and multi-user systems. For single user systems it should be possible for the main user to simply install and de-install software, and of course to perform updates. On a multi-user system, only a select few should be allowed to install publically accessable software, but almost everyone should be able to install software for themselves. (including personal extensions to applications that they otherwise can't change) Something else that bothers me is that it's often difficult to have multiple versions of a peice of software installed on the same machine at the same time. /usr/local/bin is appalling - /opt/<application>-<version> is much better - if a new version doesn't work - just go back to using the old one - total effort == 0. You're vimXY suggestion addresses this - but if I uninstall vim60 - what happens in /usr/share? That's something that -I- have to clean up... asuming I think of it. So what I need is a distinction between, system software (OS only), local software [1] (applications for general use), local application extensions (for general use), personal applications and personal application extensions - and for everything, it should be possible to have as many different versions of each application as the users require. (Even system software should be so flexible - which version to use should be 'the latest unless otherwise configured'.) This distinction isn't a categorisation of the software being installed, but rather a question of who is doing the installation and for what purpose. (In this respect, I find the installation of applications via the 'root' user extremely annoying - it's a security risk and in most cases completely unnecessary.) [1] local software can also be split into "local to this machine" and "local to site" So, to your suggestion - rather than specifying a directory (/usr/share/vim) where vim's scripts should go, please specify an overall structure for any application - and then modify vim as necessary to meet those requirements. The key word here being "requirements" - what should be possible? what should be discouraged? what should not be possible? What are the benefits of splitting the files of an application into "external" directories like /usr/share? what problems arise? What happens when things go wrong? How difficult is it uninstall software? (including unwanted vim scripts!) What would a normal user have to do to install a vim script for himself? What about non-unix environments? They will have the same problems but will probably require a different solution (try to find /usr/share on a M$ machine hahahahaha)... If you specify what is required, then the solution can be found at a higher level and then applied to any system and any application. It could be that /usr/share/vim becomes the standardised installation directory for locally installed vim scripts - but realistically this should be left flexible enough so that the admin can chose to do something different (ie: he might have an NFS directory for platform independant scripts, why should he be forced to update every system because someone said "/usr/share/vim is where they go"?) Apple has gone a long way in this respect - the idea of an application being a single, location independant(!), directory containing everything that the application needs is something that appeals to me greatly, add to that a small group of well defined personalisation directories on a system-wide and user basis (/Library, /System/Library and ~/Library) and you've got something that works for all applications, in a consistent manner, which is easy to understand, manage and automate. If you can convince the debian (suse, red hat, ....) people to do an analysis allong these lines and reach a consesus so that software can be installed in a standard but flexible way on such platforms, it would be a great thing for everyone (developers, admins, users). The different types of installation (system, local, personal) only really differ in the location of the software - it could even be automated to the point that if the software was installed as root, the system directories would be used, if the user has write access to the local directories (ie: a user called 'local', or even one called 'vim' which can only update the vim installations) then the local directories would be used, and if all else fails, every user can install software in their personal directories. I hope you view this as constructive criticism and not just a rant - I've been managing software in /usr/local site-wide for years and putting together and keeping track of software installations on unix machines is not a fun task. Sorry but I couldn't let this chance go by :-) Cheers, Steve -- -----Ursprüngliche Nachricht----- Von: Jakub Turski [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 18. Juli 2003 13:20 An: VIM Mailing list; debian-policy@lists.debian.org Betreff: Debian Vim Scripts Policy proposal Greetings. Together with Artur Czechowski, we've created a proposition of possible Debian Vim Scripts Policy. At the moment Debian introduces only vim-scripts and vim-latexsuite but we think that problems which have risen during assembly of vim-latexsuite should be addresed in a form of policy for others maintainers willing to package vim scripts. The current draft of the policy could be found at: http://yacoob.dnsalias.net/sakwa/vim-policy.txt Please mail us our suggestions and thoughts about it. We'd like this policy to become a part of Debian Policy set of documents. So far, maintainers of 'cream' package and 'vim-scripts' package have spoke in favour of this document. We're still waiting for the opinion from 'vim' package maintainer. This message has been sent to both Vim mailing list and debian-policy mailing list. Regards, Jakub Turski. -- __ __.------------------------- http://yacoob.dnsalias.net/cv.html --.__ (oo) | 1/2: one half the value, i.e.: 1/2, X/2, PS/2, OS/2 ... | / \/ \ | | `V__V' `--.__penguin_#128720______________________________________________.--' Der Inhalt dieser E-Mail oder eventueller Anhänge ist ausschliesslich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen. The information contained in this email is intended solely for the addressee. If you are not the intended recipient, any form of disclosure, reproduction, distribution or any action taken or refrained from in reliance on it, is prohibited and may be unlawful. Please notify the sender immediately.
