Re: beid

Sometimes help is just around the corner, and all you have to do is ask.

Not so long ago, I asked for help on the support software for the Belgian electronic ID card. I'd been packaging that since it came out back in 2004, but recently I've had some issues with getting the most recent version of this software to work properly. Since Debian 6.0 "squeeze" is fairly near, and since I don't want a horribly outdated version of beid to be part of that release, I realized that something needed to happen, and rather soon.

My request got quite some response; much more than I'd expected. There have been answers from people with various amounts of experience in Debian packaging; one of the people to reply to my request was Laurent Bigonville, who's also a Debian Developer. So we've now set up a mailinglist, a git repository, and work seems to be proceeding nicely.

I've also asked for the removal of the old belpic source package. However, due to a mistake on my end, the beid source package rather than the belpic one was removed, which means that it'll have to be re-added to the archive now. That should happen sometime during the next few days, after the worst problems have been fixed. However, since I now asked for belpic to be removed, too, this means that for the time being, there is no eID software in unstable. We'll fix that in due time; stay tuned.

On LDAP objectClasses

Petter suggests to make the dhcpHost LDAP objectClass an auxiliary one, to make it possible to combine it with the dNSDomain objectClass in one and the same object.

Unfortunately, you can't do that. Well—not if you want Debian-edu to remain compatible with everything else under the sun. You see, one of the features of LDAP is that each and every objectClass is well-defined, and that you cannot change it. As such, once a tool knows about an objectClass, it can make assumptions about objects in that class, for any such object, in any LDAP-server anywhere. Change an objectClass, and some tools will break.

The proper fix is, first, to verify that you are using the proper objectClasses. To me, an objectClass called dhcpHost and one called dNSDomain don't sound like they were meant to be used together; I would suspect that there is another DNS-related objectClass that is meant for hosts rather than domains. If that isn't the case, then one can create a new objectclass—say, auxiliaryDhcpHost or some such—that is the same as dhcpHost in all but name, OID, and the fact that you make it an auxiliary rather than a structural objectClass. Because luckily, what's true for an objectClass is also true for an attributeType: if it is assigned to an LDAP object, tools may assume that their meaning is what they think it is...