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
------------ --------------
aka Dale Scheetz Phone: 1 (904) 877-0257
Flexible Software Fax: NONE
Black Creek Critters e-mail: dwarf@polaris.net
------------ If you don't see what you want, just ask --------------
Reply to: