Re: [RFC] new virtual package names for optical discs burning applications
Thomas Perl [EMAIL PROTECTED] writes: Hello! On Sat, 18 Nov 2006 20:42:16 +0200 George Danchev wrote: On Saturday 18 November 2006 11:33, Adrian von Bidder wrote: If they can't be used with the exact same commandline, there's no sense in providing these virtual packages because the programs need explicit support for each of those programs. (And especially with these writing applications, arcane options need to be specified in many cases, so it's not a case of a common API with some few extra options a backend might use if it has specific support.) Fair concern, but this is also true for other already existing virtual packages -- editor comes to mind. Isn't it more important what a functionality is being provided, and not so important how it is provided. Yeah, but an editor just takes one or more filenames as arguments and opens/edits these. For burning to a CD/DVD, you have to specify a bunch of options before cdrecord (for example) burns the disc (driver, device, speed, burnproof options, etc..). It's not like a cd-writer myfile.iso will burn the iso to CD/DVD, is it? Or at least not until we have a wrapper for every cd burning tool there is. Actualy it will. Udev sets the /dev/cdrw link and wodim defaults to that. All you have to do is wodim myfile.iso and it will burn it for you. But I guess that is an exception. Enjoy. Thomas MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] new virtual package names for optical discs burning applications
On Friday 17 November 2006 16:44, Loïc Minier wrote: On Fri, Nov 17, 2006, George Danchev wrote: Using alternatives mechanism -- currently I don't think that using alternatives mechanism would be a benefit as a whole, but I might be blind of course. Check /usr/bin/sensible-* in debianutils. They rely on alternatives and environment variables for defaults and overrides (respectively) and carry some logic to select the most adequate binary in the normal cases. E.g., sensible-cd-burner could spawn xcdroast; but I'm not sure this is what you want to achieve. Sure, that could be another level of abstraction which could be implemented further if necessary. But currently I imagine the things as follows: low-level burners provide the proposed virtual -burner packages. Their clients (e.g. various console and X frondends these low-level programs, various backup systems which could use optical medium to write archives to, etc) should decide how to call (and look for) these low-level programs which come with these virtual packages or allow the user to do that him/herself from their configuration options. So, before filing a bug against Debian Policy I'd like to sound if a consensus could be reached wrt `cd-burner' and `dvd-burner' virtual package names, since there might be any objections of doing so I could not be aware of. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] new virtual package names for optical discs burning applications
On Friday 17 November 2006 15:22, George Danchev wrote: * `cd-burner' -- could be provided by wodim, cdrskin, (cdrdao ?) * `dvd-burner' -- could be provided by wodim, dvd+rw-tools and dvdrecord I don't know the programs in question exactly, but how likely is it that even wodim and cdrecord will stay commandline compatible? If they can't be used with the exact same commandline, there's no sense in providing these virtual packages because the programs need explicit support for each of those programs. (And especially with these writing applications, arcane options need to be specified in many cases, so it's not a case of a common API with some few extra options a backend might use if it has specific support.) cheers -- vbi -- featured product: Debian GNU/Linux - http://debian.org pgpoEMc67fHtL.pgp Description: PGP signature
Re: [RFC] new virtual package names for optical discs burning applications
On Saturday 18 November 2006 11:33, Adrian von Bidder wrote: On Friday 17 November 2006 15:22, George Danchev wrote: * `cd-burner' -- could be provided by wodim, cdrskin, (cdrdao ?) * `dvd-burner' -- could be provided by wodim, dvd+rw-tools and dvdrecord I don't know the programs in question exactly, but how likely is it that even wodim and cdrecord will stay commandline compatible? If they can't be used with the exact same commandline, there's no sense in providing these virtual packages because the programs need explicit support for each of those programs. (And especially with these writing applications, arcane options need to be specified in many cases, so it's not a case of a common API with some few extra options a backend might use if it has specific support.) Fair concern, but this is also true for other already existing virtual packages -- editor comes to mind. Isn't it more important what a functionality is being provided, and not so important how it is provided. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] new virtual package names for optical discs burning applications
Hello! On Sat, 18 Nov 2006 20:42:16 +0200 George Danchev wrote: On Saturday 18 November 2006 11:33, Adrian von Bidder wrote: If they can't be used with the exact same commandline, there's no sense in providing these virtual packages because the programs need explicit support for each of those programs. (And especially with these writing applications, arcane options need to be specified in many cases, so it's not a case of a common API with some few extra options a backend might use if it has specific support.) Fair concern, but this is also true for other already existing virtual packages -- editor comes to mind. Isn't it more important what a functionality is being provided, and not so important how it is provided. Yeah, but an editor just takes one or more filenames as arguments and opens/edits these. For burning to a CD/DVD, you have to specify a bunch of options before cdrecord (for example) burns the disc (driver, device, speed, burnproof options, etc..). It's not like a cd-writer myfile.iso will burn the iso to CD/DVD, is it? Or at least not until we have a wrapper for every cd burning tool there is. Enjoy. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] new virtual package names for optical discs burning applications
Am Samstag 18 November 2006 19:42 schrieb George Danchev: On Saturday 18 November 2006 11:33, Adrian von Bidder wrote: On Friday 17 November 2006 15:22, George Danchev wrote: * `cd-burner' -- could be provided by wodim, cdrskin, (cdrdao ?) * `dvd-burner' -- could be provided by wodim, dvd+rw-tools and dvdrecord I don't know the programs in question exactly, but how likely is it that even wodim and cdrecord will stay commandline compatible? If they can't be used with the exact same commandline, there's no sense in providing these virtual packages because the programs need explicit support for each of those programs. (And especially with these writing applications, arcane options need to be specified in many cases, so it's not a case of a common API with some few extra options a backend might use if it has specific support.) Fair concern, but this is also true for other already existing virtual packages -- editor comes to mind. Isn't it more important what a functionality is being provided, and not so important how it is provided. editor file is a bit easier than cd-writer file because it is not even clear what file actually is (must have special formats like .cue or .iso or whatever is supported) and you certainly need some options. And after all, there are a LOT more editors than programs that can burn CDs/DVDs. cd-writer is not even a good name for it. What do you want to put on the CD? Audio, Video, Data? Shall it be bootable on on what arch. Shall input from stdin be possible. Same for DVD. The matter is a bit more complex than to say: I need a cd-burner program. And that makes the virtual package name a bit useless. Just my opinion, though. HS
[RFC] new virtual package names for optical discs burning applications
Hello, With the advent of cdrskin [1] for writing CD-R/W in a cdrecord's command-line-compatible way and already having several dvd burner applications, I'd like to propose the addition of at least two more virtual package names to the `Authoritative list of virtual package names' [2] -- these are: * `cd-burner' -- could be provided by wodim, cdrskin, (cdrdao ?) * `dvd-burner' -- could be provided by wodim, dvd+rw-tools and dvdrecord * `blueray-burner' -- in a distant (or not so distant?) the future. * `optical-discs-burner' -- i.e. burns all types of optical discs. I'm not sure if we will need that in fact. Another set of possible names would be `cd-recorder', `dvd-recorder' and so on, but these are a little longer, while the clarity remains the same. Using alternatives mechanism -- currently I don't think that using alternatives mechanism would be a benefit as a whole, but I might be blind of course. FWIW, should /usr/bin/cdrecord symlink (from the `cdrecord' package) stay as a symlink to wodim for compatibility reasons or remove it in order to benefit identification of the apps which search for cdrecord binary ? Various frontend packages -- these would depend on these virtual packages at some future point; post-etch of course. * k3b -- 0.12.17-4 already uses cdrskin if wodim is not installed. * nautilus-cd-burner -- I filed a wishlist bug against it to do the same * cdw -- I'm not sure if that package will be maintained in the future. * more -- to be identified ??? [1] Fully GPL'ed; highly cooperative and capable upstream; and obviously too youngish as compared to cdrkit/cdrtools mileage. [2] http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] new virtual package names for optical discs burning applications
On Fri, Nov 17, 2006, George Danchev wrote: Using alternatives mechanism -- currently I don't think that using alternatives mechanism would be a benefit as a whole, but I might be blind of course. Check /usr/bin/sensible-* in debianutils. They rely on alternatives and environment variables for defaults and overrides (respectively) and carry some logic to select the most adequate binary in the normal cases. E.g., sensible-cd-burner could spawn xcdroast; but I'm not sure this is what you want to achieve. -- Loïc Minier [EMAIL PROTECTED] 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] new virtual package names for optical discs burning applications
On Fri, Nov 17, 2006 at 04:22:51PM +0200, George Danchev wrote: * `cd-burner' -- could be provided by wodim, cdrskin, (cdrdao ?) [...] Another set of possible names would be `cd-recorder', `dvd-recorder' and so on, but these are a little longer, while the clarity remains the same. What about `cd-writer'? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 --
