Re: Bug#13287: less uses /usr/bin/editor without it necessarily being there.
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.
We should also have some consideration for the policy manager,
and try not to make a hard job more cumbersome and harder.
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 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 ;-(.
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.
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?
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.
manoj
--
Live Free or Live in Massachusetts.
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
Reply to: