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
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel