Arch Linux

respiranto

Member

Registered: 2015-05-15

Posts: 479

Website

dictd database - PKGBUILD

I am currently trying to write my first PKGBUILD, for a dictd-database, more specifically dictd-freedict-eng-deu, at least for now.
Unfortunately I am confused at some points.

1.
I don't know where to put the files. The manpage of dictd mentions /usr/share as the directory to store such databases:

FILES
       [...]
       /usr/share
              The  default  directory  for  dictd  databases  (.index   and
              .dict[.dz] files)

- which does not make much sense, since /usr/share as far as I know is not intended for 'direct use', i.e. placing regular files inside. Instead usually a directory for the respective program is created.
That's also how the previous packagers did it, they put all the files into /usr/share/dictd.
To confuse me even more:

# The initrc script scans /usr/lib/dict and adds all of the dictionaries
# it finds here.

The last packager of the eng-fra database did complain about the latter directory not being scanned as well.

Furthermore there is also a directory /usr/share/dict, which is created by the dictd package.

2.
Whichever location I choose, dictd does not recognize the dictionaries by itself. The user has to add / configure them in /etc/dict/dictd.conf.
Confusingly, in the old .install-scripts, if existing, the respective daemon was "restarted in order to detect the new dictionary" (via rc.d script).
So there must be a way to make dictd find the dictionaries by itself, but I was not able to find out which (I tried all of /usr/share/{,dict{,d}}/ and /usr/lib/dict)

