FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-31-2012, 08:32 PM
Russ Allbery
 
Default Breaking programs because a not yet implemented solution exists in theory

Cyril Brulebois <kibi@debian.org> writes:
> Andreas Tille <tille@debian.org> (31/01/2012):

>> This is definitely not "wishlist" - but I do not like to play
>> severity-changing pingpong.

> Please avoid “To: debian-devel@” when you disagree with maintainers on
> individual bugs; thanks already.

Er, peer review seems like a primary purpose of the mailing list to me.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8739avy2wa.fsf@windlord.stanford.edu">http://lists.debian.org/8739avy2wa.fsf@windlord.stanford.edu
 
Old 02-01-2012, 08:14 AM
Russ Allbery
 
Default Breaking programs because a not yet implemented solution exists in theory

Andreas Tille <andreas@an3as.eu> writes:

> Well, from my perspective I was bored the first time when xpdf came up
> when I was expecting evince. After purging xpdf I learned that see does
> not find any pdf viewer. Sorry if I did not realised any discussion
> seven monthes ago noch any one-line helpers.

> So were can I read about which one-liner should be added to what package
> to fix the problem you decided to force upon others.

So, I don't have a one-line script, but I generally agree with Josselin
that maintaining the same information in two places is a bad idea. The
basic idea of what needs to be done is to convert the information in the
desktop files into the equivalent of a /usr/lib/mime/packages file.

For example, /usr/share/applications/xpdf.desktop has:

[Desktop Entry]
Name=xpdf
GenericName=PDF viewer
Comment=View PDF files
Exec=xpdf
Icon=xpdf
Terminal=false
Type=Application
MimeType=application/pdf;
Categories=Viewer;Graphics;

/usr/lib/mime/packages/xpdf has:

application/pdf; /usr/bin/xpdf %s; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf; priority=6
application/x-pdf; /usr/bin/xpdf %s; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf; priority=6

Obviously, the first field comes straight from MimeType (and, in general,
from the list of values in MimeType). I think one has to make the
assumption that one can add %s after Exec in order to load a file, since
the desktop entry doesn't have an equivalent of the command. The test is
the same for any application that says Terminal=false.

The description and nametemplate don't come from the same place. Those
come from /usr/share/mime/application/pdf.xml, and are the same for all
application/pdf entries.

The priority is a more interesting problem. I'm not sure how the desktop
specification assigns priorities when multiple applications can handle the
same MIME type.

This doesn't look like a trivial tool, but it looks possible to write.
What I'd do is teach update-mime how to handle desktop files as well and
then add a trigger for changes in /usr/share/applications.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k446oqzh.fsf@windlord.stanford.edu">http://lists.debian.org/87k446oqzh.fsf@windlord.stanford.edu
 
Old 02-01-2012, 08:35 AM
Josselin Mouette
 
Default Breaking programs because a not yet implemented solution exists in theory

Le mercredi 01 février 2012 * 01:14 -0800, Russ Allbery a écrit :
> The description and nametemplate don't come from the same place. Those
> come from /usr/share/mime/application/pdf.xml, and are the same for all
> application/pdf entries.

That, and also you have to take into account aliases (different MIME
types characterizing the same file type) and subclasses (for example ODT
is a subclass of ZIP, yet you want to prioritize OOo if it is installed
to open it).

> The priority is a more interesting problem. I'm not sure how the desktop
> specification assigns priorities when multiple applications can handle the
> same MIME type.

Yes, that’s where things become interesting. The freedesktop
specification handles defaults, instead of priorities. In Debian, we
take advantage of this to provide per-environment defaults. This way,
you can prioritize GNOME applications over KDE ones when running GNOME,
and vice versa. I don’t know if it’s possible to match that with the
mailcap system.

Cheers,
--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1328088922.9702.289.camel@pi0307572">http://lists.debian.org/1328088922.9702.289.camel@pi0307572
 
Old 02-01-2012, 08:51 AM
Russ Allbery
 
Default Breaking programs because a not yet implemented solution exists in theory

Josselin Mouette <joss@debian.org> writes:
> Le mercredi 01 février 2012 * 01:14 -0800, Russ Allbery a écrit :

>> The description and nametemplate don't come from the same place. Those
>> come from /usr/share/mime/application/pdf.xml, and are the same for all
>> application/pdf entries.

> That, and also you have to take into account aliases (different MIME
> types characterizing the same file type) and subclasses (for example ODT
> is a subclass of ZIP, yet you want to prioritize OOo if it is installed
> to open it).

