<div dir="ltr"><div>Hello everyone,</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>This is only happens when the activities provide a mimetypes.xml files in the ./actvity/ directory.</div><div><br></div><div>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:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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<br><jo0nas> for Debian I will remove mimetype symlinks and properly _install_ (not symlink) relevant files into install area<br><tch__> jo0nas, thanks for the insight, what do you suggest we can do to improve that in upstream side?<br><jo0nas> simplest approach is to copy, not symlink<br><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<br><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<br><jo0nas> to cover both user-pseudo-install and system-real-install sugar-toolkit-gtk3 needs to distinguish between those two<br><tch__> jo0nas, (try with a package that has an actvity/mimetypes.xml file)<br><tch__> s/package/activity/<br><jo0nas> no, I did not notice binary MIME database files getting included in packages<br><tch__> jo0nas, it happened to me, <br><tch__> jo0nas, let me see one example,<br>* artista_ has quit (Ping timeout: 244 seconds)<br><jo0nas> at what path inside the .deb package did the binary MIME file(s) get installed?<br><tch__> /usr/share/mime/<br><jo0nas> did you use CDBS <a href="http://python-sugar.mk">python-sugar.mk</a> snippet?<br><tch__> yes, I follow pretty much your files<br><jo0nas> on Debian Sid, or...?  Which activity?<br><tch__> jo0nas, I am currently testing in ubuntu trusty, but I remember double checking this on Jessie<br><tch__> jo0nas, and with some of the new activities I packaged, ie., stopwatch <br>* k_yash has quit (Ping timeout: 246 seconds)<br><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<br><tch__> jo0nas, maybe we can sketch something together? there is still time to push it on this devel cycle<br><jo0nas> I really don't know the internals good enough<br><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<br><tch__> jo0nas, but it can become a burden to packaging too,<br><jo0nas> I just see that I currently prefix calls to install.py with this: LANG=C XDG_DATA_HOME="$(DEB_DESTDIR)/usr/share"<br><jo0nas> ...in addition to setting --prefix="$(DEB_DESTDIR)/usr"<br><tch__> jo0nas, so, if we can find a decent solution for upstream, even if its copying the files it could work<br><tch__> maybe copying the files + avoiding update step?<br><tch__> then packaging realm only needs to run the update in something like postinst<br><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"<br><jo0nas> makes sense to me that I instead would do this: python setup.py install --system --prefix="$(DEB_DESTDIR)/usr"<br><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)<br><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<br><jo0nas> not sure if the option would be better named --shared<br><tch__> jo0nas, neither I to be honest, but what about copying this conversation to the sugar-ml?<br><jo0nas> feel free to do so - but please keep me explicitly CCed, as I am not subscribed there<br><tch__> jo0nas, if we can think and agree on something I could try to land it next week<br><tch__> jo0nas, of course,</blockquote><div><br></div><div>So basically, there are 2 problems.</div><div><br></div><div>1. symlinks creation during ./setup.py --install (for installing the mimetypes.xml file .svg icons for mime types declared in <a href="http://activity.info">activity.info</a>)  and,</div><div>2. the execution of update-mime-database (which generates the database files).</div><div><br></div><div>Possible solutions:</div><div><br></div><div>a) for 1), we could copy or move these files instead of creation symlinks?</div><div>b) for 2) we could provide an option to skip the update-mime-database execution? I already prepared a patch for this [1].</div><div><br></div><div>Let me know what you think,</div><div><br></div><div>Regards,</div><div>Martin.</div><div><br></div><div>Refs:</div><div>1. <a href="https://github.com/tchx84/sugar-toolkit-gtk3/commits/disable-update-mimedb-try2">https://github.com/tchx84/sugar-toolkit-gtk3/commits/disable-update-mimedb-try2</a></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>