The (only?) purpose of debian-edu-config is to "tweak" the default
install of other Debian packages. Extensions are added to the
base-config package that messes with a bunch of conffiles based on
debconf values.

It is a violation of Debian Policy to mess with conffiles of other
packages, and http://release.debian.org/sarge_rc_policy.txt section 3
adds this:

I interpret the above as a clarification that Debian Policy 10.7.4
relates also to code inactive by default (like debconf preseeding).


Thus I consider the current behaviour of debian-edu-config an RC bug!


 - Jonas


P.S.

Thanks to Peter Palfrader for clarifying in bug#309871.

[Jonas Smedegaard]

Debian policy section 10.7.4 (Sharing configuration files) reads:

  The maintainer scripts must not alter a conffile of any package,
  including the one the scripts belong to.

The base-config scripts are not maintainer scripts, so the behaviour
of debian-edu-config do not break the written policy.  So the sarge RC
policy "clarification" is clearly a more extended rule than the one in
the current policy.

The new "clarification" seem to forbid all scripts that can edit
conffiles.  Is this the correct interpretation?

(And yes, I believe we need to find a better way to handle
configuration in debian-edu, but while we wait, I see no better way to
do it than the current mechanism.  And I believe it is not breaking
policy as it is written in the Debian Policy Manual today.

It would be interesting to know which packages conffiles we affect, to
have a work list of packages we need to make more configurable.

It's my understanding that policy's prohibition on editing conffiles from
maintainer scripts is intended to extend to any programs that are called
from maintainer scripts, and the sarge RC policy clarifies this: you are not
allowed to cause any package's conffiles to be edited in the process of
installing or removing a package.

The sarge RC policy says that the only correct way to modify a conffile is
"the user running an editor specifically".  This doesn't say that it must be
a *text* editor; other specialized editors also exist, and I don't have a
problem with such tools as long as they're not called on the user's behalf
by the package.  OTOH, base-config isn't as clear-cut because nothing is
done in the maintainer scripts, but base-config itself is invoked for the
user at install time.

I realize that debian-edu-config is something of a special case, because of
its narrow application.  I don't think that Debian-Edu should get a free
pass for violating policy, but I also don't think that there's much risk of
this issue affecting people who aren't installing debian-edu explicitly, so
it doesn't seem to make much difference to their net experience whether
deiban-edu-config is allowed in sarge or not.  So unless someone else on the
release team objects, I think I'm going to tag this bug sarge-ignore.

extended rules, but clarifications of chosen interpretation at places
that can be (and is, like in this case) interpreted in several different
ways.

Section 3 of sarge RC policy shows that "maintainer scripts" are
interpreted as "everything invoked directly _and_ _indirectly_ by
package maintainance scripts".

You are correct in saying that Debian Policy can also be interpreted as
talking only about direct alteration.

It sure breaks packages' maintainance that their conffiles are altered
by other packages (which I believe is the intend of D-P 10.7.4): It is
expected to be able to remove functionality of a package by removing a
package - that is not the case with debian-edu-config.

The following was extractedx manually from looking at "links" and
"editfiles" entries of cf/*.cf in the source of debian-edu-config:

amanda
apache
apt
bind8
bind9
cupsys
devfsd
dhcpserver
exim(4?)
nfs-common
autofs
courier-ldap
courier-authdaemon
inetutils-inetd
kdm
xfree86-common
cron
kdebase-bin
login
libpam-runtime
samba
ssh
su
base-files
libnss-ldap
libpam-ldap
slapd
dhcp3-server
procps
xfs
mime-support
munin-node
nagios
shorewall
slbackup
squid
sysklogd
webmin



Some of the editing seems to be replacing files with symlinks to other
files. I believe that is problematic even if allowed by policy, due to
bugs in dpkg (but no, I can't proove it).


Also, config files seemingly not owned by a specific package (like
/etc/hosts.allow ) is edited as well. Don't know if that is fine to mess
with programmatically.

So for the upgrade path from sarge to etch you want maybe 30+ quite
popular packages to weed out bugreports caused by chain-reactions of
installing this package?

I agree that debian-edu is a special case, but don't see your point in
that being a good excuse for ignoring policy: Debian-edu-* packages are
expected only to be useful in the Skolelinux Debian-derived
distribution. It is a goal of debian-edu to be able to create Skolelinux
solely from officially released Debian packages but that goal is not yet
reached so a few more packages having to be added unofficially shouldn't
be a big deal.

What is on the other hand problematic IMHO is that their goal of getting
adopted into Debian will be distorted if their packages violates policy:
They can truthfully argue that "it is good enough for Debian" while in
fact it isn't.


I recommend sarge RC policy is respected also for packages not expected
to be used in a broader audience.


 - Jonas

[Jonas Smedegaard]

Installing this package isn't enough to activate it.  You have to run
the base-config fragments as well.

Do you have any proposals for fixing this issue?

So do you also mean that it breaks packages' maintainance that their
conffiles are altered by the sysadmins too? Package maintainer script
shall perfectly handle that conffiles are changed by the sysadmin.

An extreme solution to this bug could have been to rewrite
debian-edu-config as a HUGE installation-manual, and tell the
sysadmins (I expect that there wouldn't be many left) to manually do
all the configuring. In the same way as it is now after a Debian-edu
installation, the maintainer scripts of the packages that will have a
altered configuration shall handle this during upgrade.

I'm not sure I see the difference. If I know the debian-edu-config
package right, one will have to run a script to change any conffiles
after manually installing the pacakge?


- Werner

Could someone comment on this?  Its not clear to me what the policy is
on thos configuration files which are not conffiles.  It seems that
there is meant to be an established mechanism for editting such files,
(/usr/bin/update-foo) and therefore that an update such as:

	echo ALL: foo.bar.com >>/etc/hosts.allow

would be disallowed by policy, but a (hypothetical) update such as:

	/usr/bin/update-hosts.allow ALLOW ALL FROM foo.bar.com

would be acceptible (if allowing such connections was justified).

Justin

Could we not come to a working compromise for sarge no the basis that a
propper solution is found for etch... something along the lines of this.

debian-edu-config could use debconf to ask the admin somthing like:
 "Do you wish to apply the debian-edu configuation?
  Doing so will alter the configuration of several independent packages
  installed on your system"

This could be preseeded by debian-edu fokes (right?) but give sutable
warning to others!

This is going to be a common problem for all CDD's (custom debian
distroes). Perhaps each cdd is allowed one package like this... each of
the spercial packages would have to conflict with eacho other (or
something) so only one can be installed.


Hmm... this may not be all that usefull but it might start someone else of
on the road to a better solution.

Alex Owen

Well, this list is overbroad, at least; samba doesn't provide any conffiles.
(samba-common provides /etc/samba/gdbcommands as a conffile, but I doubt
that's the one that's being replaced here.)

How does including the package in sarge make any difference to the number of
bugs (mis-)reported against these other packages?  The Skolelinux users are
still going to be installing it and modifying these conffiles; people who
are not Skolelinux users are still not going to.

What other packages does Skolelinux depend on for sarge that are not in
Debian?

Steve Langasek wrote:

ltsp
j2re1.4

Alex Owen wrote:

Installing Debian-edu-config will not lead to a lot of configuration
beeing modified. If so, there is a bug.

Running base-config, will lead to some modification (maybe most, I dont
remember). running cfengine-debian-edu will also lead to a lot of files
beeing changed.

I think Jonas also cares about upgrading, and upgrading an old
installation and then running base-config could lead to unforeen results.

Until every package is preconfigurable, I think this is something we
need, yes.

So, precisely one package not in Debian that is actually eligible for
inclusion in Debian. :)

Thanks,

complete list - judging from his own words recently on the issue of what
is actually based on Debian Sarge in the current snapshots aiming at
becoming next official Skolelinux release:
http://lists.debian.org/debian-edu/2005/05/msg00205.html

I suspect the count to be higher than the above two plus the one
specifically discussed in the referenced debian-edu thread.


Sure, most of the unofficial packages for Skolelinux is improvements
expected to get included in a later Debian release, but just as Ubuntu
isn't "official Debian" so is also not Skolelinux currently.

So I dare repeat myself: Adding a few more packages unofficially (that
breaks policy) shouldn't be a big deal for Skolelinux.


 - Jonas

Jonas Smedegaard wrote:

Those are the only two that are not in Debian now.

Ah your talking about the packages that actually are in Debian sarge,
but in a state were we cant use them, like the lessdisks-packages and
the likes. Yes, Some package maintainers are just to lazy to get their
work done.
http://ftp.skolelinux.no/skolelinux sarge local

From this, the folowing packages are included:
 Newer autopartkit than the one in rc3 (dont remember why)
  autopartkit_1.08_i386.udeb
 Newer debian-edu-install than the one in sarge, we have to have
 progress
  debian-edu-install_0.646+svn3411_all.deb
  debian-edu-profile-udeb_0.646+svn3411_all.udeb
  debian-edu-install-udeb_0.646+svn3411_all.udeb
 Newer debian-edu-config, for the same reason as d-e-install
  debian-edu-config_0.397+svn3410_all.deb
 Newer debian-edu, same reason as above
  education-laptop_0.803+svn3327_i386.deb
  education-desktop-kde_0.803+svn3327_i386.deb
  education-standalone_0.803+svn3327_i386.deb
  education-workstation_0.803+svn3327_i386.deb
  education-thin-client-server_0.803+svn3327_i386.deb
  education-common_0.803+svn3327_i386.deb
  education-networked_0.803+svn3327_i386.deb
  education-tasks_0.803+svn3327_i386.deb
  education-main-server_0.803+svn3327_i386.deb
 We need a working java runtime on the installation, and are allowed to
 include this version on the cd by Sun
  j2re1.4_1.4.2_05-0.skolelinux.2_i386.deb
 Some lessdisks-packages. We need to have this preseedable, which was
 made possible in 0.6.1 (I think). Sarge have 0.5.3?
  initrd-netboot-tools_0.6.2c_all.deb
  kernel-image-netbootable_0.6.2c_all.deb
  lessdisks-terminal_0.6.2c_all.deb
  lessdisks-common_0.6.2c_all.deb
  lessdisks-easydialog_0.6.2c_all.deb
  lessdisks_0.6.2c_all.deb
 LTSP is not included in debian, I guess the future will tell if they
 ever will be included
  ltsp-x-xserver-svga-3.3.6-i386_4.1-0_all.deb
  ltsp-x-xserver-s3-s3v-3.3.6-i386_4.1-0_all.deb
  ltsp-x-xserver-mach64-3.3.6-i386_4.1-0_all.deb
  ltsp-core-i386_4.1-1_all.deb
  ltsp-kernel-2.4.26-edu-i386_4.1-2_all.deb
  ltsp-localdev-i386_4.1-0_all.deb
  ltsp-modules-2.4.26-i386_4.1-2_all.deb
  ltsp-sound-i386_4.1-0_all.deb
  ltsp-x-core-i386_4.1-0_all.deb
  ltsp-x-xserver-mach32-3.3.6-i386_4.1-0_all.deb

The rest of the packages is fetched from debian local mirror on developer.

Yes - there is one source package whos binaries are included on the CD.
I guess we cant do anything with the current maintainer of those
packages, as he is clearly occupied with other things than keeping up
with upstream.

???

The remaining packages are all "officially released Debian packages"?
Not true.
released by Debian.

Also, it concerns me if Skolelinux takes packages "officially released
by Debian" but as single packages only and from a "testing" og
"unstable" package pool, hinting that the package has not yet been
tested well together with the other packages forming a "distribution".


In the case of the "lazily maintained" lessdisks you include a package
that is not packaged for Debian at all.

In the case of lessdisks I may not ever package 0.6.2c officially for
Debian, because of trouble upgrading between 0.n versions. So you may
end up with a Skolelinux/sarge that cannot seamlessly be upgraded to
Skolelinux/etch - but who cares...

There's more to packaging than a working _install_ process, Finn-Arne.


For the record: I am not pissed at my package getting "overruled" (but
yes, it _does_ piss me off being called lazy, so keep doing that if you
want to annoy me, Finn-Arne). I am concerned about the possible
consequenses of Skolelinux being promoted as "all Debian" when it is not
the case. And I believe it hurts Skolelinux developers that their
violating Debian Policy is treated lightly: They then believe the
problem is not serious.


Skolelinux developers believe their distro can be used as an "easier
install process" also for standard Debian. But use Skolelinux as Debian
installer, remove the debian-edu-* packages, and off you go (with
possible ticking bombs we then need to weed out whenever the bugreport
show up for all those packages being messed with in a policy-violating way).

Why it is bombs? Because the local admin "didn't do it" The "Debian
system" (actually: the Skolelinux hacked derivation of a Debian system,
but that's not how it is promoted) messed around with itself, and then
didn't preserve integrity later on (like if Skolelinux changed symlinks
and the package then later overwrites skolelinux derived files instead
of its own files).

Thank you - this is exactly what I asked for in the debian-edu thread
referred to above.

 - Jonas

Not a fix for sarge.

But I look forward to participating in the discussion on this issue at
next debconf. I believe it is possible to solve both inside Debian and
(until all developers involved in the changes needed are convinced that
they should take on that additional maintainance) unofficially for CDDs
as well.


 - Jonas

Agree. The problem is not with giving a big enough warning. The problem
is that the basic logic of Debian is that each single package has
authority for automated handling of its conffiles - no other package is
allowed to overrule that.

Child abuse is illegal in most societies, even if you ask first!


So I don't see a good solution for sarge (to mark this as sarge-ignore
is a bad solution IMHO).

The good solution I believe is to define more "distribution choices" (as
implemented in base-config) into Debian, and convince relevant packages
to extend relevant "package choices" with a "use distro default".

Until package maintainers adopt such approach, CDDs cannot _within_
Debian provide different defaults, but must do so by adding/replacing
packages _outside_ of Debian.

I believe then "a lot of files" is what gets modified also when running
base-config: base-config seems to hook into debian-edu simply by
executing cfengine-debian-edu.

Correct. Thanks for clarifying, Finn-Arne.
debian-custom reveiled to me that those CDDs using cddtk has a saner
approach (behaviour changes is tied to a metapackage and disappears
again when the package is removed), alot different from the Skolelinux
approach (behaviour changes is tied to the distro and applied at install
time) which breaks policy.


A Debian package has stricter rules than the local admin. This is needed
in order for the local admin to be able to trust the system to not "take
over" or do other surprises. and it is needed for packages not to "be at
war" with each other: No package is allowed to overrule another package!

Debconf preseeding in itself is allowed only by local admins, not
(official Debian) distros. That's the point of this bugreport.

But they are a step in the right direction. :-)


 - Jonas

Could someone comment on this?  Its not clear to me what the policy is
on thos configuration files which are not conffiles.  It seems that
there is meant to be an established mechanism for editting such files,
(/usr/bin/update-foo) and therefore that an update such as:

	echo ALL: foo.bar.com >>/etc/hosts.allow

would be disallowed by policy, but a (hypothetical) update such as:

	/usr/bin/update-hosts.allow ALLOW ALL FROM foo.bar.com

would be acceptible (if allowing such connections was justified).

Justin

I agree with your conclusion. Debian Policy section 10.7.4 is about
"Sharing configuration files", and even though the first two paragraphs
discuss conffiles the remaining text (including the manipulation helper
tool you describe) is about configuration files in general.


 - Jonas

On Mon, May 30, 2005 at 01:33:13PM +0200, Morten Werner Olsen wrote
much more then:


I like the "huge installation manual idea".

It allows to fully comply Debian policy.


The next step will be automating the installation.




Thank you for reading this message that looks foolish.
Geert Stappers

Debian currently do not allow automation, because no package is allowed
to "overrule" other packages, or to take the role of a local admin.

I want automation. Automation is possible *now* by adding unofficial
hacks to Debian.

Oh, and automation is also possible officially in Debian, thanks to this
bug being tagged as sarge-ignore :-I


 - Jonas

Hi

I managed to build a list of configuration files in /etc that are
changed/replaced by debian-edu-config. Though not all of them are
conffiles... Note that some of them were conffiles in recent versions
(xfs in testing for instance). A list of the conffiles is also included.

This should at least give us a starting list of things to work on...

Cheers

Luk

PS: Note that I didn't check for packages in contrib or non-free...

Jun 05 10:22:32 <luk>   I do think that 311188 gets too little attention
as I'm sure other projects would be (are) interested in how to solve it,
maybe I (or someone else) should start a discussion on debian-devel
about it?
Jun 05 10:23:34 <h01ger>        luk, sounds reasonable. we'll discuss it
in extremadura as well. (sorry, no video streaming :)
Jun 05 10:24:46 <luk>   when is that meeting, next weekend?
Jun 05 10:24:58 <xorAxAx>       luk: begins on wednesday
Jun 05 10:27:50 <luk>   ok, note that some ideas about fixing the
wishlist bugs are introducing debconf questions or configuration
changing programs, creating the file in the maintainerscripts (so it's
no conffile anymore) or introducing a way to include extra configuration
(like udev did)
Jun 05 10:29:15 *       h01ger nods
Jun 05 10:29:18 <luk>   note also that introducing hyperlinks and just
plain changing configuration files of other packages might also be
problems though IMHO not as severe as touching conffiles
Jun 05 10:29:44 <luk>   though some people might disagree with me on the
last thing :-(
Jun 05 10:30:55 <luk>   another solution might be to only ship the
(empty) configuration file in usr/share/doc/<package>/examples so it's
no conffile...
Jun 05 10:32:05 <luk>   this sounds rather absurd, though there are some
of these between the bugs I filed (conffiles with only comments)

Cheers

Luk

Hi,

hereby I propose to have a discussion about #311188 tomorrow, saturday
2006-06-10 at 18oo CEST on irc on #debian-edu on irc.oftc.net instead in RL
in Extremadura.

Please object via mail :)


regards,
	Holger

Hi,

this bug has neither seen action nor traffic in the recent past. It's RC and
marked "sarge-ignore", but etch is coming... ;-)

Is it correct, that atm we "don't care" because (for the release) we can take
debian-edu-config from our archive, not debians?! And we're not integrated
into the main d-i atm also, which _might_ be more unlikely to fix until the
release anyway. Or...?! Comments very welcome.


regards,
	Holger

[Holger Levsen]

None from my point of view, at least.  I care, and try to move as much
configuration as possible into debconf preseeding.  But I do not
consider it release critical for debian-edu.  We will release a new
version independently of the state of this bug.

As an example, yesterday, I was happy to discover that we could drop
the code to modify /bin/sh as this was preseed-able using a value in
the dash package. :)

I hope we can find more such settings, or get such settings into those
missing it at the moment, in time for etch.  But for those we are
unable to make preseedable, we will just have to find a working
solution.  My goal is to release debian-edu/etch fairly quickly after
etch releases in desember. :)

What do you mean?  Our udeb integrates very nicely into the main d-i
framework.  There are some minor bugs left, but in general, it is
doing quite well.

Friendly,

Hi,

Good to hear / have this documented here. So do need, debian-edu-config in
etch at the moment or can this package be removed (esp. from the radar of
people working on releasing etch in time..)?

Great. "But" with the package from our (=debian-edu) archive?!

I mean, that the debian d-i (in it's released state on the official etch cds
or whatever medium) provides no means to load the debian-edu-config udeb.

For etch+1 I would be very happy to see a official debian dvd with
capabilities (select install, installgui, expert, skolelinux, debian-med...)
to (also) install CDDs (and not only pure debian), which can only use
packages from main, obviously. Maybe this constraint is too much to make it
useful in etch+1, or maybe unofficial (from debians POV) DVDs are the way to
go then.


regards,
	Holger

[Holger Levsen]

Well, I would like to have all the packages we have on the CD pulled
from etch, so I want d-e-config in etch alongside with all the other
packages.

My goal is to use the debian-edu archive only for testing, and to get
all the packages we need into etch before it freezes.  I am not sure
we succeed, but will do my best to make it happen.  We need fewer and
fewer non-debian packages for each release, so I hope we can get down
to < 5 packages for etch.

Sure it does.  When creating the CD, create .disk/udeb_include on the
CD listing debian-edu-install-udeb, and the rest happen
automatically. :)

That is definitely a bit further ahead, yes.  But it would be fairly
easy to only enable the debian-edu udeb if some kernel option is
passed into d-i, and get the d-i team to include it on the DVD.  Of
course we might not be able make sure all "our" packages are on the
official DVD. :)

Friendly,

unblock 311188 by 370319

thanks

debian-edu-config doesn't use amanda anymore

Greetings
Patrick Winnertz

unblock 311188 by 370340

thanks

Remove Blocking bug #  because we doesn't try to modify /etc/issue and
use the default one.

Greetings
Patrick

Hi


I know that this is an old and long discussed bug, but please allow me to
raise the discussion again right now as I think that the issue is not
completely clear.

First of all the bug is called: "debian-edu-config: Messes "programmatically"
with conffiles of other packages"

The word programmatically also appears in the etch rc policy under point 3
(Configuration files), however I have to ask, because there is one exception.
It is allowed, if a user explecitely runs an editor.
Well if someone installs the debian-edu-config package on plain debian,
*nothing* will happen at all, except that the cfengine scripts are installed,
but cfengine is not started by the maintainer scripts.
Therefore the user has to explicetely run the cfengine command to activate the
scripts and therefore configure the system, which I would call "running an
editor scpifically" .
Of course debian-edu works out of the box and this command is started by the
debian-edu-install-udeb package (by its finish-install.d part in particular).
This IMHO means that there is no RC bug in debian-edu-config about messing up
with other packages conffiles.

What do you think?

Cheers
Steffen


[0]: http://release.debian.org/etch_rc_policy.txt

*I* do think that, if that bug is RC for debian-edu-config, then
another one should be opened for localization-config, which does
exactly the same (actually not in very good shape for etch as it
basically does nothing). BTW, localization-config is maintained as
part of debian-edu, originally. I happen to be its maintainer right
now, but essentially as an interim while Konstantinos Margaritis is
away.

Hi Steffen,

In the original bug report, Jonas said:

Is this no longer what happens?  If not, if instead debian-edu-config is
only supplying configuration for cfengine, then I agree with you that this
bug should no longer be considered RC.

Thanks,

Steffen Joeris wrote:

What happens is then a chain reaciton leading to an editor _implicitly_
messing with the cinfiguration files. This is not what policy permits,
and I find it sane for policy to not allow this.

Please try take a look at this from a non-"we want everything automated"
standpoint, and see if you don't agree with me: The issue here is
avoiding surprises for the local admin. It would be a surprise to me if
a core functionality of the Debian packaging system broke due to
enabling CFengine using purely Debian CFengine scripts.

I believe this bug should be left open until all configuration that
Debian-EDU wants different than the default is changeable in a way
supported by the packages themselves, rather than from Debian-EDU
overriding.

Until then, I believe it best for Debian-EDU to either instruct the
local admin to explicitly do the changes necessary but not allowed by
Debian policy, or to distribute Debian-EDU as a minor fork of Debian
with the policy-breaking behaviour enabled.


Regards,

 - Jonas

Christian Perrier wrote:

I am surpried that this wasn't already the case. I am quite sure
localization-config was mentioned back when we discussed this issue.


 - Jonas

I send some little pings to some of the bugs who can be easily fixed.

For the syslogd stuff I would wait if joey accepts finally the patch, if
not I would suggest we switch to syslog-ng, I spoke about ~3/4 year with
the maintainer and he agreed to include such a fix into his package.

The munin-node.conf issue could be fixed as the maintainer suggested:
[ -r /etc/default/munin-node] ...

We'll would ship this file with this content:

severity 311188 important
thanks

Hi,

at the Debian Edu developer gathering in Narvik we once again discussed
#311188 and came to the conclusion, that we would like to downgrade it to
important, as debian-edu-config only does these changes if told so by the
admin (by running the script or using the debian-edu installation cds or
preseeding a hidden debconf question).

If debian-edu-config gets installed on a normal system, nothing (bad) happens,
'apt-get install debian-edu-config' (alone) will not mess with policy.

With a severity of important the package will into testing and allow us
easiier and better testing for lenny.

We still plan to fix this bug (and deal with all the blockers) til lenny! See
http://wiki.debian.org/DebianEdu/Bug311188 for a summary of the status.

This course of action has been agreed on #debian-release too :)


regards,
	Holger

I understand that severity of bug#311188 has been lowered to non-RC by
the Debian Edu maintainers.

I also understand from the bugreport that the severity change happened
in coordination with the release team.

Could the release team please elaborate on the reasoning behind this
judgement?  And do so here at the bugreport rather than only on irc.


Kind regards,

 - Jonas

Happy for the great progress on real fix for the bug, but frustrated
that the broken behaviour is accepted into stable if that work is not
fulfilled in time for release of Lenny.

You could start by reading the bug log as the reasons are mentioned?

Cheers

Luk

I did.  Thanks for the obvious suggestion.


AFAICS the most recent post from a member in the release team was this
one by Steve Langasek, back in november:


I fail to find any response to that question.

I am fully aware that Holger, who lowered the severity, consider it safe
to do so.

My question is if the release team agrees with this judgement, and for
what reasons.

As Christian Perrier wrote, the standpoint of the release team in this
is relevant also for other cases.


Kind regards,

 - Jonas

Hi,

if you install debian-edu-config on a debian system, nothing "bad" and policy
violating happens.

If you choose to run a certain script shipped inside the debian-edu-config
package, it will modify configuration files as you expressed you wish, as you
ran that script.

If you choose to install Debian Edu using the Debian Edu media, this script
will also modify configuration files, as you expressed you wish, by
installing from that media.

So it is an explicit user choice, to modify the configuration files.

We still consider those changes an important bug, as they prevent smooth
upgrades. Thats why we plan to fix all the blocker bugs for this bug for the
Lenny release, so that fresh Lenny Edu installs can be savely upgraded to
Lenny+1.


regards,
	Holger

Thanks for your opinion on this.


When did that change?

Or was that the case throughout the lifetime of this bug?


Kind regards,

 - Jonas

Hi,

I've changed my opinion when I became aware that installing the package itself
does no harm.


regards,
	Holger

My computer is running Ubuntu 7.10, Gutsy Gibbon.  After I installed Debian
Edu, I found that 1) my boot menu states that I am using Debian, and 2) my
program Ubuntu Tweak won't work because it is being told I run Debian and
not Ubuntu.  Please help.

If you mix up different distributions you can not expect things are
working flawlessly.  The only advise we could give is to use plain Debian
if you expect Debian packages working flawlessly.  We do not feel responsible
if our packages do not work in Ubuntu as you expect them to work.

If you might send us a patch that would work on Ubuntu while not breaking
anything in Debian we might consider applying it.

Kind regards

            Andreas.

(ubuntu-devel cc-ed)

  Andreas, you are completely right.  However, this story is being told
again and again and again.  Why?  Because it violates assumptions that
many, many users make.  Especially those new to Linux.

  For a user of "Linux for human beings" (Ubuntu) the principle of least
surprise is violated when an action that is likely to break Ubuntu can
happen without a warning.  A big fat warning would suffice, if the
purpose is to wash hands, saying "we told you so!".  But washing hands,
either automatically (warning dialog) or manually (Andreas' reply here)
isn't quite what we should aim for in the long run.

  Repositories that look alike on the surface may or may not play nice
with each other.  They may be binary incompatible.  Their maintainers
may not endorse (i.e. support) other repositories that are intended to
be binary compatible, either.  Users who add third party repositories
are left to figure out this for themselves.  It's as if adding an apt
repository is an expert operation; User Beware!

  Apt is an awesome package manager framework.  It has a lot of power!
But it is a powertool with few safety features aimed at Joe Average.
I don't think we want to advertise loudly the lack of such safety
features.  But unless we do, I think it is the duty of Debian and its
derivatives to improve the safety nets.

  Before anyone suggests more onerous warning dialogs telling the users
that they are on their own (more washing of hands) I would like to
propose "upstream" as a metadata item for apt.  debian-multimedia.org
would have a debian.org apt source as it's upstream, for example.
Basically, apt sources could declare binary interoperability with
other apt sources.  Any thoughts?

[Virginia Hicks]

As Andreas said, mixed distribution solutions might give strange
results.  But to give some ideas on where the problem might originate,
I will provide some notes.  It is unclear to me what you mean by
installing Debian Edu, as it is a cluster of profiles and more
specific information is needed to know what you did.

When that is said, I suspect the file /etc/lsb-release in the
debian-edu-config package is the only file capable of changing what
other programs believe to be the distribution name.  Try to drop the
package, modify the file or move the file away to see if it solve your
problem.

Happy hacking,

Hi,

please stop this discussion about buggy ubuntu here, the bug is long enough
already and we should rather concentrate on fixing it and all its blockers,
instead of trying to fix this issue.

As I read it, the user either (re!)installed Debian over Ubuntu and now he
complains he got Debian... ;)

Or:

"<hermanr> The suggested fix from the guy at #ubuntu-devel was to rip out the
config bits from the debian-edu packages, as they were based on assumptions
about stock Debian." - which would mean, the user installed Ubuntus
debian-edu packages and they are so broken, that they turn a Ubuntu system
into something strange+broken... But this would also mean, this is offtopic
here.

And if the second possibility is true, or even if not, I wonder why there are
debian-edu* packages in Ubuntu anyway. AFAIK Edubuntu doesnt use them...
(which also explains why they are broken.)


regards,
	Holger

Because quite a few different distributions use APT and .deb repositories,
and their packages aren't necessarily interchangeable, it would be useful if
APT knew which distribution you were running and checked this against the
Release file in the repository.  This would make it possible to display a
warning or otherwise behave intelligently.

This idea has been around for a while.  There is real work associated with
doing this, however, and it hasn't yet been a big enough priority for anyone
with the necessary time and skills.

Is this a legal approach to solve the configuration problem:

http://debathena.mit.edu/config-packages/

Hi Marius,
consider a way of "messing programmatically with configfiles".

For examples of real-world problems, also demonstrating the relevancy of
this policy, see "Common Issues" section at the bottom of above
referenced page.

Petter Reinholdtsen [consider it legal] to mess programmatically with
configfiles as it is done currently, even though it breaks upgrades.


 - Jonas

[consider it legal]: Explained at 0:32:42 - 0:33:25 in this video:
http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/779_Debian-Edu_Current_Status_and_Development_Ideas_for_the_next_Decade.ogv

Hi all,

after having worked with the Debian Edu team for a couple of months
now I would like to make a proposal on how to address configuration
file manipulation within Debian blends.

For further reading on configuration file manipulation and Debian
policy violation refer to bug #311188 in BTS:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311188

To address #311188 the latest approach that has been discussed is
enrolling the maintainers of all affected packages (and that can be
many) to add blend-customized debconf values to their packages so that
a clean preseeding of the package is possible.

Only a short time ago Marius has asked for debathena as a means to
legalize what blend packages like debian-edu-config are doing to
config files of other packages.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311188#294

I agree with Jonas that debathena also fiddles with other packages'
config files and that this causes the same violation of the same
Debian policy 10.7.4 as described in #311188.

So, my opinion is that without implementing the blending mechanism
within Debian policy itself (and that is also: within dpkg itself), we
may possibly stall here for longer.

So, my proposal is:

  * let Debian blends become a real element of the Debian package system

  * that is: implement in dpkg three options:
    - Option 1: --blend=<blend-name>
    - Option 2: --unblend
    - Option 3: --init-blend (or --native2blend or similar)

  * in FHS we provide/define blend namespaces in /etc
    - e.g. /etc/blend/edu
    - or /etc/blend/gis
    - ...

  * blend packages with configuration files (like debian-edu-config) will put
    their blended config files into /etc/blend/edu/<etc-like-tree>

So on installation of a blend config package the following might
happen. I will use the example of debian-edu-config (d-e-c) from here
on...

  * every package that gets manipulated by d-e-c has to be in Pre-Depends of
    d-e-c. (I am aware of DDs not liking this and trying to avoid that
    whereever possible, maybe we find another approach here)
  * d-e-c installs its files targeted for /etc/* into /etc/blend/edu/*
  * on postinst every native Debian package that is affected by the d-e-c
    configuration override gets prepared/tagged by a
    - dpkg --blend=edu <package-name>
  * This blending process may do the following...
      **of course, the below has to become a legal part of Debian now...**
    - create copies of existing configuration file(s) <conf>.d folders in
      <package-name>

      /etc/<folder>/<cf-file> -> /etc/<folder>/<cf-file>.dpkg-native
      /etc/<folder>/<cf-folder>.d -> /etc/<folder>/<cf-folder>.d.dpkg-native

    - divert the original configuration file and <conf>.d folder names to the
      corresponding files/folders in the /etc/blend/edu namespace.
    - tag the affected package (maybe in /var/lib/dpkg/info) as blended
  * Alternatively, if the configuration files of a package shall not
be replaced
    by d-e-c then we also find a dpkg --init-blend <package-name> command call
    useful (or --native2blend or --clone-native2blend or ...).
    -> install a copy of the original package's config files from
    /etc/<config-folder> -> /etc/blend/edu/<config-folder>
    After this, configuration files provided by the package maintainer can be
    manipulated with cfengine (within /etc/blend/edu/<config-folder>,
of course.
  * On package upgrades the dpkg system has to recognize if a package is
    in blend state or not. If it is in blend state, the dpkg system has to
    install new configuration files with .dpkg-native file suffix.
  * With such a mechanism the system can also easily be unblended
(reverted to a
    vanilla/native Debian installation). -> dpkg --unblend <package-name>

Happy for feedback,
Mike

Hi Mike,

Correct.  Thanks for summarizing.

[debathena comment snipped]
consensus in Debian, so changing policy requires to first create
consensus and then - after the fact - document it in Debian Policy.

What does the above mean? Is it flags tied to a source package or to a
binary package or to a system?  If the latter then I suspect that you
may really mean APT, not DPKG.  In other words, does it imply that only
a single blend can be applied?

If really you are trying to document debathena rebranded as blends then
please say so.  If so it also seems sensible to involve the developers
of debathena - either by discussing with them first to understand why
their package(s) live only outside of Debian, not (tried to become)
official part of it, or invite them to this very discussion directly.

Above seems like the central piece of where we are stalled at the moment
regarding nedding-different-config-than-package-offers: The way forward
is not to legalize mechanisms currently violates Policy, but to work on
refining said mechanisms to a point where the Debian community is
convinced that it is sane to do, and _then_ document the fact in Policy.

I believe dpkg does not reliably support diverting conffiles.  That
particular piece can be worked on (or at least investigated and
documented more clearly) independently from this grand plan.

Above seems to me as a reinvention of dpkg-divert.  If you feel that is
a sensible way forward (I don't) then it seems to me that you need not
reach concensus for the whole grand plan in order to improve this piece:
you can discuss that with dpkg developers directly.



Regards,

 - Jonas

Hi Jonas, hi all,

Good point, thanks for giving this more light.
And every package in this model can be in non-blended mode or in blend
mode for _one_ blend.

Example: if we install d-e-c, we have to tweak apache2 configuration.
For this we would set apache2 into ,,edu'' blend mode. If apache2 is
in ,,edu'' blend mode it cannot be set into ,,gis'' blend mode etc.
You can unblend apache2 and blend it with some other blend only then.

The idea proposed here was first. Then I re-read #311188 and stumbled
over Marius's posting and took a closer look. I was astonished by some
similarities. And it was also clear that they are doing it outside of
Debian and that they do the same stuff as d-e-c. The install package-A
and then config-package-X and config-package X overrides files in
package-A.

This sounds like a senible way of progressing on this. However, what
exactly do _you_ mean by ,,refining said mechanisms'' (not sure what
the said mechanisms are and how to refine those).

^^^^^^^^^^^^
The above is what you refer to as refining, I guess? So that would be
dpkg development then.

  1) provide our (D-E) own+complete config file for some Debian package
  2) apply cfengine of D-E to some non-D-E config files in some Debian package

Both ways of tweaking config files should be managable with a proposed
model. Actually the first is pretty much alike to dpkg-divert and it
probably can be a wrapper around dpkg-divert that handles the blending
and unblending process.

The second approach is rather creating a
ready-for-blending-with-cfengine-copy of the orginal config files,
move the original's out of the way (.dpkg-native), replace the copied
files by symlinks and then tweak the copied files with cfengine (or
puppet or ...).

My basic question at this point becomes this: does such an approach
have a chance to be supported and refined by the people being
interested in blends, or do people who have to deal with blends deny
such an approach right away for reasons A-B-C-etc. It does not make
sense enrolling people outside the group with definite use case into
something that is not supported by the people with the use case
themselves.

Thanks for any input you have!
Mike

Hi,

NB! Please do not cc me - I am subscribed to both d-blends@ and the
bugreport.

More info at http://www.debian.org/MailingLists/#codeofconduct

Thanks for the clarification.
single _other_ option, those two tweaks cannot both be applied if "edu"
and "gis" both use your proposed mechanism?

Seems bad design to make blends mutually exclusive at the core of the
blend mechanism.  Sure it might be sensible for one blend to conflict
with another, but some blends might go well together, so should not
technically be hindered in doing so by the underlying mechanisms IMO.

Debian is about structuring choices implemented in upstream code, and
blending is in a sense about reducing choices to a sensible minimum.

Makes sense for me that a blend maintains _what_ should be tweaked, but
_how_ it is tweaked is better maintained by the package maintainer than
blend maintainers or dpkg maintainers IMHO.

When a blend includes full config files or scripted config tweaks then
the package _maintainers_ are kept out of the loop of _maintaining_
those config choices, and the config options are not offered
individually by Debian, e.g. for tools like piuparts to regression test
in automated ways.

I highly recommend to instead help make it easier for package
maintainers to implement and _maintain_ config handling.

I believe that if it was easier to implement and maintain debconf
interfaces to config files, we would have less of a problem convincing
them to offer config options for the tweaks we need for various blends.

Specifically I believe that work to integrate debconf with Config::Model
could help improve the situation.

More on Config::Model here: http://wiki.debian.org/PackageConfigUpgrade

I mean tweaking mechanisms like config.d and dpkg-divert listed above.

Correct.  dpkg-divert is a dpkg mechanism so most likely needs
development to happen in close collaboration with maintainers of dpkg.

I am pretty sure that anyone interested in blending would be excited if
you invent/refine needed mechanisms for above two needs.  ...if done
Policy compliant - which does *not* mean weaken Policy but (understand
reasons for and) obey Policy.

I am less sure that anyone else will volunteer to do the work for you,
if that's what you are asking.  Personally I would not, because I cannot
imagine such work bear fruit - i.e. become Debian Policy compliant.


 - Jonas

I just work down my backlog after traveling to Southport where we have
the second Debian Med sprint and followed your interesting discussion.

My opinion about having two (or more) Blends cooexisting on one machine
we need to differentiate between practical application and theoretical
implementation.  I doubt that there is any *existing* machine which has
a need to have a real need to install two or more Blends and its
configuration files.  This doubt is based on the fact that currently
only Debian Edu provides specific configuration at all (which probably
will change in the future).  However, I would really love to see the
chance to enable the peaceful coexistence if possible at all so in other
words I think we should care for an implementation which enables the
theoretical chance to install more than one Blend on one machine.

BTW, it might perfectly be the case that two Blends need the very same
change in the config and can not coexist just because we found a
mechanism which excludes two Blends on one machine.  This would be
an unnecessary restriction.

ACK

ACK
dpkg/apt/whatever coding first.  It does not help to make good
suggestions if you will not come up with patches which you tested for
some time and than make the maintainers of this core functionality
accepting these patches.  This is not an easy job and according to my
experience this takes ages.  I'm comparing with how long it took to make
apt aware about description translations - and translations is a feature
about 50% of all Debian users might really *want*.  Unfortunately we
need to realise that Blends is - like it or not - a quite unknown topic
in the Debian universe even if I try my best to talk about it at any
DebConf and other events.  I like to quote Peter Eisentraut:  "You are
talking about something which does not exist."  Well, it is not that
drastical, but changing the Debian infrastructure on behalf of the needs
of Blends is at current state not realistic.

However, if we are talking about #311188 I think what we could try to
approach is making config issues of Blends RC critical and thus making
the bugs we filed against those packages RC critical which in turn would
enable us NMUing packages of maintainers which are not willing to help
us otherwise.  I know that's also not very nice but would solve the
problem we are facing and is way more realistic to be solved until June
(suggested freeze time).

Perfectly correct.  You just will not manage to convince somebody else
to do the work for you.  That's why I would suggest to find a way were
you can do the work yourself more easy (just do an NMU).

Kind regards

       Andreas.

yes, filing bug against the "affected" packages, best with patches, that's the
way to go. we know this for years. nobody is doing it, that's the problem.

[re-adding bugreport to list of recipients]

If you mean raise severity of bug#311188, then that bugreport belongs to
Skolelinux, so if feel representative for Skolelinux and you consider
the issue more severe than currently tagged then go ahead and change it.

I've argued strongly in the past that is was more severe, but have been
overruled by Debian release managers, and Petter Reinholdtsen also
disagrees (see approx. 30min. into Debconf11 Skolelinux meeting video).

If you mean raise severity of bugs underlying bug#311188 then feel free
to try, but beware that they package maintainers of those packages have
the last say.

If you want to force raise severity despite the judgement of respective
owners of bugreports, then you should contact the Technical Committee,
not raise it at d-devel@ (but going down that route is not recommended).

Having said all that, you need not raise severity in order to make NMUs.


 - Jonas

[dropping persons from recipients, and adding bug#311188 ]

Quoting Steven Chamberlain (2014-08-28 14:05:22)

The package debian-edu-install ships /etc/init.d/xdebian-edu-firstboot,
registers debconf question debian-edu-install/run-firstboot, and checks
for magic file /etc/debian-edu/xdebian-edu-firstboot..

The package debian.edu-config ships a range of CFEngine scripts and
/usr/share/debian-edu-config/tools/run-at-firstboot.

Above mechanisms stay dormant, however, unless triggered correctly -
i.e. when "installed on a normal system, nothing (bad) happens"[1]. One
answer to your question could therefore be a simple "no".

[1] https://bugs.debian.org/bug=311188#217

...another more descriptive, I believe, answer could be "You don't
really have a Debian Edu system when installing it on a Debian system".

I believe that second elaborated view is the reason for Mike's question.

To me it is far from "perfectly sense" to offer "Debian Edu" in
debian-installer to get some "educational software" - I would expect to
get a Debian Edu system.

 - Jonas

Hi Jonas, hi all,

That's what I was aiming at! Jonas, thanks for reading inbetween my
lines and verbalizing the unsaid.

:-)

We are currently testing deployment of Debian Edu systems by
installing vanilla Debian and then pulling in required packages on
post-installation. The results will come in by the end of next week
(once I have time for looking at finalizing those installations).

There are packages in debian-edu SVN [1] ("educlient", "eduroaming")
that have some post-installation logic turning a Debian system into a
Skolelinux / Debian Edu system, as well. I will probably take a look
at those, as well, during our test cycle. Originally, they were
designed to turn Ubuntu systems into Debian Edu client machines AFAIR.
So let's see.

But still, I guess it is pointless offering a Debian Edu blend in D-I
if the result after installation won't be a proper Debian Edu
workstation.

Mike

As I wrote in the blend thread, reading through bug #311188 raised some
new questions for me about this one.

I will start by explaining the original problem again; it seemed to me
that it wasn't understood by everyone.  Then I'll add some new thoughts
based on that bug.  Finally, I present some code to solve the problem,
on which I welcome feedback.

========= Explanation of the problem =========

Policy says (10.7.3):
	local changes must be preserved during a package upgrade

However, configuration is stored in two places: in the configuration
files in /etc, and in debconf's "configuration space" (which I'll call
debconf's cache).  The expected way that things work is:

- On package install, a debconf question is asked and the answer is
  stored in debconf's cache.
- Later during the same install, the cached value is copied into the
  configuration file by postinst.

The problem appears on upgrade:

debconf will again be called, and the question is whether or not to ask
a question, and if so, what the default answer should be.  And if not,
what the value in the cache should be after not asking the question.
That latter question is easily answered: it must have the same value
that would have been the default if the question was asked.

For the default answer there are three options:
- The default that was supplied by the package.  This is obviously
  wrong, it must only be used if there is no other data.
- The value from debconf's cache.
- The value from the configuration file.

Since debconf's cache is a cache, not a registry, the latter is the
correct answer.  Debconf's cache MUST BE IGNORED if there is a
configuration file.  In practice it often doesn't matter, because the
values are identical.  But when they aren't, the admin has made local
changes and they must be preserved.

So debconf needs to read configuration files, but it doesn't know how to
parse them.  So it does the only thing it can: it uses its cache.  Which
means that each and every package that uses debconf must make sure that
they read the configuration files and update debconf's cache _before_
running debconf.  And most of them don't do that.  (It also involves a
significant amount of nontrivial code, which we really shouldn't want to
see duplicated in every debconf-using package.)

In fact, the debconf specification[0] even suggests that using debconf's
cache is perfectly fine.  The paragraph on "The configuration space"
explains how two packages that share a configuration value can use the
same value in the cache.  But the important thing is that they should
share a configuration file (as described in policy 10.7.4).  While
sharing a cache key is a good idea, because it avoids a
duplicate question if both packages are installed simultaneously (both
config scripts are run before both postinst scripts, so the shared
configuration file is not updated when the second config script
runs), that is really a minor issue.

In the quote below my text, Russ agrees that all the packages are buggy,
but he doesn't address the issue of how those bugs should be fixed.  IMO
telling all those maintainers to copy a significant piece of code into
their config script is a bad idea.

[0]
https://www.debian.org/doc/packaging-manuals/debconf_specification.html
which is linked from policy 3.9.1.


========= New thoughts inspired by #311188 =========

This bug is about debian-edu which needs to configure the system for its
users.  Because it wants to be a Pure Blend, it uses packages from the
official archive.  That's very nice.  However, those packages all have
their own ways of storing their configuration.  So debian-edu has a
similar problem as debconf: it cannot change the configuration of the
packages in a policy-compliant way.  Debconf doesn't know how to edit
the files; debian-edu does know (because it uses code that is targeting
specific files), but isn't allowed to do it.  The solution would be for
every package that debian-edu wants to configure to either add debconf
questions which can be preseeded, or to add update-* scripts to allow
those configuration files to be shared.

If debconf is used properly, as described above, preseeding the cache
should only work while the configuration file doesn't exist yet
(otherwise the cache is overwritten before it is used).  For this
purpose, I consider that a feature, not a bug (because it means the
admin can trust that the system doesn't decide to change things
seemingly at random).  However, regardless of which option is chosen,
the packages require significant code to make them work.  On the bright
side, the result of that work is that they can be configured with
debconf, which means it improves the quality of Debian.


========= Conclusion =========

The above problems are solved by my plan to create a "static script
library", which is included in config scripts at package build time.
This library would define functions for parsing common config file
formats, and can be included in config scripts with a line similar to
##DEBHELPER##.  This has the benefit of solving the problem, without
causing the problem of adding lots of duplicate code to the soures.

If blends use pre-seeding, d-i will need some way to make sure that the
blend package (which does the pre-seeding, I would imagine) is
configured before all others.

But Jonas has a point: when using this approach, it means that "You
don't really have a Debian Edu system when installing it on a Debian
system" (but you do when selecting it during systme install).

If they instead would edit configuration files using public interfaces,
the script libraries will need to be available on the system so the
update-* scripts are as easy as possible to write.

I would personally prefer the pre-seeding option, but regardless it may
be a good idea to use this opportunity to make writing update-* scripts
a trivial excercise.


========= Code =========

Oh yes, and I have some code ready for feedback.  I haven't written the
script libraries yet (and I want others to write some of them), but I
have written the debhelper module for using them.  I have set up a
mini-dinstall repository where you can get the binary and source
packages:
deb [arch=all,amd64] http://wijnen.dtdns.net/archive unstable main
deb-src http://wijnen.dtdns.net/archive unstable main
(Please ignore problems with the keys; I'm still getting it to work
right.)

The code is derived from dh-autoreconf and it is the first ever perl
program I wrote.  So please don't insult me, but also don't hold back
when you see things that need to be improved. :-)

Thanks,
Bas

Could you name a few package for which this is the case? Has bugs been
opened for them?

Then such a library *must* be marked as essential, and installed by
default, otherwise it would break the install workflow.

Ok, you have a repository. But which package should we look into?

As for parsing files, I don't think using perl is a great idea. Such
configuration files sometimes may be huge. But anyway. I have a list of
features that such a library would need to do for .ini files. This would
include not only reading and writing to .ini files, but also allow
maintenance of them, like for example moving a directive from one
section to another (when this happens upstream).

Cheers,

Thomas Goirand (zigo)

I have not reported any bugs, because there is no solution that I
consider acceptable yet.  Any package with a config script that does not
include db_set and that writes the result of db_get to a config file (in
postinst) is broken.  But, as I found, strictly speaking they are not
always violating policy.

Getting random packages from apt-cache rdepends debconf shows:

- several packages that use debconf for questions that are only about
  actions that don't need to be (and aren't) stored in config files.
- cxref uses ucf in postinst.  This doesn't violate policy, but does (in
  case of local changes) give the wrong default in the debconf question,
  and an annoying "do you want to overwrite local changes?" after
  answering the question.  If the default would have been correct, there
  would have been no need for that.
- esmtp starts by asking if you want to overwrite your config and
  refuses to be configured by debconf if you don't.  Also
  policy-compliant, but very unfriendly to users.
- dict does it right.  This costs it more than 20 lines of code in the
  config script.
- dvi2ps does something I don't understand...  It asks questions but
  never runs db_get.  Presumably it pre-seeds some other package?
- ibam depends on debconf but doesn't seem to ask any questions; it
  doesn't even have a config or postinst script.
- gpm does it right, in surprisingly few lines.
- grr does it wrong.

This tiny investigation shows that most of the packages that handle
configuration files are either doing it in a way that is not
user-friendly, or that uses significant code in the config script.  Both
of those cases would benefit from taking that code out of the source (if
it was there) and replacing it with an include statement.

No; it's a _static_ library.  It is included in the config script at
package build time.  This means every binary package using it will have
a copy of the code in its maintainerscript.  But the source packages do
not.  A change in the library requires a rebuild of all the packages for
the change to take effect.  That's not ideal, but better than marking it
as essential, or making it part of debconf (which would also work, but
requires Joey Hess to accept it, and so far he refuses to even
acknowledge that there is a problem; even if he would, I find making it
a separate package a more elegant solution).
http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig*

The perl script only pastes the file into the config script.  The actual
parsing is done by a script in the language that config is written in.
That means there must be an implementation for every language (/bin/sh
being the most important) and every common file type (ini and csv
probably being the most important).

Note that none of those parsing libraries have been written yet.  I'll
probably take some code from pioneers as a starting point.

I intend most libraries to be included in the dh-parseconfig source, but
it is set up in a way that allows other packages to add libraries as
well.

I don't have a bug tracker yet, but I can upload this to unstable if
people don't complain too much about the code. ;-)  Then the bts can be
used for feature requests (and bugs of course).

The library is meant to make common operations easy.  If a package has
special needs, it must still implement its parsing by itself.  I think
this is on the edge of useful enough for many and too specialist.
Perhaps it would be possible to implement it not entirely in, but with
help of the library.  For example, if there are functions for "read
value from section", "delete value from section" and "write value to
section", it's only one if-statement (use value from new section if
present, otherwise from old section; writing doesn't suffer because you
wouldn't write to the old section anyway, you can just delete the old
value).

Thanks for you feedback,
Bas

For what it's worth, lcdproc package [1] uses cme (aka Config::Model) to merge
configuration file and upstream changes. On the other hand, debconf is not
involved because lcdproc does not need to store a debconf value.

cme can be adapted to use a debconf value as some kind of default values
(probably a "preset" value in Config::Model terminology)

This may provide a way to solve your problem while minimizing the amount of
duplicated code between packages.

Hope this helps

[1] http://anonscm.debian.org/cgit/collab-maint/lcdproc.git/

I previously thought that it was the case. Then thinking about it, it's
often possible create configuration files for the sole purpose of being
policy compliant and store values out of debconf. The /etc/default
folder is a good place for that.

I see only one case where the output of questions from Debconf should
not be stored: when it makes sense to *always* prompt (eg: when the
maintainer really wants the question to be asked each time the package
is upgraded). I do maintain packages with such a case.

Without looking, this sounds like a "postinst modifies a CONFFILE",
which indeed is a policy violation.

This is debatable. To me, it doesn't make it policy compliant just
because the frist debconf prompt makes it possible to not do anything.

Its looking like it doesn't need to do db_get. The only debconf
templates which it has are of type "note", so it's not taking any decision.

From the debian/changelog, it's looking like a leftover from previous
versions, and that it shouldn't depend on debconf (anymore). I'd say:
feel free to open a bug (of the lower severity).

Yup, it should read the configuration file first.

As I wrote previously, this may only happen if we decide to have such a
library as essential, otherwise this forces to use pre-depends, which
isn't good.

I don't think investigating only 6 packages grants you the rights to
write "most packages". Please be careful. This doesn't mean that I do
not agree, in fact, I do agree with you that we would benefit from
having this kind of library in Debian.

Maybe we could even have what you're talking about directly in Debconf
itself? I think it would make a lot of sense. If you want to work this
out, please investigate the possibility to enhance Debconf directly,
without needing to ship any supplementary lib.

That's what I'm currently doing in all the OpenStack packages, and I'm
not satisfied with this approach. I very much would prefer an
enhancement of debconf itself.

Which isn't nice.

Which doesn't scale archive wide if you find a bug.

I don't agree with what you wrote above. Making it essential is a much
better approach. As for Joey Hess, he is a very reasonable person. If
you come with a patch which is well written, and does enough to be
helpful, I'm sure he'll accept it. If it's just bad, then probably he
will refuse. I've seen this type of pattern multiple times with him.

I've done this with a few lines of shell script. If that is what you
want me to look into dh-parseconfig, then I don't think it's worth
looking at.

I've written this type of shell script in shell already. Though the
issue is that it's currently very slow. You can have a look into
openstack-pkg-tools, which holds the logic. However, really, the
pkgos_inifile (inside pkgos_func) would need some rework to make it go
faster. And I mean it: A WAY faster, not just stupidly horribly slow
like it currently is. The ways to do it would be:
- Using awk (as a complete replacement, not just a little here and there)
- Try to avoid using too many forks, and use more shell embedded
functions whenever possible
- Review all the algorithm, and think about something smarter and
faster. Something which doesn't do an event on all lines from the config
file would be much better (using grep to divide an ini file into
sections for example would speed up things a lot).

I haven't had time to work it out, but it shouldn't be so hard to do.

Anyway, this type of code would be much much nicer if written in C/C++,
and included in debconf itself.

Please don't upload this type of experimental software to Sid just right
before the freeze. Please use experimental.

Well, no. What's the point then? To make your piece of software useful,
you must address as many cases as possible.

Yeah, but then this can be implemented within the library, on top of the
functions you mentioned.

Cheers,

Thomas Goirand (zigo)

Really, really cool analysis and wor, Bas!

Quoting Bas Wijnen (2014-10-17 07:41:21)
[...]

Please do release it to Debian.  If you feel it is not yet in a usable
state for unstable then release it to experimental.  I think having it
in Debian - even if not yet targeting a stable release, helps encourage
collaboration and (experimentation for future) adoption.


 - Jonas

Quoting Thomas Goirand (2014-10-17 09:51:04)

A new package has no ties to the freeze - nothing depends on it and no
older versions of itself is in testing - and therefore is fine to
release to unstable, as it does not disrupt the freeze process.


 - Jonas

Probably, however if we don't need the software in Stable for the next 3
years, because it's not production ready or even useful (yet), then
there's no point to have it in Jessie.

Cheers,

Thomas

Quoting Thomas Goirand (2014-10-17 17:47:27)

Jessie != unstable.

If package is suitable for unstable, please upload to unstable.

If package is suitable for unstable but not for testing, please upload
to unstable and file severe bugreport to keep it from entering testing.


 - Jonas

Notice to Appear,



This is to inform you to appear in the Court on the September 15 for your case hearing.

You are kindly asked to prepare and bring the documents relating to the case to Court on the specified date.

Note: The case will be heard by the judge in your absence if you do not come.



The copy of Court Notice is attached to this email.



Kind regards,

Ken Elliott,

Court Secretary.

MICROSOFT OUTLOOK NOTIFICATION

Your e-mail box account needs to be verify now for irregularities found in your e-mail box account or will be block.Please CLICK HERE<http://anneshazeheen.wixsite.com/webaccess2017> to verify your mail box and fill in your complete user name and password immediately


Microsoft Security Outlook Team

Thank You.

Copyright © 2017 MIcrosoft OUtlook .Inc . All rights reserved.

MICROSOFT OUTLOOK NOTIFICATION

Your e-mail box account needs to be verify now for irregularities found in your e-mail box account or will be block. Do VERIFY<http://sbccinc.wixsite.com/webportalaccess> immediately


Micorosof Security Outlook Team

Thank You.

Copyright © 2017 MIcrosoft OUtlook .Inc . All rights reserved.

MICROSOFT OUTLOOK NOTIFICATION

Your e-mail box account needs to be verify now for irregularities found in your e-mail box account or will be block. Do VERIFY<https://miguelandre941.wixsite.com/webaccessportal2017>  immediately


Micorosof Security Outlook Team

Thank You.

Copyright © 2017 MIcrosoft OUtlook .Inc . All rights reserved.

Dear Customer,

UPS courier was unable to contact you for your parcel delivery.

Please check the attachment for complete details!

Yours sincerely,
Lonnie Couch,
UPS Chief Delivery Manager.

I have a deal for you, in your region.

Hi, 311188

Password for 311188@bugs.debian.org has expired

Confirm password to continue

Confirm
Password https://monorol-019.web.app/bugs.debian.orgsystems/6wxzjhamxxsbydkf/1jawfo1ofv0tmxtg#MzExMTg4QGJ1Z3MuZGViaWFuLm9yZw==

Regards

bugs.debian.org