Bug#673819: info:-url handled by yelp
chrysn
chrysn at fsfe.org
Mon May 21 15:27:55 UTC 2012
Package: libgnome2-0
Version: 2.32.1-2
Severity: minor
File: /usr/bin/gnome-open
summary
=======
the 'info' url scheme is used for access to yelp, although there is a
real url scheme with that name.
the issue is not urgent, but i'd suggest to migrate whatever is using
this to a registered url scheme.
problem description
===================
when calling gnome-open with an info uri (eg `gnome-open
'info:doi/10.1006/jmbi.1998.2354'`), yelp is called, and the info:
prefix is mapped to another prefix, 'man:'.
the info url schema is registered by rfc 4452 and used for a plethorea
of applications as shown in [1], among them many related to
identification of publications.
while i am currently not aware of any application that'd handle, for
example, an 'info:lccn/' url (and display information gathered from the
library of congress), chances are that for one of the many info:
namespace users, ther'll sooner or later exist a debian package, and
then they'll conflict.
possibilities for solutions
===========================
mainly depends on how the info url scheme is currently used -- probably
it is related to gnu info[2], and i've never really used that.
if info pages don't yet have their own scheme, one could be created in a
publicly usable space (http, tag[3] or even registed, possibly even in
the info: space.
it is possible that gnome's current mechanism for assigning scheme
handlers is not powerful enough to handle that yet, as it seems to me it
only looks at the scheme and doesn't provide ways for applications to
filter urls inside their scheme, as it is currently done on the android
platoform[4] (their solution won't quite cut it here either, i'm aware
this is a difficult topic, as every scheme has its own rules for
decomposition). such problems would also affect library programs like
the above-described hypothetical library of congress lookup tool, which
would want to filter for 'info:lccn/*' urls.
assignment
==========
i couldn't identify precisely where the info: association comes from, as
dconf shows neither a 'man' nor an 'info' handler in
/desktop/gnome/url-handlers/, so my assignment to libgnome2 might be
wrong; moreover, migration away from the info: schema not only affects
the package that binds all info urls to yelp, but all users of that
prefix, provided it is not just a relic.
references
==========
[1] http://info-uri.info/registry/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc
[2] http://www.gnu.org/software/texinfo/
[3] http://www.taguri.org/
[4] http://developer.android.com/guide/topics/manifest/data-element.html
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libgnome2-0 depends on:
ii gvfs 1.12.3-1
ii libbonobo2-0 2.24.3-1
ii libc6 2.13-32
ii libcanberra0 0.28-4
ii libgconf2-4 3.2.5-1
ii libglib2.0-0 2.32.3-1
ii libgnome2-common 2.32.1-2
ii libgnomevfs2-0 1:2.24.4-1
ii liborbit2 1:2.14.19-0.1
ii libpopt0 1.16-5
libgnome2-0 recommends no packages.
libgnome2-0 suggests no packages.
-- no debconf information
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20120521/5fbbb3a1/attachment.pgp>
More information about the pkg-gnome-maintainers
mailing list