Unfortunately there is no such directory like dictd.conf.d/.
Of course I could create one but then I would have to modify dictd.conf to read its contents (if it's possible), but I don't think, a package should modify another one's files. Obviously in that case I could also 'simply' write a script for each database package to add itself to dictd.conf.

3.
The old PKGBUILDs use mv in their build() functions.
Of course I will use package() instead, but I am not sure whether moving the files is correct, since the src/ folder will be empty afterwards.
If not, should copying or hard-linking be preferred? - I presume the former.

The only dictd-database package I could find in AUR4, dict-freedict-eng-mal, still does not use the package() function, but cp instead of mv.

4.
Furthermore the last mentioned package compiles the databases from source, while all the others I've seen do not.
Is it a good idea to compile in this case? I don't think there is any security issue here, as the database should not be able to cause any damage when read by dictd.

5.
Upstream releases e.g. the eng-deu and deu-eng databases separately, so they also do have different version numbers. The dict-freedict-eng-fra package has actually been packaged with two version numbers, separated by a comma.
I don't assume this good practice and, if nobody disagrees, will package both databases separately.

Hopefully somebody on this forum has some knowledge of dictd, which is not very probable, regarding the last packaging date of most of the databases.
Therefore I encourage also all the other, to provide any help, especially since many questions are more general.

Thanks in advance!

EDIT: grammar; semantical correction.

Last edited by respiranto (2015-08-05 21:55:19)

respiranto

Member

Registered: 2015-05-15

Posts: 479

Website

Re: dictd database - PKGBUILD

I've just checked how Ubuntu does this stuff and found out that it uses a perl-script, named dictdconfig, that updates a database which is in turn used by dictd to find the dictionaries.
However, this script (or a smilar one) is not provided by the Arch package, so it's probably Ubuntu / Debian specific.

So I will just do everything as I want to,  requiring the user to configure dictd on his own.
That is:
1. /usr/share/dictd as location for databases
2. -
3. cp instead of mv
4. source instead of precompiled .dict.dz files
5. separate packages for e.g. eng-deu and deu-eng databases

EDIT: grammar

UPDATE:
4. I stick with the binaries, because else I would have to package freedict-tools as well, which would require a some modifications, which are from my point of view not worth the gain of being able to compile the dictionary databases instead of directly downloading the precompiled ones.
However, if somebody should actually want the freedict-tools, e.g. to write TEI-dictionaries on his own, he may ask me, so I might find some time to package the freedict-tools as well.

Last edited by respiranto (2015-08-07 16:33:26)

severach

Member

Registered: 2015-05-23

Posts: 192

Re: dictd database - PKGBUILD

1. pacman -Qo cracklib-small
/usr/share/dict/cracklib-small is owned by cracklib 2.9.4-1

That doesn't look like it has anything to do with dictd.

2. I don't see any dir scanning in the code. I'd just improve the installer to add and remove the config lines automatically.

3. This isn't a development package so there isn't any use for anything left in src. There's no practical difference between cp and mv. You can't link to anything in src. It should be deleted when you're done.

progandy

Member

Registered: 2012-05-17

Posts: 5,190

Re: dictd database - PKGBUILD

1. pacman -Qo cracklib-small
/usr/share/dict/cracklib-small is owned by cracklib 2.9.4-1

He uses /usr/share/dictd, just as the old dictd initrc script.

2. I don't see any dir scanning in the code.

That code was in the initrc file and has been removed.

I'd just improve the installer to add and remove the config lines automatically.

That is possible. Or you can create a new package for dictdconfig and maybe depend on it. Maybe only use it as an optdepend and then call it in the install script if it is available.

Last edited by progandy (2015-08-08 12:01:34)

---

| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

respiranto

Member

Registered: 2015-05-15

Posts: 479

Website

Re: dictd database - PKGBUILD

1. pacman -Qo cracklib-small
/usr/share/dict/cracklib-small is owned by cracklib 2.9.4-1

That doesn't look like it has anything to do with dictd.

For some reason I was sure it belonged to dictd, but I don't remember why. Of course you are right.

2. I don't see any dir scanning in the code.

That code was in the initrc file and has been removed.

Thank you for the explanation.
I will probably actually improve the installer as severach suggested, since dictdconfig seems to be debian-specific and only available as part of dictd*.deb.
Would I then have to look for any user modification when adding / removing the configuration for a specific database in dictd.conf and use a .pacnew file?
I'm not sure, because the file does not belong to my package, as it is usually the case when a .pacnew is written.
Furthermore, a .pacsave would be stored upon removal of the dictd package, even though the user has never touched the file, which I can probably not prevent from happening.

3. This isn't a development package so there isn't any use for anything left in src. There's no practical difference between cp and mv. You can't link to anything in src. It should be deleted when you're done.

By linking I meant hard-linking. Doesn't mv create a hard link as well?
Anyways, I agree that mv should be fine.

Talking of optional dependencies, another question arises:
All the old dict database packages I know, as well as mine, depend on dictd.
However, since dictd is only one of several servers for dict databases, I suppose it's better to have it only as optional dependency only, right?
Of course this would require checking for its existence in the to be written install script.

EDIT: semantical correction

UPDATE:
Forget about the .pacnew, that was nonsense.
The .pacsave does probably actually make sense, specially since I will set dictd only as an optional dependency.

I have now packaged the FOLDOC database and improved it (the PKGBUILD and the .install file) in comparison to the freedict packages.

The installer does now:
- add the necessary configuration on first install if there is no such present for the respective database,
- restart dictd if it is running, both after first install and each upgrade,
- remove the respective configuration block on package removal if it did not change.
- inform the user that he should use a dict-server if dictd is not installed

The freedict packages are to be updated accordingly soon.

Thanks again for your help!

Last edited by respiranto (2015-08-09 18:02:24)

severach

Member

Registered: 2015-05-23

Posts: 192

Re: dictd database - PKGBUILD

In theory mv does create a hard link. It creates a hard link in a new location and deletes the old hard link, and where atomic is possible, does so in such a way that it is not possible to observe both links.

From your point of view, a moved file disappears from one place and reappears in another.

It's usually not necessary to add optional dependencies for other dictd servers. Where dictd is the original, any package that provides the same functionality will specify in PKGBUILD

provides=("dictd")

and Pacman will offer the original and any of these alternates it can find in the repository.

respiranto

Member

Registered: 2015-05-15

Posts: 479

Website

Re: dictd database - PKGBUILD

It's usually not necessary to add optional dependencies for other dictd servers. Where dictd is the original, any package that provides the same functionality will specify in PKGBUILD

provides=("dictd")

and Pacman will offer the original and any of these alternates it can find in the repository.

Counter-example:
goldendict-git, which is able to use dictd databases, however only 'provides' goldendict.

It does also not really make sense for goldendict to 'provide' dictd, since, as far as I know / understood, it does not feature what dictd is: a dict server, which is by the way also, what I would consider a useful value of provides - dict-server.

And furthermore, as I think, such a database cannot really depend on anything, since the database does not actively do anything, which might require a dependency.
Rather should dictd in my opinion depend on something like dict-database, since it does actually not work (service fails to start) without one installed.
dict-database would then have to be 'provided' by any dict database.

Correlating with this, I wonder, why most dict database packages are called dictd-foo instead of dict-foo, e.g. dictd-foldoc, which I did upload myself, keeping the old name.

I got another question, which is not that much related, however it is only a small issue and thus I didn't want to open a new thread:
(If a moderator disagrees, please let me know.)
I have updated a package (dict-freedict-deu-fra) twice, but forgot the first time to update the pkgrel, which is now for both the initial commit and the first update '1', while it is '2' for the last commit.
The first and the second commit, which have the same pkgrel, do only differ by one line, a comment.

Should I try to change this, or doesn't it matter anymore?

EDIT: missing bracket; grammar

Last edited by respiranto (2015-08-23 21:56:07)