[Sugar-devel] Bundlebuilder and mime-type related files
martin.abente.lahaye at gmail.com
Mon May 25 14:21:55 EDT 2015
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
<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
> <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.,
> * 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
> <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)
2. the execution of update-mime-database (which generates the database
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 .
Let me know what you think,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel