[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#13287: less uses /usr/bin/editor without it necessarily being there.

On 7 Oct 1997, Manoj Srivastava wrote:

> Hi,
> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
> Dale> First of all, I'm not necessarily speaking in opposition to the
> Dale> current policy here, but I am objecting to the way policy is
> Dale> being decided. An "excelent solution" that "noone objected" to,
> Dale> should not constitute a policy decission.
> 	So what are you proposing the policy manager do? Hold quorum
>  calls and call for vote registration like the US house of
>  representatives do? We had an informal discussion, an excellent
>  poposal came forth, a few people said that sounded fine. Short of a
>  vote taking on every decision (which would be quite tedious, and not
>  just for the policy manager), this is the best you can expect.

I believe that Policy is important enough that concesus is required. It is
entirely possible that this consensus was reached without my input. (I
don't really have any problem with this in principle) The problem for me
personally is that I maintain two editors, which makes it necessary that I
deal with this policy.

> 	We should also have some consideration for the policy manager,
>  and try not to make a hard job more cumbersome and harder.
The only recourse that I have is to go "read" the policy manual every week
or two to see if there is anything that has changed. I don't have the
time, or inclination to subject myself to that, so I end up finding out
about policy from a bug report. This just doesn't work well for

> Dale> I pay close attention to traffic on the list. While this doesn't
> Dale> guarantee that I will not miss things, I sure missed Ian's
> Dale> posting on this issue.
> 	Yes. It happens. We can't hold up every policy decision to
>  ensure that no one of the 200 odd develoers has not in fact
>  missed a critical mail message. If you were interested/involved in
>  this process, and happened to have missed the message, were you not
>  concerned that the discussion stopped? 
The only discussion I remember had to do with the "editor" virtual
package. I have a vague memory of several "better" solutions being
proposed at the end of this discussion, but don't remember a decission.

This is a general problem for others as well. We have longwinded
discussions on a "given thread" that tend to diverge off into several
directions. One or another of these "sub threads" looks like the
resolutions to some, while another appears to fix it for others. Some see
no resolution and go back to business as usual. This creates far too much
confusion. Pointing to the Policy manual as the "definative" answer isn't
necessarily adequate.

> 	The policy manager then put it on the weekly proposed policy
>  note. But you do not care to join the policy mailing list. I think
>  that means you choose not to fully participate in policy making. In
>  which case you can't turn around and complain about policy being
>  formulated in your absence.
> >>  Anyways, I'll send an announcement to debian-devel soon which
> >> explains the new policy so that the maintainers of all
> >> editors/pagers can update their packages.
> >> 
> Dale> I believe that this is backwards of the way things should
> Dale> work. Announcement of proposed policy changes should preceed the
> Dale> decission making. (I'm not sure if we should vote on each issue,
> Dale> but we need some broader control than two people making the
> Dale> decission.
> 	The decision has been made. If we allow everyone to come back
>  and challenge decisions made on the policy list (which they *choose*
>  not to subscribe to), we shall have no lasting decisions ;-(.
If we don't allow the established policy to be challenged then nothing
changes. There is no such thing as a "lasting decision". As times, or
circumstances change, so must policy.

Declaring all those not subscribed to the policy list (or any other list,
for that matter) as being "uniterested parties" doesn't deal with the
problem in a fair or adequate fashion. I have never agreed with the "list
proliforation" that has been used to solve the volume problem. In
particular I believe that policy issues should be discussed on
debian-devel, as they are "meta-technical" issues that impact all

> Dale> The policy manual doesn't make it very clear as to why the
> Dale> "editor" has the responsibility, rather than the package that
> Dale> wishes to use it.
> 	Because if my package angband wants to use an editor, any
>  editor, then it can't provide the /usr.bin/editor link on it's	own if
>  in fact no editor has been installed on my machine. Only an editor
>  package can. Seems to me the logical choice is that all editors
>  provide this link unless it exists already.
I see your point.

> Dale> For instance, Pine can be configured to use an
> Dale> editor other than the the built-in Pico editor. This
> Dale> configuration is established by the user within his own
> Dale> account. While it seems pretty clear that these "individual user
> Dale> controls" are addressed by the EDITOR and PAGER variables (and
> Dale> this seems much cleaner than the update-alternatives approach)
> Dale> these variables are not guaranteed to be set.
> 	That's why the /usr/bin/sensible-editor et al are required, so
>  that a default editor always can be used. The user may change it if
>  she wishes. If these are not set, the user did not wish to change the
>  system default. Where is the problem?
The problem comes when dealing with the "priority" field for
update-alternatives. It's not clear how to order the priorities amongst
the plethora of editor packages, and the policy manual doesn't give any
guidance in this.

> Dale> Rather than requiring every editor to "update-alternatives" I
> Dale> would suggest that the base system come with a /etc/profile that
> Dale> sets these variables to the "default" programs provided in
> Dale> base.
> 	I vote we do both. It is policy, after all. ;-)
> Dale> This gives the system administrator a place to change
> Dale> these for the system, and still gives the individual user the
> Dale> option of changing the personal default. None of this
> Dale> flexibility is provided by update-alternatives. Worse than that,
> Dale> using this method adds another question to the installation
> Dale> process of an editor (Do you want "this editor" to be the system
> Dale> default?)
> 	This has already been hashed once, I do not feel I've the
>  energy to get into this again.
OK, so what was the decission?

Waiting is,

_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: