[Sugar-devel] Bundlebuilder and mime-type related files

[Martin Abente]

Hello everyone,

Recently, when packaging activities for Debian/Ubuntu, I noticed that my
packaged activities contained many unexpected/unnecessary files under
/usr/share/mime. These files were clashing with other activities files I
packaged, because they were under the exact same path and name.

After investigating, I noticed that  our bundlebindler (ie., activity
installation script) makes a call to "update-mime-database" tool and also
creates some symlinks, and that Fedora and Debian packaging files uses
bundlebuilder (through /setup.py install) to populate the packages files
and dirs. The problem is not present in Fedora packages, my first guess is
it because /usr/share/mime directory is ignored from the final package
(doesn't seem to be the case for Debian/Ubuntu).

This is only happens when the activities provide a mimetypes.xml files in
the ./actvity/ directory.

The idea of this thread is to see if we can agree on a solution for this
problem. Here is an initial discussion that happened over IRC between Jonas
and me:

<jo0nas> tch__: sugar3/bundle/activitybundle symlink handling seems
> fundamentally wrong to me: It creates symlink from _build_ area to
> _install_ area <- that only works when build area is same host as install,
> and is not purged
> <jo0nas> for Debian I will remove mimetype symlinks and properly _install_
> (not symlink) relevant files into install area
> <tch__> jo0nas, thanks for the insight, what do you suggest we can do to
> improve that in upstream side?
> <jo0nas> simplest approach is to copy, not symlink
> <jo0nas> I suspect symlinking is done to save space - but it has the
> assumption that build (a.k.a. unpacking-source for most activitites) path
> will be sustained after (partly-pseudo-)install
> <tch__> jo0nas, yes, and did you also notice the update-mime-database
> stuff? it _does_ creates database files and these _are_ included in the
> packages
> <jo0nas> to cover both user-pseudo-install and system-real-install
> sugar-toolkit-gtk3 needs to distinguish between those two
> <tch__> jo0nas, (try with a package that has an actvity/mimetypes.xml file)
> <tch__> s/package/activity/
> <jo0nas> no, I did not notice binary MIME database files getting included
> in packages
> <tch__> jo0nas, it happened to me,
> <tch__> jo0nas, let me see one example,
> * artista_ has quit (Ping timeout: 244 seconds)
> <jo0nas> at what path inside the .deb package did the binary MIME file(s)
> get installed?
> <tch__> /usr/share/mime/
> <jo0nas> did you use CDBS python-sugar.mk snippet?
> <tch__> yes, I follow pretty much your files
> <jo0nas> on Debian Sid, or...?  Which activity?
> <tch__> jo0nas, I am currently testing in ubuntu trusty, but I remember
> double checking this on Jessie
> <tch__> jo0nas, and with some of the new activities I packaged, ie.,
> stopwatch
> * k_yash has quit (Ping timeout: 246 seconds)
> <jo0nas> it would be nice for sugar-toolkit-gtk3 to grow a --system flag -
> I already now paper over its relying on user-specific XDG paths
> <tch__> jo0nas, maybe we can sketch something together? there is still
> time to push it on this devel cycle
> <jo0nas> I really don't know the internals good enough
> <tch__> jo0nas, I considered something like you mentioned earlier, to add
> an option to setup.py to completely avoid creating these symliks and update
> database, and leave that to packaging realm
> <tch__> jo0nas, but it can become a burden to packaging too,
> <jo0nas> I just see that I currently prefix calls to install.py with this:
> LANG=C XDG_DATA_HOME="$(DEB_DESTDIR)/usr/share"
> <jo0nas> ...in addition to setting --prefix="$(DEB_DESTDIR)/usr"
> <tch__> jo0nas, so, if we can find a decent solution for upstream, even if
> its copying the files it could work
> <tch__> maybe copying the files + avoiding update step?
> <tch__> then packaging realm only needs to run the update in something
> like postinst
> <jo0nas> this is essentially how I currently install: LANG=C
> XDG_DATA_HOME="$(DEB_DESTDIR)/usr/share" python setup.py install
> --prefix="$(DEB_DESTDIR)/usr"
> <jo0nas> makes sense to me that I instead would do this: python setup.py
> install --system --prefix="$(DEB_DESTDIR)/usr"
> <jo0nas> ...which would then a) set paths based only on --prefix, not some
> parts based on XDG dirs, and b) really truly fully install (i.e. copy stuff
> not symlink)
> <jo0nas> ...and according to you it should then also c) avoid running
> update-mime-database, but I have not seen that go wrong myself yet
> <jo0nas> not sure if the option would be better named --shared
> <tch__> jo0nas, neither I to be honest, but what about copying this
> conversation to the sugar-ml?
> <jo0nas> feel free to do so - but please keep me explicitly CCed, as I am
> not subscribed there
> <tch__> jo0nas, if we can think and agree on something I could try to land
> it next week
> <tch__> jo0nas, of course,


So basically, there are 2 problems.

1. symlinks creation during ./setup.py --install (for installing the
mimetypes.xml file .svg icons for mime types declared in activity.info)
 and,
2. the execution of update-mime-database (which generates the database
files).

Possible solutions:

a) for 1), we could copy or move these files instead of creation symlinks?
b) for 2) we could provide an option to skip the update-mime-database
execution? I already prepared a patch for this [1].

Let me know what you think,

Regards,
Martin.

Refs:
1.
https://github.com/tchx84/sugar-toolkit-gtk3/commits/disable-update-mimedb-try2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150525/da16dd63/attachment.html>