[freedict] Re: discussion: make install and other FD improvements
- From: Einhard Leichtfuß <alguien@xxxxxxxxxxxxx>
- To: freedict@xxxxxxxxxxxxx
- Date: Sun, 13 May 2018 21:31:27 +0200
Hi,
On 2018-05-05 17:33, Sebastian Humenda wrote:
Hi
Einhard Leichtfuß schrieb am 01.05.2018, 14:51 +0200:
On Arch at least, dictdconfig is not available. If I recall correctly, I
was once told it would be debian specific.
Right, but doesn't the script also check whether dictdconfig is available?
Would
be great if it'd work on non-Debian systems, too :).
Yes; if I recall correctly, I already thought of this once. At that
time, I decided to take the easiest option and perform the task
separately for each package using an (Arch specific) .install file.
Regarding the fact that dictdconfig is Debian specific, I'd say the
optimal solution would be to have dictdconfig (or something else
performing the same task) included in dictd. Alternatively, I might
create a separate package in the Arch User Repository to contain nothing
but such a script.
However, on Arch in particular, there exists an (unwritten?) policy not
to restart anything automatically upon package actions such as
installation. I do currently not adhere to this policy believing that
most people do not run dictd as a publicly accessible server. Also,
installing / upgrading a dictionary does not make much sense without
restarting dictd.
Hence, I would probably want to discuss things in the Arch world before
doing any Arch specific work.
I actually meant the same, my bad. But anyway, dictionary != package. I
wouldn't
expect a `make install` to install files under /usr/share/doc/lat-deu, this is
the package manager's job.
OK.
- Checksums are great. Maybe you could provide such in the API?
Currently, my script fetches the sources / binaries on every update,
just to calculate the checksum.
Brilliant, what do you want, MD5?
Since there should not be a security impact (is there one?), MD5 should
be fine. Though I generally prefer stronger ones, such as SHA512.
Ok, each file that we ship (and used to ship) now also has a .sha512
counterpart. It's also in the API and documented on the wiki. The only bit
missing: how should it be presented on the website? I'm very uncreative here.
The files I found, though the API appears unchanged to me. That helps me
already though, so thanks!
Concerning presentation, I'd suggest a link `[SHA512]' after each
download link on the downloads page, pointing to the corresponding
.sha512 file.
Greetings,
Einhard
Attachment:
signature.asc
Description: OpenPGP digital signature
Other related posts:
