...snip... > > i wasn't saying that debian-edu-* > > packages weren't, in some way breaking policy, i was saying that your > > suggested (and snipped) third approach did not account for the above > > highlighted policy-compliant approach to use debconf values. > > The policy violation in bug#311188 is two-fold: The package messes with > conffiles, and it messes with conffiles (and other configfiles) that > does not belong to the package itself. and i explicitly said i wasn't talking about weather the debian-edu packages were in violation or not... > Debian Policy 10.7.3 is about the use of conffiles or not. 10.7.4 is > about config files (conffile or not) not part of your own package. > > It is policy-compliant to use debconf with configfiles of your own > package if you make sure not to mark those configfiles as "conffiles" > (because then debconf automation and dpkg automation collide). > > It is *not* policy-compliant to mess with configfiles of *other* > packages, wether or not those configfiles are conffiles or not. i'll try and re-word it. quoting from jonas (http://lists.debian.org/debian-edu/2005/06/msg00275.html): """The separation of "local admin", "packaging scripts" and "packaging scripts that see themselves as implicitly initiated by the local admin even if in fact it is done by the packaging scripts through debconf" is new. Current Debian does *not* handle that separation and considers it a violation of Debian Policy section 10.7.4.""" the way you worded it, it basically sounds like any use of debconf pre-seeding a policy violation... but i don't think that is true. as i read it (i'm no lawyer or policy wonk), it is within debian policy, section 10.7.4 to use debconf pre-seeding to pre-configure packages. it is the responsibility of the package being pre-configuerd to only use debconf values to edit non-conffile configuration files. in this case, the maintainer scripts could be seen functioning as the "provided program" mentioned in paragraph 4 of section 10.7.4. that doesn't cover use of cfengine to edit other package's configuration files (such as debian-edu-config), the not-so-clear case of using base-config (again, debian-edu-config), or packages that edit their own conffiles (such as lessdisks). but i still wanted to point out that is was possible to use debconf pre-seeding in a policy compliant manner. > >>>i don't see the point of dragging this out without proposals about how > >>>to fix it, as the workarounds are at least a temporary necessity. > >> > >>I am not sure what is your point here. > > > > > > you seem to be saying "this is broken, we need it fixed." > > > > and others seem to say "yes, we know, but we have other priorities right > > now." > > Maybe I'm just blind, but I never realized the "yes, we know, but" part. here's one: http://lists.debian.org/debian-edu/2005/05/msg00304.html i know there have been others, but don't want to spend all day looking for them. people really do acknowledge, on some level, that this is an issue. > > without *providing* and alternative, re-stating the issue will not solve > > it. > If we all agree to what is the problem, you are right: there is no need > to re-state it. simply restating a problem will not convince anyone, either. > Here's the shortest-term alternative: Do *not* consider packages adopted > by Debian until they are policy-compliant. all laws, rules, policies, etc. are merely guidlines to avoid major conflicts. any system completely inflexible with regard to it's guiding princepals is too rigid to be useful in the real world. while i don't personally see what advantage there is to have the debian-edu-config package in sarge when debian-edu uses a newer version anyways (and i've probably missed past discussions of the matter), i don't see what major harm can come from it's inclusion. time will tell if this exception was a bad idea or not. > Again, maybe I'm just blind, and noone considers debian-edu-config truly > adopted by Debian... > [snip] > > > i await your fine code to do all this :P > > Thanks, I appreciate that (as I choose to see it as you at least > acknowledge the need for it). i don't know anyone involved in CDDs who doesn't wish we had better tools to deal with these situations... live well, vagrant
Attachment:
signature.asc
Description: Digital signature