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

Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.



* Jeremy Bicha <jeremy@bicha.net> [201013 18:09]:
> On Tue, Oct 13, 2020 at 1:52 PM Marvin Renich <mrvn@renich.org> wrote:
> > Describing a clear benefit to having both open and see would help
> > immensely.  Alternatively, convincing the mime-support authors that open
> > should replace see would also work.
> 
> This thread is full of people who strongly prefer "open" over "see"
> ("see" is also little known). Add me to that list. In this case, I
> don't care whether other operating systems do it or not.
> 
> I think "see" was used because "open" was not available. I don't know
> why you are so interested in having "see" go away. It could be removed
> but it's not clear at all to me that it needs to be removed at the
> same time "open" is added. (I don't see anything else that would want
> to use "see".)

Sorry if I gave the impression that I thought see should be removed.
That was not at all what I was saying, and I don't believe it should.

I was trying to identify how the new proposed implementation of "open"
was better or different than "see".  My impression from this thread is
that the only issue is that a lot of people like the name "open" better,
and the current "see" is technically better (or at least as good) other
than a name preference.  If that is the case, then there is probably a
much better solution than adding a new package to the archive that will
likely be installed in most of the same system configurations that
mime-support is.

The mime-support package seems to me to be the "right" place for "open"
and/or "see".  If enough people have a strong opinion that Debian needs
an "open" that does what "see" currently does, I think a wishlist bug on
mime-support is the correct course of action.  That would allow several
choices of implementation, the most likely (in my opinion) is adding
another symlink from open to run-mailcap and _possibly_ deprecating, but
leaving in the package, the "see" symlink.

If mime-support used "see" because "open" was unavailable at the time, I
would expect the mime-support maintainers to be very favorably inclined
to such a wishlist bug.

Adding even a very small package to the archive has a significantly
higher cost for the archive, the maintainers (including ftpmasters,
security, QA, etc.), and the end users than does adding one symlink in
an existing package.

Again, if the new "open" has features that "see" does not, let's
identify them so we can decide whether they belong in the mime-support
package or in a new package.  If the only advantage is the name, I
cannot understand why anyone would object to at least approaching the
mime-support maintainers before plowing ahead with a new package.

...Marvin


Reply to: