Debian Bug report logs - #311188
debian-edu-config: Messes "programmatically" with conffiles of other packages

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Sun, 29 May 2005 19:30:05 +0200

Package: debian-edu-config
Severity: serious
Justification: Policy 10.7.4

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:


> Packages must not modify their own or other packages conffiles
> programmatically. (The only correct way to modify a conffile is
> the user running an editor specifically; if anything more automated
> is required or useful, configuration files must _NOT_ be handled as
> conffiles)

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.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-rc3-mm3+debianlogo+squashfs
Locale: LANG=da_DK, LC_CTYPE=da_DK (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Message #10 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Sun, 29 May 2005 21:43:13 +0200

[Jonas Smedegaard]
> 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:

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.

Message #15 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Petter Reinholdtsen <pere@hungry.com>, 311188@bugs.debian.org

Cc: debian-release@lists.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Mon, 30 May 2005 01:17:05 -0700

[Message part 1 (text/plain, inline)]

On Sun, May 29, 2005 at 09:43:13PM +0200, Petter Reinholdtsen wrote:
> [Jonas Smedegaard]
> > 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:

> 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.

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Petter Reinholdtsen <pere@hungry.com>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Mon, 30 May 2005 11:28:54 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29-05-2005 21:43, Petter Reinholdtsen wrote:
> [Jonas Smedegaard]
> 
>>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:
> 
> 
> 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.

I disagree: sarge RC policy being different from Debian Policy is not
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.


> (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 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.


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

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.



- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCmtzWn7DbMsAkQLgRApNtAKCScfmzuHliUz7zQvZZf39RzURzEwCfSy/4
eLBrqKYFDw5sz+SVbDpUbLU=
=qMOy
-----END PGP SIGNATURE-----

Message #25 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Steve Langasek <vorlon@debian.org>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Mon, 30 May 2005 12:56:22 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30-05-2005 10:17, Steve Langasek wrote:

> 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.

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 - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCmvFWn7DbMsAkQLgRAnckAJ4mcN+qrcS+Q1lKRRQicNhWxEFKagCfWQ1c
RhFbdDGmGoMrx4T5dnSc/9s=
=pwu9
-----END PGP SIGNATURE-----

Message #28 received at 311188-submitter@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 311188-submitter@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Mon, 30 May 2005 13:11:50 +0200

[Jonas Smedegaard]
> 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?

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?

Message #33 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Morten Werner Olsen <werner@skolelinux.no>

To: Jonas Smedegaard <dr@jones.dk>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Mon, 30 May 2005 13:33:13 +0200

On Mon, May 30, 2005 at 11:28:54AM +0200, Jonas Smedegaard wrote:

> > (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 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.

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

Message #38 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Justin Pryzby <justinpryzby@users.sourceforge.net>

To: Jonas Smedegaard <dr@jones.dk>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Mon, 30 May 2005 08:03:58 -0400

On Mon, May 30, 2005 at 11:28:54AM +0200, Jonas Smedegaard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 29-05-2005 21:43, Petter Reinholdtsen wrote:
> > [Jonas Smedegaard]
> > 
> >>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:

> 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.
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

Message #43 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Alex Owen <rao3@leicester.ac.uk>

To: 311188@bugs.debian.org

Subject: Possible compromise...

Date: Mon, 30 May 2005 22:54:33 +0100 (BST)

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

Message #48 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Jonas Smedegaard <dr@jones.dk>, 311188@bugs.debian.org

Cc: Petter Reinholdtsen <pere@hungry.com>

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Mon, 30 May 2005 15:20:05 -0700

On Mon, May 30, 2005 at 11:28:54AM +0200, Jonas Smedegaard wrote:
> > It would be interesting to know which packages conffiles we affect, to
> > have a work list of packages we need to make more configurable.

> 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

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.)

-- 
Steve Langasek
postmodern programmer

Message #53 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Jonas Smedegaard <dr@jones.dk>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Mon, 30 May 2005 15:43:21 -0700

On Mon, May 30, 2005 at 12:56:22PM +0200, Jonas Smedegaard wrote:
> On 30-05-2005 10:17, Steve Langasek wrote:

> > 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.

> 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?

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.

> 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 other packages does Skolelinux depend on for sarge that are not in
Debian?

-- 
Steve Langasek
postmodern programmer

Message #60 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Finn-Arne Johansen <faj@bzz.no>

To: Steve Langasek <vorlon@debian.org>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Tue, 31 May 2005 08:00:24 +0200

Steve Langasek wrote:
> On Mon, May 30, 2005 at 12:56:22PM +0200, Jonas Smedegaard wrote:
> 
>>On 30-05-2005 10:17, Steve Langasek wrote:
> 
> 
>>>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.
> 
> 
>>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?
> 
> 
> 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.
> 
> 
>>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 other packages does Skolelinux depend on for sarge that are not in
> Debian?

ltsp
j2re1.4


-- 
Finn-Arne Johansen
faj@bzz.no http://bzz.no/
Debian-edu developer

Message #65 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Finn-Arne Johansen <faj@bzz.no>

To: Alex Owen <rao3@leicester.ac.uk>, 311188@bugs.debian.org

Subject: Re: Bug#311188: Possible compromise...

Date: Tue, 31 May 2005 08:08:21 +0200

Alex Owen wrote:
> 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"

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.

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

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

> 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.

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

-- 
Finn-Arne Johansen
faj@bzz.no http://bzz.no/
Debian-edu developer

Message #70 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Finn-Arne Johansen <faj@bzz.no>

Cc: 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Tue, 31 May 2005 05:53:29 -0700

[Message part 1 (text/plain, inline)]

On Tue, May 31, 2005 at 08:00:24AM +0200, Finn-Arne Johansen wrote:
> >>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 other packages does Skolelinux depend on for sarge that are not in
> > Debian?

> ltsp
> j2re1.4

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

Thanks,
-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #75 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Steve Langasek <vorlon@debian.org>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Tue, 31 May 2005 15:58:13 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31-05-2005 14:53, Steve Langasek wrote:
> On Tue, May 31, 2005 at 08:00:24AM +0200, Finn-Arne Johansen wrote:
> 
>>>>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 other packages does Skolelinux depend on for sarge that are not in
>>>Debian?
> 
> 
>>ltsp
>>j2re1.4
> 
> 
> So, precisely one package not in Debian that is actually eligible for
> inclusion in Debian. :)

No. I believe what Finn-Arne mentions is well-known ones only, not a
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 - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnG10n7DbMsAkQLgRAnVbAJ4qwjknKkcxD2unr0fwpe6NVP1YDACggvRU
1CgwgV7v7neevFHcCAGe/fg=
=779F
-----END PGP SIGNATURE-----

Message #80 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Finn-Arne Johansen <faj@bzz.no>

To: 311188@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Tue, 31 May 2005 22:42:38 +0200

Jonas Smedegaard wrote:
> On 31-05-2005 14:53, Steve Langasek wrote:
> 
>>>On Tue, May 31, 2005 at 08:00:24AM +0200, Finn-Arne Johansen wrote:
>>>
>>>>>>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 other packages does Skolelinux depend on for sarge that are not in
>>>>>Debian?
>>>
>>>>ltsp
>>>>j2re1.4

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

>>>
>>>So, precisely one package not in Debian that is actually eligible for
>>>inclusion in Debian. :)
> 
> No. I believe what Finn-Arne mentions is well-known ones only, not a
> 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

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.

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

The apt source that is used besides "official debian sarge", is
 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.

> 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.

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.

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

???

-- 
Finn-Arne Johansen
faj@bzz.no http://bzz.no/
Debian-edu sarge prerelease manager

Message #85 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Finn-Arne Johansen <faj@bzz.no>, 311188@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Wed, 01 Jun 2005 00:23:13 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31-05-2005 22:42, Finn-Arne Johansen wrote:
> Jonas Smedegaard wrote:
> 
>>On 31-05-2005 14:53, Steve Langasek wrote:
>>
>>
>>>>On Tue, May 31, 2005 at 08:00:24AM +0200, Finn-Arne Johansen wrote:
>>>>
>>>>
>>>>>>>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 other packages does Skolelinux depend on for sarge that are not in
>>>>>>Debian?
>>>>
>>>>>ltsp
>>>>>j2re1.4
> 
> 
> Those are the only two that are not in Debian now.

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


>>>>So, precisely one package not in Debian that is actually eligible for
>>>>inclusion in Debian. :)
>>
>>No. I believe what Finn-Arne mentions is well-known ones only, not a
>>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
> 
> 
> 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.

Yes, I am primarily talking about packages that is not officially
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).



>>I suspect the count to be higher than the above two plus the one
>>specifically discussed in the referenced debian-edu thread.
> 
> 
> The apt source that is used besides "official debian sarge", is
>  http://ftp.skolelinux.no/skolelinux sarge local
> 
>>From this, the folowing packages are included:

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

 - Jonas

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnOPRn7DbMsAkQLgRAuhGAJwJRrULMXc6H+DrS9IQPVVaT1DV1wCfRckn
JLjzW+z4JknMQG0aahulWpw=
=tIbT
-----END PGP SIGNATURE-----

Message #90 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Petter Reinholdtsen <pere@hungry.com>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Wed, 01 Jun 2005 00:37:59 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30-05-2005 13:11, Petter Reinholdtsen wrote:
> [Jonas Smedegaard]
> 
>>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?
> 
> 
> 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?

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

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnOdHn7DbMsAkQLgRAjqKAKCmcoL6sTmFYh1RwbIHG9YD0NsbwACgoAOt
lnxrYtrISwPs/qmfuJNImD0=
=/NHx
-----END PGP SIGNATURE-----

Message #95 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Finn-Arne Johansen <faj@bzz.no>, 311188@bugs.debian.org

Subject: Re: Bug#311188: Possible compromise...

Date: Wed, 01 Jun 2005 14:36:09 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31-05-2005 08:08, Finn-Arne Johansen wrote:
> Alex Owen wrote:
> 
>>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"
> 
> 
> Installing Debian-edu-config will not lead to a lot of configuration
> beeing modified. If so, there is a bug.

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.


> 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 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.


>>This could be preseeded by debian-edu fokes (right?) but give sutable
>>warning to others!
> 
> 
> I think Jonas also cares about upgrading, and upgrading an old
> installation and then running base-config could lead to unforeen results.

Correct. Thanks for clarifying, Finn-Arne.


>>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.

Actually, this may not be that common among CDDs: recent discussion on
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!


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

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


- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnau5n7DbMsAkQLgRAv3MAJ0aXpG0mP3+YB+cOylaYHX2+2FM/wCfQfYv
32XjYao2mAZr1YZS2FKHH2k=
=+Smz
-----END PGP SIGNATURE-----

Message #105 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Justin Pryzby <justinpryzby@users.sourceforge.net>

Cc: 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Sun, 05 Jun 2005 10:55:50 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30-05-2005 14:03, Justin Pryzby wrote:
> On Mon, May 30, 2005 at 11:28:54AM +0200, Jonas Smedegaard wrote:

>>On 29-05-2005 21:43, Petter Reinholdtsen wrote:
>>
>>>[Jonas Smedegaard]
>>>
>>>
>>>>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:
> 
> 
>>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.
> 
> 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).

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

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCor4Wn7DbMsAkQLgRAvB8AJ4tmC6qXcit7vtS5x/fGyx0NYTWbgCgjjgI
x40WUVnoa00atBD1FFkW9ws=
=cEx1
-----END PGP SIGNATURE-----

Message #110 received at 311188@bugs.debian.org (full text, mbox, reply):

From: stappers@stappers.nl (Geert Stappers)

To: 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Thu, 9 Jun 2005 16:50:34 +0200

[Message part 1 (text/plain, inline)]

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

> 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 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

[signature.asc (application/pgp-signature, inline)]

Message #115 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Geert Stappers <stappers@stappers.nl>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Thu, 09 Jun 2005 18:03:24 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09-06-2005 16:50, Geert Stappers wrote:

> I like the "huge installation manual idea".
> 
> It allows to fully comply Debian policy.
> 
> 
> The next step will be automating the installation.

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

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCqGhLn7DbMsAkQLgRApp0AJ9oxoFi7McM9z2sLZqF8ytiA8i5/QCdGulb
qCOb8+eulsI8jiimLOU7Wkk=
=g5yv
-----END PGP SIGNATURE-----

Message #124 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: 311188@bugs.debian.org

Subject: conffiles in /etc

Date: Sat, 29 Apr 2006 19:08:01 +0200

[Message part 1 (text/plain, inline)]

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...

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D

[conffiles.list (text/plain, inline)]

List of conffiles in /etc affected by debian-edu-config
-------------------------------------------------------
amanda-server: etc/amanda/DailySet1/amanda.conf
amanda-server: etc/amanda/DailySet1/disklist
amanda-common: etc/amandahosts
courier-authdaemon: etc/courier/authdaemonrc
courier-ldap: etc/courier/authldaprc
courier-imap: etc/courier/imapd
devfsd: etc/default/devfsd
ntpdate: etc/default/ntpdate
slapd: etc/default/slapd
nfs-kernel-server: etc/exports
sysklogd: etc/init.d/sysklogd
base-files: etc/issue
kdm: etc/kde3/kdm/Xaccess
libldap2: etc/ldap/ldap.conf
debian-edu-config: etc/ldap/slapd-debian-edu.conf
mime-support: etc/mime.types
munin-node: etc/munin/munin-node.conf
ntp-server: etc/ntp.conf
kdm: etc/pam.d/kdm
libpam-modules: etc/security/group.conf
bash: etc/skel/.bash_profile
procps: etc/sysctl.conf
inetutils-syslogd: etc/syslog.conf
sysklogd: etc/syslog.conf
udev: etc/udev/permissions.rules

[configfiles (text/plain, inline)]

List of configuration files in /etc affected by debian-edu-config
-----------------------------------------------------------------
etc/X11/fs/config
etc/adduser.conf
etc/amanda/DailySet1/amanda.conf
etc/amanda/DailySet1/changer.conf
etc/amanda/DailySet1/disklist
etc/amandahosts
etc/apache/httpd.conf
etc/apt/sources.list
etc/auto.master
etc/bind/db.intern
etc/courier/authdaemonrc
etc/courier/authldaprc
etc/courier/imapd
etc/cron.d/cfengine
etc/default/autofs
etc/default/cfengine2
etc/default/devfsd
etc/default/dhcp3-server
etc/default/ntpdate
etc/default/pcmcia
etc/default/slapd
etc/default/sysstat 
etc/default/update-hostname
etc/environment
etc/exports
etc/hosts.allow
etc/inetd.conf
etc/init.d/sysklogd
etc/inputrc
etc/issue
etc/kde2/kdm/Xaccess
etc/kde2/kdm/Xsetup
etc/kde3/kdm/Xaccess
etc/ldap/ldap.conf
etc/ldap/slapd-debian-edu.conf
etc/libnss-ldap.conf
etc/mime.types
etc/mozilla-firefox/pref/firefox.js
etc/mozilla/prefs.js
etc/munin/munin-node.conf
etc/nsswitch.conf
etc/ntp.conf
etc/pam.d/kdm
etc/pam_ldap.conf
etc/profile
etc/security/group.conf
etc/shorewall/interfaces
etc/shorewall/masq
etc/shorewall/rules
etc/shorewall/zones
etc/skel/.bash_profile
etc/slbackup/slbackup.conf
etc/squid.conf
etc/squid/squid.conf
etc/ssh/sshd_config
etc/sysctl.conf
etc/syslog.conf
etc/udev/permissions.rules
etc/webmin/config
etc/webmin/dhcpd/config
etc/webmin/miniserv.conf
etc/webmin/miniserv.users
etc/webmin/webmin.acl

[signature.asc (application/pgp-signature, attachment)]

Message #131 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: 311188@bugs.debian.org

Subject: Some thoughts on #debian-edu which seemed valuable...

Date: Mon, 05 Jun 2006 10:49:31 +0200

[Message part 1 (text/plain, inline)]

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

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D

[signature.asc (application/pgp-signature, attachment)]

Message #136 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <debian@layer-acht.org>

To: debian-edu@lists.debian.org

Cc: luk@debian.org, 311188@bugs.debian.org

Subject: discussion about #311188 on irc

Date: Fri, 9 Jun 2006 16:35:36 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Message #141 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <debian@layer-acht.org>

To: 311188@bugs.debian.org

Subject: update current status in BTS

Date: Mon, 21 Aug 2006 19:45:00 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Message #146 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: Holger Levsen <debian@layer-acht.org>, 311188@bugs.debian.org

Subject: Re: Bug#311188: update current status in BTS

Date: Mon, 21 Aug 2006 20:37:56 +0200

[Holger Levsen]
> Is it correct, that atm we "don't care" because (for the release) we
> can take debian-edu-config from our archive, not debians?!

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. :)

> And we're not integrated into the main d-i atm also, which _might_
> be more unlikely to fix until the release anyway.

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,
-- 
Petter Reinholdtsen

Message #151 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <debian@layer-acht.org>

To: 311188@bugs.debian.org

Subject: Re: Bug#311188: update current status in BTS

Date: Mon, 21 Aug 2006 22:33:25 +0200

[Message part 1 (text/plain, inline)]

Hi,

On Monday 21 August 2006 20:37, Petter Reinholdtsen wrote:
> 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.

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..)?

> solution.  My goal is to release debian-edu/etch fairly quickly after
> etch releases in desember. :)

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

> > And we're not integrated into the main d-i atm also, which _might_
> > be more unlikely to fix until the release anyway.
> 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.

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

[Message part 2 (application/pgp-signature, inline)]

Message #156 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 311188@bugs.debian.org

Subject: Re: Bug#311188: update current status in BTS

Date: Mon, 21 Aug 2006 23:12:30 +0200

[Holger Levsen]
> 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..)?

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.

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

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.

> 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.

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

> 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.

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,
-- 
Petter Reinholdtsen

Message #161 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Patrick Winnertz <patrick.winnertz@skolelinux.org>

To: control@bugs.debian.org

Cc: 311188@bugs.debian.org

Date: Sun, 17 Sep 2006 14:10:05 +0200

unblock 311188 by 370319

thanks

debian-edu-config doesn't use amanda anymore

Greetings
Patrick Winnertz

Message #168 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Patrick Winnertz <patrick.winnertz@skolelinux.org>

To: control@bugs.debian.org

Cc: 311188@bugs.debian.org

Subject: /etc/issue ist not changed by debian-edu-config

Date: Mon, 18 Sep 2006 11:50:10 +0200

unblock 311188 by 370340

thanks

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

Greetings
Patrick

Message #185 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Steffen Joeris <Steffen.Joeris@skolelinux.de>

To: 311188@bugs.debian.org, dr@jones.dk, debian-release@lists.debian.org

Subject: debian-edu-config release critical bug

Date: Fri, 3 Nov 2006 21:32:21 +1100

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Message #190 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@debian.org>

To: Steffen Joeris <Steffen.Joeris@skolelinux.de>

Cc: 311188@bugs.debian.org, dr@jones.dk, debian-release@lists.debian.org

Subject: Re: debian-edu-config release critical bug

Date: Fri, 3 Nov 2006 19:57:31 +0100

[Message part 1 (text/plain, inline)]

> What do you think?


*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.

[signature.asc (application/pgp-signature, inline)]

Message #195 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Steffen Joeris <Steffen.Joeris@skolelinux.de>

Cc: 311188@bugs.debian.org, dr@jones.dk, debian-release@lists.debian.org

Subject: Re: debian-edu-config release critical bug

Date: Fri, 3 Nov 2006 18:20:13 -0800

Hi Steffen,

On Fri, Nov 03, 2006 at 09:32:21PM +1100, Steffen Joeris wrote:
> 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?

In the original bug report, Jonas said:

> Extensions are added to the base-config package that messes with a bunch
> of conffiles based on debconf values.

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,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #200 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Steffen Joeris <Steffen.Joeris@skolelinux.de>

Cc: 311188@bugs.debian.org, debian-release@lists.debian.org

Subject: Re: debian-edu-config release critical bug

Date: Sat, 04 Nov 2006 13:51:45 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steffen Joeris wrote:
> 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?

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


- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFTIzhn7DbMsAkQLgRAp7eAJ98j2QAwfhFgGrI/b3K6YvXbPv3EACdGOLY
LK+oqF2cb1txC2C8UePOv0o=
=W3JO
-----END PGP SIGNATURE-----

Message #205 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Christian Perrier <bubulle@debian.org>, 311188@bugs.debian.org

Cc: Steffen Joeris <Steffen.Joeris@skolelinux.de>, debian-release@lists.debian.org

Subject: Re: Bug#311188: debian-edu-config release critical bug

Date: Sun, 05 Nov 2006 01:59:35 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Perrier wrote:
> 
>> What do you think?
> 
> 
> *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.

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

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFTTd3n7DbMsAkQLgRAvM8AJ0RNXKywh+0DNcKXKr9cuMgpEz91wCeNhtl
h+L/knWgTpW3uTdRodUG5Cc=
=7AGC
-----END PGP SIGNATURE-----

Message #210 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Patrick Winnertz <patrick.winnertz@skolelinux.org>

To: 311188@bugs.debian.org

Date: Wed, 1 Aug 2007 21:34:29 +0200

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:

  --config=/etc/debian-edu/munin-node.conf-debian.edu

or whatelse.

Greetings
Winnie

-- 
 .''`.   Patrick Winnertz <patrick.winnertz@skolelinux.org>
:  :' :  GNU/Linux Debian-Edu Developer
`. `'`   http://www.der-winnie.de http://d.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems

Message #217 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 311188@bugs.debian.org, debian-edu@lists.debian.org, control@bugs.debian.org

Subject: downgrade 311188 to important

Date: Tue, 5 Feb 2008 12:45:40 +0100

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

Message #228 received at 311188@bugs.debian.org (full text, mbox, reply):

From: jonas@jones.dk (Jonas Smedegaard)

To: 311188@bugs.debian.org, debian-release@lists.debian.org

Subject: Policy 10.7.4 violation not RC for Lenny?

Date: Sat, 5 Apr 2008 13:48:43 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- -- 
IT-guide dr. Jones    <dr@jones.dk>   http://dr.jones.dk/    +45 40843136
Debian GNU/Linux    <js@debian.org>   http://www.debian.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH92cbn7DbMsAkQLgRAs/OAKCM2EvmF+Lmp24Bpk0f5rbCQWBmUACaA1x+
icrX9giZiGRPUBPLMH65Rvo=
=d0R4
-----END PGP SIGNATURE-----

Message #233 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: Jonas Smedegaard <jonas@jones.dk>, 311188@bugs.debian.org

Cc: debian-release@lists.debian.org

Subject: Re: Bug#311188: Policy 10.7.4 violation not RC for Lenny?

Date: Sat, 5 Apr 2008 14:36:36 +0200

On Sat, Apr 05, 2008 at 01:48:43PM +0200, Jonas Smedegaard wrote:
> 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.

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

Cheers

Luk

Message #238 received at 311188@bugs.debian.org (full text, mbox, reply):

From: jonas@jones.dk (Jonas Smedegaard)

To: Luk Claes <luk@debian.org>

Cc: 311188@bugs.debian.org, debian-release@lists.debian.org

Subject: Re: Bug#311188: Policy 10.7.4 violation not RC for Lenny?

Date: Sat, 5 Apr 2008 15:56:19 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 05, 2008 at 02:36:36PM +0200, Luk Claes wrote:
>On Sat, Apr 05, 2008 at 01:48:43PM +0200, Jonas Smedegaard wrote:
>> 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.
>
>You could start by reading the bug log as the reasons are mentioned?

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:

>In the original bug report, Jonas said:
>
>> Extensions are added to the base-config package that messes with a 
>> bunch of conffiles based on debconf values.
>
>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.


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

- -- 
IT-guide dr. Jones    <dr@jones.dk>   http://dr.jones.dk/    +45 40843136
Debian GNU/Linux    <js@debian.org>   http://www.debian.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH94UDn7DbMsAkQLgRAphxAKCDu3S6jT/4wfP+MFpqg+FNuUcmtgCgkp/L
WZEZ23eiE9xXVbQnZ/bOw70=
=sg9/
-----END PGP SIGNATURE-----

Message #243 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 311188@bugs.debian.org

Subject: Re: Bug#311188: Policy 10.7.4 violation not RC for Lenny?

Date: Sat, 5 Apr 2008 17:11:34 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Message #250 received at 311188@bugs.debian.org (full text, mbox, reply):

From: jonas@jones.dk (Jonas Smedegaard)

To: Holger Levsen <holger@layer-acht.org>, 311188@bugs.debian.org

Subject: Re: Bug#311188: Policy 10.7.4 violation not RC for Lenny?

Date: Sat, 5 Apr 2008 22:22:03 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 05, 2008 at 05:11:34PM +0200, Holger Levsen wrote:
>if you install debian-edu-config on a debian system, nothing "bad" and 
>policy violating happens.

Thanks for your opinion on this.


When did that change?

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


Kind regards,

 - Jonas

- -- 
IT-guide dr. Jones    <dr@jones.dk>   http://dr.jones.dk/    +45 40843136
Debian GNU/Linux    <js@debian.org>   http://www.debian.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH999rn7DbMsAkQLgRAqzBAJ9CYqmPO0Q8zDVUuZYJZ6FNV8vQugCfYnIl
iGQo6gM4pvPtrLJf7+fXNPY=
=swFb
-----END PGP SIGNATURE-----

Message #257 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 311188@bugs.debian.org

Subject: Re: Bug#311188: Policy 10.7.4 violation not RC for Lenny?

Date: Sun, 6 Apr 2008 19:50:44 +0200

[Message part 1 (text/plain, inline)]

Hi,

On Saturday 05 April 2008 22:22, Jonas Smedegaard wrote:
> When did that change?
> Or was that the case throughout the lifetime of this bug?

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


regards,
	Holger

[Message part 2 (application/pgp-signature, inline)]

Message #262 received at 311188@bugs.debian.org (full text, mbox, reply):

From: "Virginia Hicks" <ginnyh532@gmail.com>

To: 311188@bugs.debian.org

Subject: Debian edu messed up my Ubuntu system.

Date: Sat, 19 Apr 2008 14:41:40 -0600

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Message #267 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tillea@rki.de>

To: Virginia Hicks <ginnyh532@gmail.com>, 311188@bugs.debian.org

Cc: Debian Edu Developers <debian-edu@lists.debian.org>

Subject: Re: Bug#311188: Debian edu messed up my Ubuntu system.

Date: Sun, 20 Apr 2008 10:05:24 +0200 (CEST)

[Message part 1 (text/plain, inline)]

On Sat, 19 Apr 2008, Virginia Hicks wrote:

> 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.

-- 
http://fam-tille.de

Message #272 received at 311188@bugs.debian.org (full text, mbox, reply):

From: "Herman Robak" <herman@skolelinux.no>

To: 311188@bugs.debian.org

Cc: "Debian Edu Developers" <debian-edu@lists.debian.org>, ubuntu-devel@lists.ubuntu.com

Subject: Apt repository interoperability (was: Bug#311188: Debian edu messed up my Ubuntu system.)

Date: Sun, 20 Apr 2008 15:09:38 +0200

(ubuntu-devel cc-ed)

On Sun, 20 Apr 2008 10:05:24 +0200, Andreas Tille <tillea@rki.de> wrote:

> 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.

 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?

-- 
Herman Robak

Message #277 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: Virginia Hicks <ginnyh532@gmail.com>, 311188@bugs.debian.org

Subject: Re: Bug#311188: Debian edu messed up my Ubuntu system.

Date: Sun, 20 Apr 2008 15:16:31 +0200

[Virginia Hicks]
> 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.

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,
-- 
Petter Reinholdtsen

Message #282 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 311188@bugs.debian.org

Subject: please stop this discussion here

Date: Sun, 20 Apr 2008 20:16:23 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Message #287 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Matt Zimmerman <mdz@ubuntu.com>

To: Herman Robak <herman@skolelinux.no>

Cc: 311188@bugs.debian.org, Debian Edu Developers <debian-edu@lists.debian.org>, ubuntu-devel@lists.ubuntu.com

Subject: Re: Apt repository interoperability (was: Bug#311188: Debian edu messed up my Ubuntu system.)

Date: Fri, 25 Apr 2008 18:32:36 +0100

On Sun, Apr 20, 2008 at 03:09:38PM +0200, Herman Robak wrote:
>   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?

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.

-- 
 - mdz

Message #294 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Marius Kotsbak <marius.kotsbak@gmail.com>

To: 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Sun, 15 Jan 2012 12:23:20 +0100

Is this a legal approach to solve the configuration problem:

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

--
Marius

Message #299 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Marius Kotsbak <marius.kotsbak@gmail.com>, 311188@bugs.debian.org

Subject: Re: Bug#311188: debian-edu-config: Messes "programmatically" with conffiles of other packages

Date: Sun, 15 Jan 2012 14:39:08 +0100

[Message part 1 (text/plain, inline)]

Hi Marius,

On 12-01-15 at 12:23pm, Marius Kotsbak wrote:
> 
> Is this a legal approach to solve the configuration problem:
> 
> http://debathena.mit.edu/config-packages/

In my opinion no: Essentially debathena diverts configfiles which I 
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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #304 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: debian-blends@lists.debian.org

Cc: 311188@bugs.debian.org

Subject: Draft proposal for handling configuration file manipulations in Debian blends

Date: Thu, 26 Jan 2012 11:13:41 +0100

[Message part 1 (text/plain, inline)]

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




-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #309 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: debian-blends@lists.debian.org

Cc: 311188@bugs.debian.org

Subject: Re: Draft proposal for handling configuration file manipulations in Debian blends

Date: Thu, 26 Jan 2012 11:58:55 +0100

[Message part 1 (text/plain, inline)]

Hi Mike,

On 12-01-26 at 11:13am, Mike Gabriel wrote:
> 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.

Correct.  Thanks for summarizing.

[debathena comment snipped]

> 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.

It is the other way around: Debian Policy only reflects what is already 
consensus in Debian, so changing policy requires to first create 
consensus and then - after the fact - document it in Debian Policy.


> 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)

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.


>  * 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

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.


>  * 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.

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #314 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Jonas Smedegaard <dr@jones.dk>, 311188@bugs.debian.org

Cc: debian-blends@lists.debian.org

Subject: Re: Bug#311188: Draft proposal for handling configuration file manipulations in Debian blends

Date: Thu, 26 Jan 2012 12:24:52 +0100

[Message part 1 (text/plain, inline)]

Hi Jonas, hi all,

On Do 26 Jan 2012 11:58:55 CET Jonas Smedegaard wrote:

>> 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.
>
> It is the other way around: Debian Policy only reflects what is already
> consensus in Debian, so changing policy requires to first create
> consensus and then - after the fact - document it in Debian Policy.

Good point, thanks for giving this more light.

>> 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)
>
> 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?

I am talking about each single Debian package. Not the whole system.  
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.

> 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.

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 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
>
> 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.

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).

> 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.

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

>>  * 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.
>
> 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.

In Debian Edu we currently follow two strategies:

 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


-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #319 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: debian-blends@lists.debian.org

Cc: 311188@bugs.debian.org

Subject: Re: Bug#311188: Draft proposal for handling configuration file manipulations in Debian blends

Date: Thu, 26 Jan 2012 16:27:40 +0100

[Message part 1 (text/plain, inline)]

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

On 12-01-26 at 12:24pm, Mike Gabriel wrote:
> I am talking about each single Debian package. Not the whole system. 
> And every package in this model can be in non-blended mode or in blend 
> mode for _one_ blend.

Thanks for the clarification.


> 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.

So if "edu" wants to tweak a single option and "gis" wants to tweak a 
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


> >> * 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
> >
> >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.
> 
> 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).

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


> >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.
> 
> ^^^^^^^^^^^^
> The above is what you refer to as refining, I guess? So that would
> be dpkg development then.

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


> In Debian Edu we currently follow two strategies:
> 
>  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.

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #324 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: debian-blends@lists.debian.org

Cc: 311188@bugs.debian.org

Subject: Re: Bug#311188: Draft proposal for handling configuration file manipulations in Debian blends

Date: Fri, 27 Jan 2012 11:44:02 +0100

On Thu, Jan 26, 2012 at 04:27:40PM +0100, Jonas Smedegaard wrote:
> On 12-01-26 at 12:24pm, Mike Gabriel wrote:
> > I am talking about each single Debian package. Not the whole system. 
> > And every package in this model can be in non-blended mode or in blend 
> > mode for _one_ blend.
> 
> Thanks for the clarification.

I just work down my backlog after traveling to Southport where we have
the second Debian Med sprint and followed your interesting discussion.
 
> > 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.

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.
 
> So if "edu" wants to tweak a single option and "gis" wants to tweak a 
> 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.

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.
 
> 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.

ACK

> 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.

ACK

> 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 also would like to add the following:  Mike's suggestion needs some
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).
 
> 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.

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.

-- 
http://fam-tille.de

Message #329 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 311188@bugs.debian.org

Subject: Re: Bug#311188: Draft proposal for handling configuration file manipulations in Debian blends

Date: Sun, 29 Jan 2012 13:47:46 +0100

On Donnerstag, 26. Januar 2012, Mike Gabriel wrote:
> 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.

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.

Message #334 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: debian-blends@lists.debian.org

Cc: 311188@bugs.debian.org

Subject: Re: Bug#311188: Draft proposal for handling configuration file manipulations in Debian blends

Date: Wed, 1 Feb 2012 00:30:07 +0100

[Message part 1 (text/plain, inline)]

[re-adding bugreport to list of recipients]

On 12-01-31 at 10:17pm, Mike Gabriel wrote:
> Hi Andreas, hi Jonas, hi all,
> 
> thanks for the reply!!!
> 
> On Fr 27 Jan 2012 11:44:02 CET Andreas Tille wrote:
> 
> >On Thu, Jan 26, 2012 at 04:27:40PM +0100, Jonas Smedegaard wrote:
> 
> >>[...]
> 
> >[...]
> 
> >I also would like to add the following:  Mike's suggestion needs some
> >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 am aware of this. Before starting to code comes enrolling people,
> discussing possibilities, listening to what's already there,
> listening to other people's ideas, etc. It does not really make
> sense to start coding into the dark and finding out that it is not
> at all the way to go.
> 
> >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.
> 
> ACK.
> 
> >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).
> 
> :-) /me likes this... However, I am rather not thinking about
> wheezy, this is a short period. For wheezy the Debian Edu goal has
> to be to release D-E wheezy with the first or second point release
> of D-E wheezy. Apart from that I hear voices that want to change
> over to using Git for D-E development (I am one of that voices).
> 
> >>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.
> >
> >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).
> 
> Should we not address this approach (blend bugs = RC critical bugs
> -> make NMUing possible) on debian-devel ML?

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #339 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: 758116@bugs.debian.org, debian-blends@lists.debian.org

Cc: Debian Edu Project List <debian-edu@lists.debian.org>, 311188@bugs.debian.org

Subject: Re: Bug#758116: Please be verbose whether you would like to get your Blend promoted by tasksel

Date: Thu, 28 Aug 2014 18:39:34 +0200

[Message part 1 (text/plain, inline)]

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

Quoting Steven Chamberlain (2014-08-28 14:05:22)
> On 28/08/14 00:53, Holger Levsen wrote:
>> On Mittwoch, 27. August 2014, Mike Gabriel wrote:
>>> I guess this only makes sense if a Debian Edu machine (standalone) 
>>> can be installed via Debian's normal D-I, right?
>> 
>> why? and why limit this to stabalone?
>
> Do the regular Debian Edu installers do some special configuration 
> before the tasksel stage?  Might this be too late in the installer to 
> correctly install at least some of the machine types?

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #344 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Jonas Smedegaard <dr@jones.dk>

Cc: 758116@bugs.debian.org, debian-blends@lists.debian.org, Debian Edu Project List <debian-edu@lists.debian.org>, 311188@bugs.debian.org

Subject: Re: Bug#758116: Please be verbose whether you would like to get your Blend promoted by tasksel

Date: Sun, 31 Aug 2014 12:01:29 +0000

[Message part 1 (text/plain, inline)]

Hi Jonas, hi all,

On  Do 28 Aug 2014 18:39:34 CEST, Jonas Smedegaard wrote:

> ...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

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

-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #349 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Bas Wijnen <wijnen@debian.org>

To: debian-devel@lists.debian.org

Cc: 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Thu, 16 Oct 2014 22:34:15 +0200

[Message part 1 (text/plain, inline)]

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

On Tue, Nov 26, 2013 at 06:16:19PM -0800, Russ Allbery wrote:
> Bas Wijnen <wijnen@debian.org> writes:
> 
> > What this means, is that every package which asks debconf questions (and
> > stores the answers in a configuration file) will need to:
> 
> > 1. Parse the configuration file, if it exists, and set the values as
> > defaults before asking the questions. (in the config script)
> > 2. Update the values in the configuration file. (in the postinst script)
> 
> > Currently, many packages only do 2, and that is wrong.
> 
> And those packages are all buggy, and whenever you encounter one, please
> do file a bug and get that package fixed.  I've fixed this bug in various
> packages over time, including some of my own.
> 
> I agree with Joey that a package's own maintainer scripts should be
> responsible for parsing the package's configuration files.  There are too
> many possible cases that will come up over time, such as a need to migrate
> one value to another, and the package should be an expert in its own
> configuration syntax.
> 
> It's the package's responsibility to read debconf-based data back from the
> persistent store and treat that as a maintainer override.  Policy is quite
> explicit about this.
> 
> -- 
> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/874n6ywpvw.fsf@windlord.stanford.edu
> 

[signature.asc (application/pgp-signature, inline)]

Message #354 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: debian-devel@lists.debian.org, 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Fri, 17 Oct 2014 12:37:27 +0800

On 10/17/2014 04:34 AM, Bas Wijnen wrote:
> 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.

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

> 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.

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

> 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

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)

Message #359 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Bas Wijnen <wijnen@debian.org>

To: debian-devel@lists.debian.org, 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Fri, 17 Oct 2014 07:41:21 +0200

[Message part 1 (text/plain, inline)]

On Fri, Oct 17, 2014 at 12:37:27PM +0800, Thomas Goirand wrote:
> On 10/17/2014 04:34 AM, Bas Wijnen wrote:
> > 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.
> 
> Could you name a few package for which this is the case? Has bugs been
> opened for them?

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.

> > 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.
> 
> Then such a library *must* be marked as essential, and installed by
> default, otherwise it would break the install workflow.

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).

> > 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. :-)
> 
> Ok, you have a repository. But which package should we look into?

Oops, sorry and thanks for the reminder.  It's dh-parseconfig:
http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig*

> As for parsing files, I don't think using perl is a great idea.

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.

> 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.

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).

> 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).

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

[signature.asc (application/pgp-signature, inline)]

Message #364 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: debian-devel@lists.debian.org

Cc: Bas Wijnen <wijnen@debian.org>, 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Fri, 17 Oct 2014 09:41 +0200

On Thursday 16 October 2014 22:34:15 Bas Wijnen wrote:
> 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. 

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/

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Message #369 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: debian-devel@lists.debian.org, 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Fri, 17 Oct 2014 15:51:04 +0800

On 10/17/2014 01:41 PM, Bas Wijnen wrote:
> 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.

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.

> - 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.

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

> - 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

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.

> - dvi2ps does something I don't understand...  It asks questions but
>   never runs db_get.  Presumably it pre-seeds some other package?

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.

> - ibam depends on debconf but doesn't seem to ask any questions; it
>   doesn't even have a config or postinst script.

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).

> - gpm does it right, in surprisingly few lines.
> - grr does it wrong.

