View Single Post
Old 12-18-2020, 02:52 AM   #13
eschwartz
Ex-Helpdesk Junkie
eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.eschwartz ought to be getting tired of karma fortunes by now.
 
eschwartz's Avatar
 
Posts: 19,421
Karma: 85400180
Join Date: Nov 2012
Location: The Beaten Path, USA, Roundworld, This Side of Infinity
Device: Kindle Touch fw5.3.7 (Wifi only)
Quote:
Originally Posted by frmald View Post
That's wonderful and I appreciate that, but perhaps you might consider packaging all useful resources (like the desktop file?) in the "isolated install", to make repackaging easier.
Quote:
Originally Posted by frmald View Post
Because putting a normal desktop file in the install directory, or considering independent packaging efforts was... too ideologically disturbing?
There's nothing remotely extraordinary about a program that generates desktop files in the Makefile or similar. Which is precisely what `python setup.py install` is.

I don't much care about the binary installer, but as I mentioned above it's not hard to just pass --root to it (and play Freedesktop XDG-utils games for overriding their default target). So I don't see how this is ideologically a battle between ideologies. Given the files are dynamically generated from up to date info, I don't see much point in shipping them again and having postinstall merely copy them. It sounds more complex, essentially busywork.

Quote:
Originally Posted by frmald View Post
Anyway, who am I kidding, calibre even uses BINARY files, instead of scripts, to set up paths. Hence, ebook-viewer vs bin/ebook-viewer. Wonderfully non-discoverable and opaque. I *suppose* it's just a matter of setting up LD_LIBRARY_PATH, but who knows, there's stuff both in lib/ and libexec/.
The from source version uses python scripts.

The binary version is based on https://github.com/kovidgoyal/calibr...nux/launcher.c
I'm not sure why this is especially evil, to use C launchers instead of shellscripts. Why is it supposed to be discoverable? Is a C program that *isn't* a launcher also supposed to be discoverable without disassembling?
eschwartz is offline   Reply With Quote