Re: New virtual package names.
Dale Scheetz writes (Re: New virtual package names. ): ... Well, I'm pretty sure that Bill didn't just wake up one morning and say Wow! That essential field sure is neat! Let's put it in ae! My assumption was that this was an attempt to keep ae in the system. I think that Bill was under the mistaken impression that every base package should be marked essential. ... No, I am concerned about programs that might use $EDITOR as the means to providing an editor. [...] As has been pointed out, the dependency scheme doesn't help at all here. Ian.
Re: New virtual package names.
On 30 Aug 1996, Mark Eichin wrote: Emacs also has conditions where it calls an outside editor... Interesting. I'm aware of cases where it will call outside *viewers* (mostly mime/web stuff) but I can't think of what outside editors it would call. Could you perhaps expand on this point? I am a novice when it comes to emacs. My impression came from a bug report on pine about pico leaving backup copies of email that are world readable. It turned out that the emacs mail handler was calling pico with the auto-backup enabled. This is what left me with that impression. (I was sure that someone less ignorant than myself would surely correct me if I was wrong) Luck, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: New virtual package names.
On 27 Aug 1996, Rob Browning wrote: Dale Scheetz [EMAIL PROTECTED] writes: (Until they try to remove all editors) I don't want to cause trouble, but why don't we just completely disallow the removal of ae. It's harmless, and the entire package only takes up 54K. I can't see that it's worth spending another second even thinking about. Am I missing something? Well, this brings us full circle. Rob, the declaration of ae as essential has been declared a bug. This kept ae from being removed which caused some to complain. The current discussion is an attempt to move beyond this. Ian's position is that it doesn't matter if ae and all other editors are removed from the system. Yours is that it doesn't matter if ae can't be removed. I hope that we can come to some middle ground here. Thanks, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: New virtual package names.
Dale Scheetz writes (Re: New virtual package names. ): ... Part of my concerns stem from the past history of ae. I have only recently taken over the maintainance of this package. When I got it, the essential field had been declaired a bug, but the discussion of that bug seemed to indicate that removal of the essential flag was not a sufficient solution. In addition, I am concerned by the fact that this field was only added to the package a couple of revisions ago, and now needs to be removed. The fact that the field was added was a mistake, and it was noticed and reported as a bug (several times, in fact). It is not surprising that once a mistake is made people ask for it to be unmade again. I didn't see anything in that discussion to think that the removal of the essential flag wasn't a full solution. I saw several people with the `hammer and nail' problem: `we have dependencies so we must use them here'. I don't see any difference, in principle, between an editor and a mail-delivery-agent. They are both programs that deliver specific functionality. The only differnce I can see is that an editor may not be viewed as being as critical to system operations as the other, and Ian has pointed out that users are likely to be more aware of their needs for an editor than they are for other dependant programs. I am pretty sure that we have users who are not this aware, but that is not the basis for my feelings here. If we have users who are not aware of this then they will not be satisfied by `vi' or `ed' either - and these programs will have to satisfy the dependency. We can't solve this problem with the dependency mechanism. Ae is in the base package because it was deemed necessary to have an editor in the system, and ae was small enough to fit. It is this necessity that is driving the editor virtual package dependance as the proposed solution. If it is not necessary for the system to contain an editor, then why is one in the base system? The base system is provided as a tool for installing the rest of the packages, and is supposed to be a sensible default. Both the essential flag and the dependency mechanism actually _prevent_ the user from doing something, and we should only do this if we really mean it. ... If it is necessary for an editor to be on the system, it seems desirable to provide protections from the inadvertant removal of all editors. If there is a better way to insure the existance of an editor on the system, I would be happy to hear it. What terrible thing do you think will happen if the user removes all their editors ? They'll sit there wanting to edit a file and think Damn, I can't figure out why I can't edit this file. I just sit here blankly and wonder how I used to edit files. ? In addition, it is not clear to me that being unnecessary is the same as undesirable. I can be convinced (no, really!) of either position at this point. I just need a little more 'splaining. For it to be right for us to do this there has to be a good reason in favour of it. It is not sufficient for it merely to be neutral. In any case, it isn't neutral: it is a lot of work, and while the work is done silly things will happen like users being forced to install particular editors to satisfy the dependency scheme. Ian.
Re: New virtual package names.
Ian Jackson: What terrible thing do you think will happen if the user removes all their editors ? They'll sit there wanting to edit a file and think Damn, I can't figure out why I can't edit this file. I just sit here blankly and wonder how I used to edit files. ? Yes. -- Please read http://www.iki.fi/liw/mail-to-lasu.html before mailing me. Please don't Cc: me when replying to my message on a mailing list. PS. I'm not sure if we want to care about that level of stupidity, though. pgpUk7GcDSzfu.pgp Description: PGP signature
Re: New virtual package names.
On Tue, 27 Aug 1996, Ian Jackson wrote: Dale Scheetz writes (Re: New virtual package names. ): ... Part of my concerns stem from the past history of ae. I have only recently taken over the maintainance of this package. When I got it, the essential field had been declaired a bug, but the discussion of that bug seemed to indicate that removal of the essential flag was not a sufficient solution. In addition, I am concerned by the fact that this field was only added to the package a couple of revisions ago, and now needs to be removed. The fact that the field was added was a mistake, and it was noticed and reported as a bug (several times, in fact). It is not surprising that once a mistake is made people ask for it to be unmade again. Well, I'm pretty sure that Bill didn't just wake up one morning and say Wow! That essential field sure is neat! Let's put it in ae! My assumption was that this was an attempt to keep ae in the system. I didn't see anything in that discussion to think that the removal of the essential flag wasn't a full solution. I saw several people with the `hammer and nail' problem: `we have dependencies so we must use them here'. I understand your perceptions of this, but I saw the discussion as trying to find a better solution than essential (which obviously didn't work right) to the problem of keeping an editor in the system. I don't see any difference, in principle, between an editor and a mail-delivery-agent. They are both programs that deliver specific functionality. The only differnce I can see is that an editor may not be viewed as being as critical to system operations as the other, and Ian has pointed out that users are likely to be more aware of their needs for an editor than they are for other dependant programs. I am pretty sure that we have users who are not this aware, but that is not the basis for my feelings here. If we have users who are not aware of this then they will not be satisfied by `vi' or `ed' either - and these programs will have to satisfy the dependency. We can't solve this problem with the dependency mechanism. I'm not sure I follow any of what you just said. If we can't solve the problem with the dependency mechanism, how then? Ae is in the base package because it was deemed necessary to have an editor in the system, and ae was small enough to fit. It is this necessity that is driving the editor virtual package dependance as the proposed solution. If it is not necessary for the system to contain an editor, then why is one in the base system? The base system is provided as a tool for installing the rest of the packages, and is supposed to be a sensible default. Both the essential flag and the dependency mechanism actually _prevent_ the user from doing something, and we should only do this if we really mean it. ... If it is necessary for an editor to be on the system, it seems desirable to provide protections from the inadvertant removal of all editors. If there is a better way to insure the existance of an editor on the system, I would be happy to hear it. What terrible thing do you think will happen if the user removes all their editors ? They'll sit there wanting to edit a file and think Damn, I can't figure out why I can't edit this file. I just sit here blankly and wonder how I used to edit files. ? Cute. No, I am concerned about programs that might use $EDITOR as the means to providing an editor. Pine, for instance, can be configured to call an editor under certain circumstances. If no editor is available (due to being removed) then, as we all know, pine will flash an error message for all of 1/20th of a second and then stare at you. Emacs also has conditions where it calls an outside editor, and I'm sure that there are others. Problems of this type, caused by the lack of an editor will appear to be bugs in other software. This is something to be avoided, in my estimation. In addition, it is not clear to me that being unnecessary is the same as undesirable. I can be convinced (no, really!) of either position at this point. I just need a little more 'splaining. For it to be right for us to do this there has to be a good reason in favour of it. It is not sufficient for it merely to be neutral. See above... In any case, it isn't neutral: it is a lot of work, and while the work is done silly things will happen like users being forced to install particular editors to satisfy the dependency scheme. Well, I don't see a LOT of work. Packages that provide an editor will only need to add it to the Provides: field. Until some base package (or some other package) creates a Depends: for editor this causes no problems to the system. That is, if the concept is integrated in the proper order, no one will know it has happened. (Until they try to remove all editors) Later, Dwarf
Re: New virtual package names.
On Sun, 25 Aug 1996, Ian Jackson wrote: I have read all of the discussion. Just because I'm a week behind on my email doesn't mean I'm not reading it. However, since you seemed so insistent, I went back and had a look at what arguments people might have presented. I found a rather limited amount of discussion. It did not appear to me to have reached a definite conclusion. The virtual package got added by the maintainer of the list because noone objected in time. The only one I could find was based on the idea that in order for it to be safe to remove the `Essential' flag from `ae' it would be necessary to use the dependency mechanism to stop people from deinstalling it before they install another editor. This didn't seem to be stated explicitly in this form, but it was clear that people were seeing the idea of an `editor' virtual package as an alternative to marking `ae' essential. I don't see that this is a true case of alternative solutions to a problem: I don't think there is a problem, and I think that it would be just fine for `ae' not to be essential and for nothing to depend on it. Thank you for speaking to the issues brought out by the previous discussions. I feel the need to make my position clear here. I have no axe to grind here on this issue. My concerns are only that the issue be resolved correctly. Part of my concerns stem from the past history of ae. I have only recently taken over the maintainance of this package. When I got it, the essential field had been declaired a bug, but the discussion of that bug seemed to indicate that removal of the essential flag was not a sufficient solution. In addition, I am concerned by the fact that this field was only added to the package a couple of revisions ago, and now needs to be removed. I don't see any difference, in principle, between an editor and a mail-delivery-agent. They are both programs that deliver specific functionality. The only differnce I can see is that an editor may not be viewed as being as critical to system operations as the other, and Ian has pointed out that users are likely to be more aware of their needs for an editor than they are for other dependant programs. I am pretty sure that we have users who are not this aware, but that is not the basis for my feelings here. Ae is in the base package because it was deemed necessary to have an editor in the system, and ae was small enough to fit. It is this necessity that is driving the editor virtual package dependance as the proposed solution. If it is not necessary for the system to contain an editor, then why is one in the base system? If it is necessary for an editor to be on the system, it seems desirable to provide protections from the inadvertant removal of all editors. If there is a better way to insure the existance of an editor on the system, I would be happy to hear it. In addition, it is not clear to me that being unnecessary is the same as undesirable. I can be convinced (no, really!) of either position at this point. I just need a little more 'splaining. Thanks, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: New virtual package names.
On Wed, 21 Aug 1996, Ian Jackson wrote: Dale Scheetz writes (Re: New virtual package names. ): On Fri, 9 Aug 1996, Ian Jackson wrote: ... Noone is going to deinstall all the editors on their system and not notice what they've done wrong and how to fix it - this is not the kind of `mistake' our dependency scheme should try to address. It was my understanding that this was EXACTLY what dependancies were designed for; Protecting the installer from removing functionality that other packages need. Surely this is only useful if this is a mistake the user will be likely to make, and then not know how to undo ? The only possible consequences of creating an `editor' virtual package and having things depend on it are: * Needless updates to packages to add dependencies and Provides This is not a technical argument. It is an economic one, and should not be listed as a primary point. (all change takes work) Your assertion that it is needless is not yet backed up by technical arguments. In addition, the modification of other editor packages to encorporate this new VPN are not on any critical path, so they can happen as need arrises. I can't prove that it's needless. You're shifting the burden of proof. It's up to you to show that it's needed. The burden I am trying to shift onto your shoulders is for you to have read the complete thread of this discussion. It is not clear that you have done so. You declared the needlessness but gave no explanation of why this was so. The rest of us, as a group, have discussed this, at some length, and come to the conclusion that the editor virtual package name was a viable solution. As a late arrival to this discussion it is your responsibility to have, at least, read the complete discussion, and speak to the points raised and settled there. Blanket assertions without supporting arguments are neither constructive, nor informative. * Some person installs their own favourite editor in /usr/local and wants to remove all ours but can't. This is true for any package that has others that depend on it. If I want to put a qmail of my own into /usr/local, I will still need to keep some Debian mail-delivery-agent installed to satisfy other packages dependance on an MDA. A way to tell dpkg about non-package provides would fix this problem in general, but I don't necessarily think that it is needed, or even desirable. The difference is that an editor is such a fundamental and striaghtforward thing that it will be obvious to the user what they're doing without the dependency scheme having to tell them. You're using a sledgehammer to crack a probably-nonexistent nut. Well, if you read the foundation postings on this subject, the nut does exist. I still think that we are using the right sized wrench. Later, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: New virtual package names.
Dale Scheetz writes (Re: New virtual package names. ): On Fri, 9 Aug 1996, Ian Jackson wrote: ... Noone is going to deinstall all the editors on their system and not notice what they've done wrong and how to fix it - this is not the kind of `mistake' our dependency scheme should try to address. It was my understanding that this was EXACTLY what dependancies were designed for; Protecting the installer from removing functionality that other packages need. Surely this is only useful if this is a mistake the user will be likely to make, and then not know how to undo ? The only possible consequences of creating an `editor' virtual package and having things depend on it are: * Needless updates to packages to add dependencies and Provides This is not a technical argument. It is an economic one, and should not be listed as a primary point. (all change takes work) Your assertion that it is needless is not yet backed up by technical arguments. In addition, the modification of other editor packages to encorporate this new VPN are not on any critical path, so they can happen as need arrises. I can't prove that it's needless. You're shifting the burden of proof. It's up to you to show that it's needed. * Some person installs their own favourite editor in /usr/local and wants to remove all ours but can't. This is true for any package that has others that depend on it. If I want to put a qmail of my own into /usr/local, I will still need to keep some Debian mail-delivery-agent installed to satisfy other packages dependance on an MDA. A way to tell dpkg about non-package provides would fix this problem in general, but I don't necessarily think that it is needed, or even desirable. The difference is that an editor is such a fundamental and striaghtforward thing that it will be obvious to the user what they're doing without the dependency scheme having to tell them. You're using a sledgehammer to crack a probably-nonexistent nut. Ian.
Re: New virtual package names.
On Fri, 9 Aug 1996, Ian Jackson wrote: Dale Scheetz writes (Re: New virtual package names. ): ... On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). Sorry I'm coming into this so late (just over a week, in fact), but I think this is a daft idea. Noone is going to deinstall all the editors on their system and not notice what they've done wrong and how to fix it - this is not the kind of `mistake' our dependency scheme should try to address. It was my understanding that this was EXACTLY what dependancies were designed for; Protecting the installer from removing functionality that other packages need. The only possible consequences of creating an `editor' virtual package and having things depend on it are: * Needless updates to packages to add dependencies and Provides This is not a technical argument. It is an economic one, and should not be listed as a primary point. (all change takes work) Your assertion that it is needless is not yet backed up by technical arguments. In addition, the modification of other editor packages to encorporate this new VPN are not on any critical path, so they can happen as need arrises. * Some person installs their own favourite editor in /usr/local and wants to remove all ours but can't. This is true for any package that has others that depend on it. If I want to put a qmail of my own into /usr/local, I will still need to keep some Debian mail-delivery-agent installed to satisfy other packages dependance on an MDA. A way to tell dpkg about non-package provides would fix this problem in general, but I don't necessarily think that it is needed, or even desirable. I think the `editor' virtual package should be scrapped. I personaly have no problem with this, as long as you can show a more specific reason for doing so. So far I haven't seen an argument that is to the point. Later, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: New virtual package names.
Dale Scheetz writes (Re: New virtual package names. ): ... On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). Sorry I'm coming into this so late (just over a week, in fact), but I think this is a daft idea. Noone is going to deinstall all the editors on their system and not notice what they've done wrong and how to fix it - this is not the kind of `mistake' our dependency scheme should try to address. The only possible consequences of creating an `editor' virtual package and having things depend on it are: * Needless updates to packages to add dependencies and Provides * Some person installs their own favourite editor in /usr/local and wants to remove all ours but can't. I think the `editor' virtual package should be scrapped. Ian.
Re: New virtual package names.
Well, it's been a while, so lets add: imap-client and imap-server to the virtual package names list. Sure thing. I'm not familiar with imap though, so could you give me a description for these to go in the list? On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). What would it be used for? Are there packages that depend on having an editor, or for which it would be appropriate to recommend one (and have any old editor serve the purpose)? If so, no problem... 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: New virtual package names.
Warwick HARVEY: Are there packages that depend on having an editor, Without trying, I think of vipw, vigr, mail, elm, rcs (and thus cvs), trn, tin, and nn. I grant that all but vipw and vigr can be used without an editor -- if you only read mail and news and never check anything in. I don't have an opinion on whether an editor virtual package is needed, though. -- Lars Wirzenius [EMAIL PROTECTED] http://www.iki.fi/liw/ Please don't Cc: me when replying to my message on a mailing list. pgpbetymPqikJ.pgp Description: PGP signature
Re: New virtual package names.
On Fri, 2 Aug 1996, Warwick HARVEY wrote: On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). What would it be used for? Are there packages that depend on having an editor, or for which it would be appropriate to recommend one (and have any old editor serve the purpose)? If so, no problem... Here is a better reason: -- paste begins -- From [EMAIL PROTECTED] Fri Aug 2 11:09:03 1996 Date: Thu, 1 Aug 1996 12:34:51 -0400 From: Daniel Quinlan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug#3994: ae won't deinstall Resent-Date: Fri, 02 Aug 1996 11:03:06 GMT Resent-From: Daniel Quinlan [EMAIL PROTECTED] Resent-To: debian-devel@lists.debian.org Resent-cc: Bruce Perens [EMAIL PROTECTED] Package: base Version: 1.1.0-14 I'd like to be able to remove `ae', but it won't deinstall. It should be possible to remove ANY package if I really want to. I don't like it when I'm treated like a child by the packaging system. -- paste ends --- So, if the base packages include a depends: editor and ae provides: editor as well as vi, joe, emacs, and others. Then, as long as some package that provides editor is installed, ae can be removed without difficulty. (Actually I think the above problem is aleviated by removing ESSENTIAL from ae, but the editor provides helps maintain the existance of some editor on the system) Later, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: New virtual package names.
Well, it's been a while, so lets add: imap-client and imap-server to the virtual package names list. On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). Thanks, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