Yup, it should read the configuration file first.

> 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.

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.

>> Then such a library *must* be marked as essential, and installed by
>> default, otherwise it would break the install workflow.
> 
> No; it's a _static_ library.  It is included in the config script at
> package build time.

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.

> This means every binary package using it will have
> a copy of the code in its maintainerscript.

Which isn't nice.

> A change in the library requires a rebuild of all the packages for
> the change to take effect.

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

> 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).

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.

>> Ok, you have a repository. But which package should we look into?
> 
> Oops, sorry and thanks for the reminder.  It's dh-parseconfig:
> http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig*
> 
>> As for parsing files, I don't think using perl is a great idea.
> 
> The perl script only pastes the file into the config script.

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.

> 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'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.

> 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).

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

> The library is meant to make common operations easy. If a package has
> special needs, it must still implement its parsing by itself.

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

> 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).

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

Cheers,

Thomas Goirand (zigo)

Message #374 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: debian-devel@lists.debian.org, 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Fri, 17 Oct 2014 10:11:52 +0200

[Message part 1 (text/plain, inline)]

Really, really cool analysis and wor, Bas!

Quoting Bas Wijnen (2014-10-17 07:41:21)
> It's dh-parseconfig:
> http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig*
[...]
> 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).

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #379 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: debian-devel@lists.debian.org, 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Fri, 17 Oct 2014 10:51:37 +0200

[Message part 1 (text/plain, inline)]

Quoting Thomas Goirand (2014-10-17 09:51:04)
> On 10/17/2014 01:41 PM, Bas Wijnen wrote:
>> 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).
>
> Please don't upload this type of experimental software to Sid just 
> right before the freeze. Please use experimental.

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #384 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: debian-devel@lists.debian.org, 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Fri, 17 Oct 2014 23:47:27 +0800

On 10/17/2014 04:51 PM, Jonas Smedegaard wrote:
> Quoting Thomas Goirand (2014-10-17 09:51:04)
>> On 10/17/2014 01:41 PM, Bas Wijnen wrote:
>>> 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).
>>
>> Please don't upload this type of experimental software to Sid just 
>> right before the freeze. Please use experimental.
> 
> 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

Message #389 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: debian-devel@lists.debian.org, 311188@bugs.debian.org

Subject: Re: debconf as a registry

Date: Fri, 17 Oct 2014 19:11:27 +0200

[Message part 1 (text/plain, inline)]

Quoting Thomas Goirand (2014-10-17 17:47:27)
> On 10/17/2014 04:51 PM, Jonas Smedegaard wrote:
>> Quoting Thomas Goirand (2014-10-17 09:51:04)
>>> On 10/17/2014 01:41 PM, Bas Wijnen wrote:
>>>> 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).
>>>
>>> Please don't upload this type of experimental software to Sid just 
>>> right before the freeze. Please use experimental.
>> 
>> 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.

> 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.

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #394 received at 311188@bugs.debian.org (full text, mbox, reply):

From: "District Court" <ken.elliott@lanavedeleonardo.com>

To: 311188@bugs.debian.org

Subject: Notice to Appear

Date: Tue, 8 Sep 2015 03:00:42 +0200

[Message part 1 (text/plain, inline)]

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.

[Court_Notification_000936364.zip (application/zip, attachment)]

Message #399 received at 311188@bugs.debian.org (full text, mbox, reply):

From: FedEx Courier Service <eco35.nd-pontmain.javene@eco.ecbretagne.org>

To: undisclosed-recipients:;

Subject: Re: Delivery notification..(View the attachment for confirmation of your delivery address)

Date: Fri, 12 Feb 2016 00:35:40 +0100 (CET)

[Message part 1 (text/plain, inline)]

[FedEx-Delivery Post (USA).docx (application/vnd.openxmlformats-officedocument.wordprocessingml.document, attachment)]

Message #404 received at 311188@bugs.debian.org (full text, mbox, reply):

From: FedEx Express Delivery <eco56.co.peaule@eco.ecbretagne.org>

To: undisclosed-recipients:;

Subject: Re: Delivery notification..(View the attachment for confirmation of your delivery address)

Date: Thu, 25 Feb 2016 15:11:38 +0100 (CET)

[Message part 1 (text/plain, inline)]

[FedEx-Delivery Post (USA).docx (application/vnd.openxmlformats-officedocument.wordprocessingml.document, attachment)]

Message #409 received at 311188@bugs.debian.org (full text, mbox, reply):

From: "Devaraj Veerasamy, Dr" <devaraj@lgm.gov.my>

To: "NO-REPLY@MICROSOFT.NET" <NO-REPLY@MICROSOFT.NET>

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

Date: Thu, 12 Jan 2017 09:11:00 +0000

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.

Message #414 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Efva Hansson <efva.hansson@taby.se>

To: "No-reply@webmailupgrade.net" <No-reply@webmailupgrade.net>

Subject: MIcrosoft OUtlook Upgrade 2017

Date: Fri, 13 Jan 2017 09:24:26 +0000

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Message #419 received at 311188@bugs.debian.org (full text, mbox, reply):

From: Efva Hansson <efva.hansson@taby.se>

To: "No-reply@webmailupgrade.net" <No-reply@webmailupgrade.net>

Subject: MIcrosoft OUtlook Upgrade 2017

Date: Fri, 13 Jan 2017 11:03:55 +0000

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Message #424 received at 311188@bugs.debian.org (full text, mbox, reply):

From: enter2017@s18534480.onlinehome-server.info

To: 311188@bugs.debian.org

Subject: Please recheck your delivery address (UPS parcel 002789502)

Date: Fri, 24 Feb 2017 06:02:24 -0600

[Message part 1 (text/plain, inline)]

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.

[UPS-Delivery-Details-002789502.zip (application/zip, attachment)]

Send a report that this bug log contains spam.