[Registry] Implementation Questions

[Markus Raab]

Hello,

Please keep Elektra specific questions on the mailing list so that others can
participate. I will forward the mail there.

I have been doing all the work for this week but have a few quick
questions.

Well done!

For testing lintain errors can I just make the package by using the make
package command from the build directory? Or should I use
dpkg-buildpackage? Can you briefly explain what make package does that is
different from buildpackage?

make package or cpack just builds an archive in .deb format, it is only a
rudimentary debian package (no dependencies, only a single package,..)

The real packaging is in the branch "debian" that works with "git-
buildpackage".

It builds multiple packages with proper dependencies and so on. Lintian,
piuparts and other quality tools are only useful on this packages.

We talked about updating the kdb man page. Currently there is one that
descibes the kdb class and its functions. Would you like me to instead make
it the kdb tool and the commands it takes. (import, mount, merge, rm,
ls.... etc)?

No, I mean the man page debian/kdb.1 (only in debian branch of course). The
development manpages are in elektra3.

The other main question I had was about the merge implementation. Right now
the merge command takes in 4 KeySets as arguments. KeySetMerge(const
KeySet& base, const KeySet& ours, const KeySet& theirs, KeySet& merged).
Additionally it returns KeySet* merged.
The problem with this is a user has to create a merged keyset and append a
key to it before passing it into the function so the function can look at
this root key to determine where to store the merged keys. I was thinking
instead to change the 4th argument as a string of the root for the new
merged keyset. This was a user wouldn't have to initialize a keyset for the
merged keys.
Would it be okay for me to change that last argument?

Yes, for this kind of problem a Key "parentKey" is used. This approach has the
advantage (next to passing the information of a common key in) that error
information can be passed out. It can also be used to pass merge modes - also
using meta data.

Also a little issue I am having is when the KeySet is returned (by pointer)
a user can't assign that value to a keyset. What I mean is that if a user
had a line of code such as "KeySet merged = Merge::KeySetMerge(ks1, ks2,
ks3, user/sw/myapp/merged)" it would fail. However "merged =
*(Merge::KeySetMerge(ks1, ks2, ks3, user/sw/myapp/merged))" would work
fine. Other function such as Key.dup() return a pointer but work in code
such as (Key duplicate = k1.dup()). Is there something I am missing here? I
could return the keyset by reference or value which wouldn't have the same
problem but I would not be able to return an int (like -1) when the merge
runs into a conflict. What do you think is the best thing to do here?

I think these are some basic errors you are running into. You cannot return a
reference or pointer to a local declared object. Just return it by value. When
no valid keyset could be built because of errors, return a null-keyset
(Keyset(0)), similar to lookup which returns a null key. The operator!,
however, is currently not implemented in the keyset, but would be very easy to
do so.

So the usage would be:

Key parentKey("user/sw/common/mergepoint",
KEY_VALUE, "merge_strategy", KEY_END)
KeySet merged = kdb::tools::merge(ks1, ks2, ks3, parentKey);
if (!merged) {printError(parentKey);}
else{/*successfully merged*/}

the API would be
KeySet merge(KeySet const & ks1, KeySet const & ks2, KeySet const & ks3, Key
parentKey); //ks1..ks3 should have proper names

parentKey with empty name would be merging everything.

Another question I have is is there any way to get the path for a whole
user/sw/myapp/config/old/opt1/key1
user/sw/myapp/config/old/opt1/key2
user/sw/myapp/config/old/opt2/key3
user/sw/myapp/config/old/opt2/key4
user/sw/myapp/config/user/opt1/key1
user/sw/myapp/config/user/opt1/key2
user/sw/myapp/config/user/opt2/key3
user/sw/myapp/config/user/opt2/key4
user/sw/myapp/config/new/opt1/key1
user/sw/myapp/config/new/opt1/key2
user/sw/myapp/config/new/opt2/key3
user/sw/myapp/config/new/opt2/key4

This is implemented in ksGetCommonParentName
(not in kdb.h, however)
But you do not need it, if the parent name is passed to you anyway?

into a merged keyset such as user/sw/myapp/config/merged.
If i do I would get
user/sw/myapp/config/merged/key1
user/sw/myapp/config/merged/key2
user/sw/myapp/config/merged/key3
user/sw/myapp/config/merged/key4
because I use the first key in each keyset to determine the path of the
keyset. In this example the path of base(old) would
user/sw/myapp/config/old/opt1 whereas the path for merged would be
user/sw/myapp/config/merged so all the keys would be appened to merged by
appending the baseName of the key to merge_path to get the final name of
the key.
I don't know a way around this limitation without a method of getting the
root path of the keyset or by taking in the path of each keyset as an
additional argument (which is how the current kdb mv implementation works).
Please let me know your thoughts, I can make the changes pretty quickly
once I know.

Not sure if I understand you fully, we are talking about the kdb-tool
interface?

The easiest interface is just alike "kdb mv"
kdb merge user/my_path user/other_path user/common_path
that just calls kdbGet() on all pathes, then calls the C++ API above and
finally (if it worked) either output the keyset or kdbSet() to user/my_path.

Also I have a test called mergetest.cpp that currently resides in the
src/libtools/examples because when I place it in src/libtools/testing it
doesn't get built. I assume its an issue with cmake but can't figure it
out. Can you look into that?

Yes, I fixed it. Also make sure that your test is called testcpp_*.

Other then that I was able to build elektra with the augeas plugin without
an issue.

Good to hear! Please also add a debian package for it. (In branch debian)

Additionally I made a proof of concept on tab completion with kdb
and have a good understanding of what would need to be done to further
implement that feature. I have been looking into packages and how they
handle upgrades with conffiles. Currently dpkg calculates a checksum to see
if the conffile has changed during an upgrade and if it has prompts the
user what to do. I don't know if its possible to override that step during
a package upgrade.

Thats the idea to do exactly that.

We may need to modify the debian package to not define
the file as a conffile in order to attempt a merge

No, that would be an ugly workaround.

but I am exploring this issue further.

Yes, dig deeper to find out :-)

best regards,
Markus