Actually, I don't think you have to take any of that into account when
translating to mailcap, since it doesn't have this concept. It has a
mapping of MIME types to applications, and that's it. If you don't have a
mapping for that particular MIME type, the only other option you have is a
wildcard, and only text/* is really meaningful. So I think you can just
ignore this property; mailcap just doesn't have any way of opening ODT
files with a ZIP viewer when OOo isn't installed.

It's been a long time since I've done mailcap, though.

> Yes, that’s where things become interesting. The freedesktop
> specification handles defaults, instead of priorities. In Debian, we
> take advantage of this to provide per-environment defaults. This way,
> you can prioritize GNOME applications over KDE ones when running GNOME,
> and vice versa. I don’t know if it’s possible to match that with the
> mailcap system.

It isn't. You get a system list and a user list, and that's all you get.
So there's no way to switch based on other system properties.

Well, you can use test to eliminate an application from consideration
entirely, but I don't think that fits for this.

That probably means that there's just no way to translate priority, and
you're going to have to guess or just take applications at random if
multiple applications with a desktop file manage the same MIME type. I
suppose you could apply a heuristic like using the application that has
the fewest MIME types it handles; I'm not sure if that's the right
approach.

The main place that mailcap is richer than the desktop file that I can see
is that mailcap allows you to express the exact command line (including
putting %s at different places if needed) and lets you specify different
commands for viewing, editing, and printing. For example:

message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal

I don't know if there's any way to do that with desktop files.

Also, I don't think there's a desktop equivalent of copiousoutput.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fweuop9m.fsf@windlord.stanford.edu">http://lists.debian.org/87fweuop9m.fsf@windlord.stanford.edu
 
Old 02-01-2012, 02:03 PM
Andreas Tille
 
Default Breaking programs because a not yet implemented solution exists in theory

Hi,

On Wed, Feb 01, 2012 at 01:51:17AM -0800, Russ Allbery wrote:
> Josselin Mouette <joss@debian.org> writes:
> ...

I confirm that I agree that we should prevent duplication of data which
was stated in previous mails.

> The main place that mailcap is richer than the desktop file that I can see
> is that mailcap allows you to express the exact command line (including
> putting %s at different places if needed) and lets you specify different
> commands for viewing, editing, and printing. For example:
>
> message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
>
> I don't know if there's any way to do that with desktop files.
>
> Also, I don't think there's a desktop equivalent of copiousoutput.

Assuming that Russ did not overlooked something this means that mailcap
entries can not generatet from desktop files. So the one-liners
mentioned by Josselin which might solve 50% of the task could not easily
enhanced to two-liners doing 100% which do all the work. In other words
we dropped support for a technique that is used by several programs and
it seems a replacement is either hard to do or not possible at all.

I personally would cope with this by installing a local package carrying
the mailcap entries I need. However that can hardly be a solution for
our users. As a general solution I would see two ways:

1. Stop droping *.mime files from packages and reinjecting them.
2. Create a general mailcap entry collection package which works
around maintainers unwilling to support mailcap.

I'd prefer 1. because I see no point in just droping what worked in the
past and has no visible chance to break something heavily. Please
correct me if I'm wrong.

Kind regards

Andreas.


--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120201150318.GA10133@an3as.eu">http://lists.debian.org/20120201150318.GA10133@an3as.eu
 
Old 02-01-2012, 03:03 PM
Michael Biebl
 
Default Breaking programs because a not yet implemented solution exists in theory

On 01.02.2012 16:03, Andreas Tille wrote:
> Hi,
>
> On Wed, Feb 01, 2012 at 01:51:17AM -0800, Russ Allbery wrote:

>> The main place that mailcap is richer than the desktop file that I can see
>> is that mailcap allows you to express the exact command line (including
>> putting %s at different places if needed) and lets you specify different
>> commands for viewing, editing, and printing. For example:
>>
>> message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
>>
>> I don't know if there's any way to do that with desktop files.
>>
>> Also, I don't think there's a desktop equivalent of copiousoutput.
>
> Assuming that Russ did not overlooked something this means that mailcap
> entries can not generatet from desktop files. So the one-liners
> mentioned by Josselin which might solve 50% of the task could not easily
> enhanced to two-liners doing 100% which do all the work. In other words
> we dropped support for a technique that is used by several programs and
> it seems a replacement is either hard to do or not possible at all.

Tools like mutt, which need the extended mailcap syntax, can certainly
continue to ship a mime file.

If a package ships both a desktop and a mime file, the conversion-tool
could simply skip the automatic generation of the mailcap entries under
the assumption that the manually written ones take precedence.


Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
 
Old 02-01-2012, 09:16 PM
Russ Allbery
 
Default Breaking programs because a not yet implemented solution exists in theory

Michael Biebl <biebl@debian.org> writes:
> On 01.02.2012 16:03, Andreas Tille wrote:

>> Assuming that Russ did not overlooked something this means that mailcap
>> entries can not generatet from desktop files. So the one-liners
>> mentioned by Josselin which might solve 50% of the task could not
>> easily enhanced to two-liners doing 100% which do all the work. In
>> other words we dropped support for a technique that is used by several
>> programs and it seems a replacement is either hard to do or not
>> possible at all.

> Tools like mutt, which need the extended mailcap syntax, can certainly
> continue to ship a mime file.

> If a package ships both a desktop and a mime file, the conversion-tool
> could simply skip the automatic generation of the mailcap entries under
> the assumption that the manually written ones take precedence.

Yeah, that's basically the sort of design that I was thinking of.

The programs on my system that use the extended mailcap syntax are all
ones that aren't very invested in using *.desktop files right now anyway.
Things like copiousoutput are useful for commands that don't really fall
into the core area intended to be addressed by *.desktop.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aa522o8e.fsf@windlord.stanford.edu">http://lists.debian.org/87aa522o8e.fsf@windlord.stanford.edu
 
Old 02-01-2012, 09:45 PM
Andreas Tille
 
Default Breaking programs because a not yet implemented solution exists in theory

On Wed, Feb 01, 2012 at 05:03:17PM +0100, Michael Biebl wrote:
>
> Tools like mutt, which need the extended mailcap syntax, can certainly
> continue to ship a mime file.
>
> If a package ships both a desktop and a mime file, the conversion-tool
> could simply skip the automatic generation of the mailcap entries under
> the assumption that the manually written ones take precedence.

Could somebody please answer my implicite question why the mime files
are removed before such a conversion tool exists and thus shamelessly
are breaking applications that depend from it.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120201224515.GJ10133@an3as.eu">http://lists.debian.org/20120201224515.GJ10133@an3as.eu
 
Old 02-01-2012, 09:52 PM
Russ Allbery
 
Default Breaking programs because a not yet implemented solution exists in theory

Andreas Tille <andreas@an3as.eu> writes:

> Could somebody please answer my implicite question why the mime files
> are removed before such a conversion tool exists and thus shamelessly
> are breaking applications that depend from it.

Josselin did answer your question. To paraphrase my understanding of the
answer: because he (they, probably, but he only spoke for himself) doesn't
want to maintain those files because they duplicate information stored in
another system that he considers superior for the purposes of what he's
doing, their lack doesn't what he views as his primary target audience,
and by removing them he forces people who care about the mailcap support
to do the work of deriving that information from desktop files if they
care enough to keep the system working.

I can understand not liking this answer, but you did get an answer.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87liom180p.fsf@windlord.stanford.edu">http://lists.debian.org/87liom180p.fsf@windlord.stanford.edu
 
Old 02-02-2012, 06:26 AM
Andreas Tille
 
Default Breaking programs because a not yet implemented solution exists in theory

On Wed, Feb 01, 2012 at 02:52:22PM -0800, Russ Allbery wrote:
> Josselin did answer your question. To paraphrase my understanding of the
> answer: because he (they, probably, but he only spoke for himself) doesn't
> want to maintain those files because they duplicate information stored in
> another system that he considers superior for the purposes of what he's
> doing, their lack doesn't what he views as his primary target audience,
> and by removing them he forces people who care about the mailcap support
> to do the work of deriving that information from desktop files if they
> care enough to keep the system working.

OK, but in this case I think #658139 (and probably friends?) is
incorrectly handled. It should not be wishlist + wontfix because
packages are actually broken. If Josselin and others are regarding this
as sombody else's problem the bug should be rather reassigned to
somebody else's package - in this case perhaps general comes to mind
because it affects several packages. Josselin was expecting the
"general void" to solve the problem and thus the bug should rather go
there (by keeping important severity).

Alternatively it also could be reassigned to mime-support because other
broken packages are basically relying on this one. However simply
hiding a problem by decreasing severity is a strange way to handle
something and assuming it would force somebody else to work.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120202072622.GC31034@an3as.eu">http://lists.debian.org/20120202072622.GC31034@an3as.eu
 

Thread Tools




All times are GMT. The time now is 09:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org