-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
I will here answer to the mail of the FTP team directly, because they should have direct answers to technical questions arising of the upload of the CipUX packages. cipux-common cipux-cibot cipux-rpc cipux-cat-web cipux-samba The aim of deciding about a REJECTION or not should be based on technical aspects of the software. So we should make sure, that we check the software carefully before accepting it. Since the plan for CipUX is to enter other repositories in the future it is good thing that we make this software good in concept. Steffen Joeris wrote: > The cipux packages were uploaded to the NEW queue[0] 3 days ago. > After the ftp-team examined the package, we decided to move the discussion > about its inclusion or rejection to the public developer list. The public developer list of CipUX is [EMAIL PROTECTED] So every technical discussion about CipUX should made there. Not all of cipux-devel folks are on this list. So every technical discussion about CipUX should find it's place there. If there are clear technical reasons, the FTP team can reject without discussion. So I guess there are no clear technical problems. If there are some, we should fix them first. The goal [A] of CipUX is the upload to debian-edu, as preconfigured software which will be installed on the first CD. That this is easily possible shows the French add on CD. When I answer this mail I do not refer to installation of CipUX by individuals [B] since the goal is that they do not have to do that (for debian-edu). Even if [A] is the long term goal, the goal for this discussion is to make CipUX a Debian-Edu package. Who will use it and when is a completely different matter. The FTP team should then tell us (the CipUX team) what we should improve to make CipUX a Debian-Edu package. I don't think this need a discussion. I believe that it make sense to have packages in Debian-Edu, even if they are used only by the French and German schools. There also arise the question for future projects and companies: is it possible to have packages in Debian-Edu which enhance Debian-Edu, but are not used by all people? > The current point which needs to be discussed is the use of the > cipux-rpc.postinst script. This script calls various cipux commands (or a > cipux command which calls another cipux command ...) which in the end fills > in LDAP data. Note that I did not completely examine the script, so somebody > else might want to give an explanation here. Yes the cipux-rpc fills a subtree of the CipUX subtree with data. And it do it by installation. This is the configuration data for cipux-rpc server. You can install several RPC servers (if you like), so the configuration data for them (for one school) should be centralized available. For now the cipux-rpc.postinst do the job. But maybe there are better solutions, since CipUX is used also on other Distributions, this should maybe not handled by a Debian mechanism. > My personal understanding is, to > put it into a nutshell, that cipux needs to fill in the LDAP data with own > attributes in order to function. Yes WLUS and LWAT too. As finnarne agreed, most lwat functions are not useful if you have a plain LDAP tree from plain Debian. The filling of the LDAP tree is the obligation of Debian-Edu. So if Debian-Edu fills the tree cipux-rpc do not have to. > I would consider this as a violation of the > debian policy, because it adds (without noticing) ldap data which no admin > would expect while installing it and it gets not removed during a purge. If you consider the slapd from plain debian as Debian policy conform installation with its basic tree layout. Then you must see that Debian-Edu is a policy violation by it self, since it adds several objects and 2 schemata for lwat or itself to work. The discussion shows that adding files to a file system and adding entries to a LDAP database is no violation. The LDAP database is under /var/lib/ldap and not under /etc. So it is not a policy violation. Or tell the paragraph of the Debian Policy. You said the that "adds ldap [...] data which no admin would expect while installing" is a problem. If you install Debian-Edu (goal [A]) then you will expect that the LDAP will be filled. If you install CipUX by yourself (goal [B]) you also would expect that CipUX add data to the LDAP. The "without noticing" is the character of Debian-Edu, since we want to provide an easy to install LDAP-Edu server. Only the point "it gets not removed during a purge" seem to be a part where we can discuss. If the majority agrees we can arrange the purge of the data. That is no problem. But some admins might look very sad, when we do that. We also could remove every object CipUX creates. But do a lwat purge delete all lwat created objects? Do we want that? Maybe not. I think, Steffen if you consider this as a violation, you are wrong. I would like to hear the other opinions of the FTP team here. Conclusion: Debian-Edu is _not_ policy conform. cipux-rpc is policy conform. debian-edu will install cipux-rpc and not the admin, so there is no problem. If someone would like to have a purge of what ever we can arrange that. > The question here would be, if this is really a violation, if so how can it > be > avoided or in a drastical case, do we want to ignore it and consider it a > special case, which is possible through our policy[1], but strongly not > recommended and should only be a temporary solution. It is clearly not a violation! But we should provide a good installation procedure. I also deeply suggest from the bottom of my heart, we should not make a temporary solution. > My question now is concerning debian-edu, is it really necessary to change > the > LDAP data and if so why? The following questions (backwards compatibility, migration, update path, ...) are not package related questions. They are important for Debian-Edu. And should be addressed on this list, when we discuss if CipUX should be the default tool, or lwat or both. So I will skip the answer to this questions for the moment. Greetings Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFCQfrKb2iXSP9HYRAuHvAJ913vvcZ2GUIevuA1/hFa9KofoyKACfUhm/ XtfIT8gprqJn6Q91I3uUT7k= =tjC/ -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
