I had no knowledge about freedesktop mime files, but they seem to be pretty simple, so just 2 little comments :
* that french translation seems pretty useless, I would just remove it :)
* why not just simply using the .pkg.tar.gz extension?
It seems really weird to include the arch there. Even if only i686 and x86 64 are officially supported, it doesn't mean you are limited to these arch, you could build pacman packages for any arch. There were also some discussions about the "any" arch for arch-independent packages.
Besides, the arch was not originally included in the filenames, it was added with pacman 3 I think, for the current/extra repos.
But there might be still some old packages there that don't have it. And all packages from the community repo don't have it either.
Finally, in the default /etc/makepkg.conf we have the following variables :
BUILDSCRIPT='PKGBUILD'
PKGEXT='.pkg.tar.gz'
SRCEXT='.src.tar.gz'

Thanks for your comments.

- The french translation is useless, I agree. It is just there to show that there are i18n stuffs too in the xml file.
- I agree about the .pkg.tar.gz extension. The more I think about it the more I find having architecture dependend stuffs is bad :-)
- I forgot about .src.tar.gz. I thought it was just a convient way to upload files to AUR ... Do you see it as a src.rpm equivalent ?

Also I was thinking about a dedicated package in a first stage, such archlinux-freedesktop or something similar, before submitting a request to freedesktop.
This package could have the .xml files to define the MIME data, and also some icones for nice display in Nautilus,Konqueror,Thunar and so.

I have identified a package which will need a patch (or a request upstream if it is official at freedesktop) : fille-roller. The mime types are hardcoded in this soft and it does not seem to handle 'sub-class-of' : when enabling the mime type for pkg.tar.gz (sub-class-of tar.gz) fille-roller do not recognize it as tar.gz ... I am going to investigate further.

In any case, further studies must be done (be sure I will), but I think it would be great to have this idea brought and discussed on dev side :-)

Thanks again !

I can't test any of this stuff now, but I like this and I think upstream is the place to go with this stuff. Let's make sure we get a well thought out file to send upstream and then we can go with it.

We could also add db.tar.gz as a recognized file type too- I haven't looked at how these things are recognized but the easy way to see if a file is a database is to look for desc and depends files inside one level of subdirectories.

On that note, is it wise for us to hardcode the .tar.gz extensions? A pacman package can be recognized by the .PKGINFO file inside rather than just the extension if that is possible. But I don't want to hijack this, I will leave it up to you. Thanks for looking into this.

Hello,

If you want to test all this you can put the Override.xml file attached into you $HOME/.local/share/mime/packages/ directory.
Then run the command (as current user, no need to be root) 'update-mime-database' to update the database.
What is great is that it does not alter the whole MIME database, just the one used by your current user :-)
This is all explained here : http://freedesktop.org/wiki/Specifications/AddingMIMETutor

I have also attached freedesktop.org.xml which is where what we are talking about will one day (hopefully) be integrated.
This file can be used to see how others cope with the file type detection.

To answer Dan, we do not need to use the .tar.gz extension as long as we can identify our objects (PKGBUILD, packages, src packages, data bases ...) by examining the binary file at a defined offset. Have a look at how ELF dynamic libraries or RPM packages are detected in the freedesktop.org.xml.
For us it will work if we can warranty that the .PKGINFO file will always be at the same offset (binary speaking) in the tarball...


Lets make a little status on what we have :

* PKGBUILD : can only be identified by the file name pattern '^PKGBUILD$'.

* source tarball : can be identified by the file name pattern '*.src.tar.gz' or by a binary offset if we can warranty that the PKGBUILD file is always at the same binary position in the tarball.

* binary package : can be identified by the file name pattern '*.pkg.tar.gz' or by a binary offset if we can warranty that the .PKGINFO is always at the same binary position in the tarball.

* database tarball : I am not sure what is this tarball for, can you please give a quick recap ;-) ?

Also we have to take care about inheritance : a source tarball or binary package tarball may inherit from the application/x-compressed-tar.
Thus a well designed compression/decompression application (File-Roller is a bad example with hardcodes everywhere) can handle those files without knowing everything about them.

I hope I answered Dan ...

We need to status on which pacman objects (PKGBUILD, src tarball, pkg tarball, db tarball) we want to "freedesktopize", which type name we are going to use for this objects, from which other type they inherit (I will give you some proposal) and which criteria will be used for mime type matching according to my comments above.

Cheers,
Chicha

Afaik the order of the files inside the tarball is not guaranteed : even if it was always sorted alphabetically, in the future we might include other dot FILES that would alter the order of .PKGINFO in the tarball.
But even without talking about that, the tarball is compressed so I don't see how we could make any detection on the resulting package, without decompressing it first.

Given that, I am afraid the only way is to rely on the extension.

I disagree that this needs to be done upstream. It's pretty common for software to ship their own mime definitions, and now with hooks, the pacman package wouldn't have to depend on shared-mime-info. Why not put it into contrib after some updating/modifications?

Here's my first attempt. Any interest at all? Maybe make them more generic with "pacman" instead of "Arch"?