Re: Bug#189461: ITP: oilwar -- Defend your country from oil-thirsty invaders

[Jaldhar H. Vyas]

On Thu, 17 Apr 2003, keegan wrote:

> Evil army is attacking your country and tries to steal your oil. Your
> mission is to waste the invaders, protect the oil and save your mother
> land.
>
> Packages will be available soon.
>

Great game but I ran into a few problems you might want to pass on to the
upstream developers.

1.  An AI problem:  It's very hard to fight off the invaders when your own
elite units are shooting you in the back.

2.  The choice of weapons is too limited.  I found the rail gun and rocket
launcher, but where are the paper shredder, "violator of womens' honor",
and battery leads?

3.  When I tried to start up the game with the -un switch, nothing
happened.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Re: >2000 packages still waiting to enter testing, > 1500 over age

[Sven Luther]

On Thu, Apr 17, 2003 at 11:31:21PM +0200, Matthias Klose wrote:
> Anthony Towns writes:
> > Yes; you were. I'm focussing on gcc and perl and such things at the
> > moment, and as of yet no one else is really able to do anything about this
> > stuff while I'm busy; hopefully both those things will change soon enough.
> 
> and maybe python ...
> 
> AFAICS there are two issues:
> 
> - libxml2 on mips has a RC
> 
> - wxwindows2.4 (has one RC).
> 
> I didn't look at packages, on which other python modules are based on
> (i.e. postgres and gnome2). But this maybe the same issues for perl,
> if there are such module/extension packages.

And will the fact that postgresql provides binding for both python and
perl not imply that perl cannot enter testing unless python and
postgresql does also, and any permutation of them ?

Friendly,

Sven Luther

Re: >2000 packages still waiting to enter testing, > 1500 over age

[Sven Luther]

On Fri, Apr 18, 2003 at 06:11:16AM +1000, Anthony Towns wrote:
> On Thu, Apr 17, 2003 at 08:11:52PM +0200, Sven Luther wrote:
> > I CCed you the bugreport where i explain everything, but the packages are :
> >   libpgsql-ocaml
> >   ocamlsdl
> > These are the source packages.
> 
> You missed:
>   ocaml-core | 3.06.3 |  unstable | all
>   ocaml-libs | 3.06.3 |  unstable | all
>   meta-ocaml | 3.06.3 |  unstable | source
> 
> Since ocaml-libs apparently breaks, this needs to go too.

Yes, since ocaml-libs depends on ocamlsdl, or more exactly
libsdl-ocaml-dev. I suppose it depends on some libpgsql-ocaml also.

Maybe Stefano could upload a version to testing-proposed-updates that
drops the these two libraries. It should be ok, since meta-ocaml is an
arch: all package, and don't needs the autobuilders.

> > > The "upload to testing-proposed-updates" [...]
> > No, it would not work, because you need to build them either with
> > testing + bit of unstable [...]
> 
> Interesting point; but yes, I didn't mean that it was a useful thing for
> this particular example.

I still think that being able to do that would be real usefull. Imagine
the problems we had with libc6. It would be much easier for a random
package to be rebuilt against testing to go to testing-proposed-updates
and thus enter testing normally, without having to wait 6 month or so
for the new libc6 to be ready. It is clear that the maintainer of this
random package doesn't have the skill to significantly contribute to
fixing libc6, and there may be a need to immediately make something
enter testing, for security reasons or such. Many users where not aware
that testing was less secure than either woody or unstable during these
times, but then maybe it is a question of communication.

It needs to be done on a case by case basis though.

> > Also, i think that the testing scripts don't consider
> > testing-proposed-updates right now, do they ?
> 
> Like I said, they need to be specifically approved. Grep for "NEEDS
> APPROVAL BY RM" in update_excuses.

A, ok.

> > Yes, on a case per case basis, after agreement of all the involved
> > maintainers and the RM. It is just as you didn't respond to my mail, nor
> > did any of the ftp master act on my bug report, nor did anyone even
> > aknowledge it, i felt abandoned ...
> 
> Yes; you were. I'm focussing on gcc and perl and such things at the
> moment, and as of yet no one else is really able to do anything about this
> stuff while I'm busy; hopefully both those things will change soon enough.

:)))

Friendly,

Sven Luther

Re: Bug#189370: acknowledged by developer (irrelevant)

[Colin Walters]

On Fri, 2003-04-18 at 00:08, Atsuhito Kohda wrote:

> Of course I can understand that it is possible to destroy
> local changes as I wrote in a former email.

Ok, well, policy is quite clear this isn't allowed.

But let me say first that this is not to belittle your work on tetex;
I'm very glad you're working on it.

> It breaks Policy to some extent but follows it to some
> extent, IMHO.
> 
> Former tetex packages provided language.dat as a
> conffile so if one changed (manually!) it then one would 
> be asked whether to replace it or not everytime at upgrading.
> 
> I changed it a configuration file which would be generated
> in postints (of tetex-base) and adopted debconf so that
> a user can select to modify it or not with debconf.

But the dpkg prompt was there for a reason; to preserve user changes.

Your change may seem like an improvement, and in some ways it is.  But
again, using Debconf is not a license to overwrite the file.

> > It does break policy.  There is no question.  And I think policy is
> > correct.  If you don't think it is, the right way to solve the problem
> > is to discuss the issue here on -devel.
> 
> I guess it depends on how to read Policy, in a sense.

"
11.7.3. Behavior


  Configuration file handling must conform to the following behavior:
* local changes must be preserved during a package upgrade [...]"

Seems quite clear to me.  After that is a discussion about how to do
things correctly.

> For example, updmap was once a conffile and was in
> /etc/texmf/dvips but the current teTeX upstream (so tetex
> packages of Debian also) changed it completely and now
> updmap is a normal script (in /usr/bin) and read configuration 
> file /etc/texmf/updmap.cfg, that is, former updmap was
> splitted into updmap and updmap.cfg.  Further its format
> of configuration was changed completely.

I'm not sure how this updmap thing relates to what we're talking about. 

> Perhaps our handling at present will be not *perfectly*
> compliant with Policy (I think it is compliant with Policy but,
> at least, there are some who think not) but is there *perfect* 
> way to handle this?

Yes, there is.  See below:

> Though I didn't check this yet but if I (or some other tetex 
> members) can understand it and find it useful for us then
> tetex packages will adopt it but if not (and if the current
> handling really breaks Policy), is it the only way to get
> back to the former scheme?

Well, it seems you're really not convinced Policy is being violated
here.  That's understandable I guess.  I am hoping other people here
will weigh in with their opinion.

Any policy editors?

> I have an impression that such Policy understanding prevents 
> sane advance of packages.

Well, the solution might be to change policy.  In the interim, I think
my fontconfig approach is fairly good (although it certainly could be
improved).  That's why this thread is being CC'd to -devel, so we can
come to a consensus about this issue.  

Having some packages prompt for "manage with debconf" all in different
ways and with different warnings in the config files and different
defaults is most definitely a bad thing.

Re: Bug#189347: stop the "manage with debconf" madness

[Emile van Bergen]

Hi,

On Thu, Apr 17, 2003 at 09:45:54AM -0700, Craig Dickson wrote:

> Andrew Suffield wrote:
> 
> > On Thu, Apr 17, 2003 at 12:47:38PM +0200, Mike Hommey wrote:
> > > On Thursday 17 April 2003 02:32, Colin Walters wrote:
> > > > On Wed, 2003-04-16 at 20:21, Chris Hanson wrote:
> > > > > I'd rather fix this properly; what you suggest is a workaround.  What
> > > > > I consider a proper fix is to redefine the configuration files so that
> > > > > they can be parsed.  I have learned, the hard way, that using shell
> > > > > scripts for configuration files is a bad idea.
> > > >
> > > > That's true, it's definitely a workaround.  The way I did it in
> > > > fontconfig is the way I think it should be done in packages which can't
> > > > (or can't easily) losslessly parse their configuration files.
> > > 
> > > OTOH, xml config files (like fontconfig's config) could be losslessly 
> > > parsed 
> > > through xslt processing...
> > 
> > Much like any other config file can be losslessly parsed by processing
> > them. That's not really very helpful.
> 
> Yes, but with a standard format such as XML, you don't have to write
> your own code to parse or generate them.
> 
> On the other hand, I don't think we really want package configuration
> scripts to require XML tools, do we?

Please, no.

In most cases, the only feature that's used (and needed) of XML that it
stores a tree of attribute/value pairs.

Given limited effort, I am absolutely convinced that it should be
possible to come up with a more robust, well defined, simple(!), user
and implementor-friendly(!), do-one-thing-and-do-it-well way of doing
that.

Not by starting from "we've got HTML which is being (ab)used for ad-hoc
RPC purposes, let's make a more general SGML application to do that"
which became XML, but starting from the simple requirement stated above:
storing and transmitting nested trees of attribute/value pairs with a
*limited* number of possible data types. 

That means *most definitely not* including a programming language to
create all kinds of funky new types, like you have with ASN.1 or the
DTDs. If the data types offered are not suitable for your application,
there's always octet-string; at least that's my humble opinion. If 5% of
the values in a configuration tree remain opaque data, we've already
gained 95%; right now configuration files are so brittle and hard to
edit losslessly that a lot of them must be treated as fully opaque.

Definition should be done like you'd treat a network protocol, with a
healty dose of "be conservative in what you write, be liberal in what
you read", to paraphrase the great J. Postel, as it /will/ be a
protocol, spoken between package configuration scripts and packages.

Anybody interested in such an effort? I've got a few ideas for this, but
if people feel the current way of doing things is "good enough", then I
won't bother you guys with another idea lacking implementation.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen   [EMAIL PROTECTED]  
tel. +31 (0)70 3906153   http://www.e-advies.nl


pgppmeJQAgvzB.pgp
Description: PGP signature

Bug#189477: ITP: twisted-web -- Twisted Web Server

[Moshe Zadka]

Package: wnpp
Version: N/A; reported 2003-04-18
Severity: wishlist

Package name: twisted-web
Version: 0.23
Upstream Author: Moshe Zadka <[EMAIL PROTECTED]>
URL: http://twistedmatrix.com/users/moshez/apt/
License: LGPL
Description: Twisted Web Server
 The necessary configuration files and harness to use the Twisted asynchronous
 network framework to serve HTTP. Supports named virtual hosting, CGI
 and serving user content, including a secure way for users to handle dynamic
 web pages in their personal directory.

-- 
Moshe Zadka -- http://moshez.org/
Buffy: I don't like you hanging out with someone that... short.
Riley: Yeah, a lot of young people nowadays are experimenting with shortness.
Agile Programming Language -- http://www.python.org/

Re: Managing bug reports

[Jesus Climent]

On Thu, Apr 17, 2003 at 11:50:27PM +0200, Matthias Urlichs wrote:
> 
> On the gripping hand, there's gcj. Now if the day only had more weeks in it...

Or the hour had more days on it...

mooch

-- 
Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69
--
 Registered Linux user #66350 proudly using Debian Sid & Linux 2.4.20

- ... todos necesitamos creer en algo.
- Si, yo también creo... Creo... que me voy a tomar una cerveza.
--Sor Trini (Año Mariano)

Re: Bug#189370: acknowledged by developer (irrelevant)

[Mark Brown]

On Fri, Apr 18, 2003 at 01:08:28PM +0900, Atsuhito Kohda wrote:

> Former tetex packages provided language.dat as a
> conffile so if one changed (manually!) it then one would 
> be asked whether to replace it or not everytime at upgrading.

Does this file really change so often that this is a problem?  Users
will only be prompted if the distributed version of a conffile has
changed.

As far as I remember the major problem with the conffile handling in
tetex was texmf.cnf which appeared to not only change regularly but also
be automatically edited by the package install scripts without user
intervention.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgp8NyWugelfg.pgp
Description: PGP signature

Re: Bug#189461: ITP: oilwar -- Defend your country from oil-thirsty invaders

[Jarno Elonen]

> Evil army is attacking your country and tries to steal your oil. Your
> mission is to waste the invaders, protect the oil and save your mother
> land.

I'm not quite sure if you these joke games of current interest really deserve 
to go in the repository.. They usually have no playability nor any other 
entertainment value once the gag is outdated. This one seems to be no 
exception.

- Jarno

Bug#189488: ITP: starvoyager -- 2D space arcade game, themed around 'Star Trek'

[Idan Sofer]

Package: wnpp
Version: unavailable; reported 2003-04-18
Severity: wishlist

* Package name: starvoyager
  Version : 0.4.4
  Upstream Author : Richard Thrippleton <[EMAIL PROTECTED]>
* URL : http://www.srcf.ucam.org/~ret28
* License : BSD with fractions of LGPL code
  Description : 2D space arcade game, themed around 'Star Trek'

Star Voyager is a Frontier/Elite class game in a more arcade style 2D
environment, themed to the 'Star Trek' universe. It utilises the SDL library
for portability, hence it should definitely run on all Linux platforms, and
hopefully all *nixes supported by SDL.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux tuxbox 2.4.20 #1 Fri Dec 27 23:03:40 IST 2002 i686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set)

Re: Managing bug reports

[Mark Howard]

On Thu, 2003-04-17 at 22:03, Jérôme Marant wrote:
> Mark Howard <[EMAIL PROTECTED]> writes:
> 
> > Hi,
> >   version 0.7 of debbuggtk is now in the Debian repository. This is a
> > set of tools (bugwatcher, bugviewer and buglister) to help manage Debian
> > bug reports. This is useful because:
> 
> Err, it requires some non-free software, jre 1.4 that is. Too bad.

Hopefully only as a temporary measure. 

I had been using kaffe until recent multi threaded changes. The latest
cvs of kaffe may even work now; unfortunately it's not packaged yet.
As I said in the original email, I have also been in contact with
sablevm developers regarding this - they have been very friendly and
seem keen on helping.
I've just tried gij again. It works but suffers seemingly random
crashes. Help by people who know more about gij would be appreciated.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: Bug#189370: acknowledged by developer (irrelevant)

[Atsuhito Kohda]

From: Mark Brown <[EMAIL PROTECTED]>
Subject: Re: Bug#189370: acknowledged by developer (irrelevant)
Date: Fri, 18 Apr 2003 09:14:40 +0100

> On Fri, Apr 18, 2003 at 01:08:28PM +0900, Atsuhito Kohda wrote:
> 
> > Former tetex packages provided language.dat as a
> > conffile so if one changed (manually!) it then one would 
> > be asked whether to replace it or not everytime at upgrading.
> 
> Does this file really change so often that this is a problem?  Users
> will only be prompted if the distributed version of a conffile has
> changed.

It is not problem how often language.dat changes but 
that if it was changed once then users will be prompted
everytime at upgrading.

And I suspect that for users in europe it is not rare to
add extra hyphenation pattern, at least.

> As far as I remember the major problem with the conffile handling in
> tetex was texmf.cnf which appeared to not only change regularly but also
> be automatically edited by the package install scripts without user
> intervention.

Okay, if you can provide us the way to handle texmf.cnf
(central configuration file for all TeX related packages)
which can work well with jadetex, xmltex, ptex, jtex,
dvipsk-ja etc. please let me know.

Note users can add local modification freely with the
current method, please read README.Debian.

Thanks, 2003-4-18(Fri)

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Tokushima Univ.

Re: Managing bug reports

[Mark Howard]

On Fri, 2003-04-18 at 08:39, Arnaud Vandyck wrote:
> Is it possible:
> 1) to depend to j2sdk1.3 | j2sdk:1.4 (I do not have the 1.4 on my ppc)
I've not tested with 1.3, so depended on 1.4. I can't think of any
problems, so will make the change. Hopefully we will change to a free
jvm soon.

> 2) to have the java-gnome compiled for ppc? I cannot do this because
>of dependencies prolblems...

This actually applies to all architectures...
I sent a request to the powerpc list a while ago asking for help but had
no response. 
In the past, java-gnome was in contrib and the buildd maintainers
stopped its builds as they would always fail with missing dependencies.
java-gnome has moved to main recently and the dependencies have been
removed - it should now compile on buildd machines. It just needs
somebody to reenable them. I've not found out who or how.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: Bug#189332: flex: unput(char) not valid outside body of grammar

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 00:50:08 -0700 (PDT),
>> Paul Eggert <[EMAIL PROTECTED]> said: 

 > This email is following up to a Debian bug report about flex
 >> http://bugs.debian.org/189332>, which reports that flex test
 >> http://bugs.debian.org/189332>version
 > 2.5.31 breaks Bison 1.875.

 >> From: Manoj Srivastava <[EMAIL PROTECTED]> Date: Date: Wed, 16
 >> Apr 2003 17:40:13 -0500

 > This change means that flex no longer conforms to POSIX
 > 1003.1-2001.  The POSIX specification for lex
 >> http://www.opengroup.org/onlinepubs/007904975/utilities/lex.html>
 > says that the functions yylex, yymore, yyless, input, and unput are
 > all accessible to user code included in the lex input.  As far as I
 > can tell, POSIX imposes no restriction that the functions are
 > accessible only to user actions.

 > The change to flex may be necessary for reentrant scanners, but it
 > shouldn't be necessary for traditional scanners such as those
 > specified by POSIX.

Indeed. The full POSIX references are:
 ISO/IEX 9945-2: 1993(3)   Information Technology -- POSIX
 IEEE Std 1003.2-1992  Part 2: Shell and Utilities
  A.2.7.5 lex Actions

It also says that it is unspecified whether the functions or
 macros appear in the C code output of lex, or are accessible only
 through the -l l operand og the c compiler. 


I have, however, noticed something bizarre: adding a %nounput
 options defines unput, but never undefines it, this seems like a bug
 somewhere. 
--
%{
/* A template scanner file to build "scanner.c". */
#include 
#include 
#include "config.h"
/*#include "parser.h" */

static void f(const char *x);

%}

%option 8bit outfile="scanner.c" prefix="test"
%option nomain noyywrap nounput
%option warn

%%
%{
 void f(const char *x) { unput(*x); }
%}

[0-9]  { unput('?'); }
[a-z]  { f("?"); }

Re: Bug#189370: acknowledged by developer (irrelevant)

[Manoj Srivastava]

>> On 18 Apr 2003 03:23:44 -0400,
>> Colin Walters <[EMAIL PROTECTED]> said: 

 > On Fri, 2003-04-18 at 00:08, Atsuhito Kohda wrote:
 >> Of course I can understand that it is possible to destroy local
 >> changes as I wrote in a former email.

 > Ok, well, policy is quite clear this isn't allowed.

I tend to agree. I evben filed a grave bug about it, which was
 promptly closed, and at that time I did not have the time to get into
 a prolonged debate. 

 >> Though I didn't check this yet but if I (or some other tetex
 >> members) can understand it and find it useful for us then tetex
 >> packages will adopt it but if not (and if the current handling
 >> really breaks Policy), is it the only way to get back to the
 >> former scheme?

 > Well, it seems you're really not convinced Policy is being violated
 > here.  That's understandable I guess.  I am hoping other people
 > here will weigh in with their opinion.

 > Any policy editors?

I don't know if policy editors carry any special weight here,
 but I think this is indeed a violation of policy, and worse, of an
 expectation that we have encouraged users to have that their changes
 to files under /etc shall not be blown away. 

 >> I have an impression that such Policy understanding prevents sane
 >> advance of packages.

I am sorry, I do think that not preserving user changes is not
 an advancement.

 > Well, the solution might be to change policy.  In the interim, I
 > think my fontconfig approach is fairly good (although it certainly
 > could be improved).  That's why this thread is being CC'd to
 > -devel, so we can come to a consensus about this issue.

 > Having some packages prompt for "manage with debconf" all in
 > different ways and with different warnings in the config files and
 > different defaults is most definitely a bad thing.

My as yet incomplete mechanism is to use debconf andother
 means to generate a current configuration file on the fly, and use
 ucf to prompt, somewhat like dpkg, as below:
--
Configuration file \`$dest_file'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
3 or T  : show a thre way difference between current, older,
  and new versions of the file
  M : Do a 3 way merge between current, older,
  and new versions of the file [Very Experimental]
  Z : start a new shell to examine the situation
 The default action is to keep your current version.
--

Note the options to merge maintainer changes into the locally
 modified configuration file. Use 3 or T to view the merged file, and
 use M to ask the maintainer changes to be merged in. 

I am attaching the man page of ucf as a shameless plug.

manoj



ucf.1
Description: ucf.1

-- 
"In matters of principle, stand like a rock; in matters of taste, swim
with the current." Thomas Jefferson
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#189370: acknowledged by developer (irrelevant)

[Colin Watson]

On Fri, Apr 18, 2003 at 06:07:28PM +0900, Atsuhito Kohda wrote:
> From: Mark Brown <[EMAIL PROTECTED]>
> > On Fri, Apr 18, 2003 at 01:08:28PM +0900, Atsuhito Kohda wrote:
> > > Former tetex packages provided language.dat as a
> > > conffile so if one changed (manually!) it then one would 
> > > be asked whether to replace it or not everytime at upgrading.
> > 
> > Does this file really change so often that this is a problem?  Users
> > will only be prompted if the distributed version of a conffile has
> > changed.
> 
> It is not problem how often language.dat changes but 
> that if it was changed once then users will be prompted
> everytime at upgrading.

Users will only be prompted when both of these conditions hold:

  * they have changed the file locally

  * the file has changed in the package since the last version they had
installed

They will not be prompted if they have changed the file but the version
in the package remains unchanged.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug#189332: flex: unput(char) not valid outside body of grammar

[Paul Eggert]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

>  [POSIX] also says that it is unspecified whether the functions or
>  macros appear in the C code output of lex, or are accessible only
>  through the -l l operand of the c compiler. 

Yes.  This means that if Bison were trying to be portable to all lex
variants, Bison would have to link itself with -ll for the lex
variants that define unput etc. in the lex library.  Bison assumes
flex, though, so it doesn't have to worry about that possibility.

One other problem I've observed is that flex 2.5.31 defines
yylex_destroy even if the application doesn't need yylex_destroy.
There is no %option noyylex_destroy.


>  the modification I provided was tested, and it did not
>  call yyunput before it was declared (the trick is to place the
>  functions in the _rules_ section in %{ %} stanzas. 

That modification relies on nested functions, which is not portable.
Bison is supposed to be portable to any ANSI C compiler, so it can't
use that technique.

Re: >2000 packages still waiting to enter testing, > 1500 over age

[Stefano Zacchiroli]

On Fri, Apr 18, 2003 at 07:56:12AM +0200, Sven Luther wrote:
> Maybe Stefano could upload a version to testing-proposed-updates that
> drops the these two libraries. It should be ok, since meta-ocaml is an
> arch: all package, and don't needs the autobuilders.

Done: meta-ocaml 3.06.1testing

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney


pgp4pWRbkFqPV.pgp
Description: PGP signature

Re: Bug#189370: acknowledged by developer (irrelevant)

[Mark Brown]

On Fri, Apr 18, 2003 at 06:07:28PM +0900, Atsuhito Kohda wrote:
> From: Mark Brown <[EMAIL PROTECTED]>

> > Does this file really change so often that this is a problem?  Users
> > will only be prompted if the distributed version of a conffile has
> > changed.

> It is not problem how often language.dat changes but 
> that if it was changed once then users will be prompted
> everytime at upgrading.

As Colin says, this is not the case - users will only be prompted when
the distributed file changes (which is why I was asking how often that
happens).

> And I suspect that for users in europe it is not rare to
> add extra hyphenation pattern, at least.

Hmm, yes - especially since many of the European hyphenation patterns
are disbled by default.

> > As far as I remember the major problem with the conffile handling in
> > tetex was texmf.cnf which appeared to not only change regularly but also
> > be automatically edited by the package install scripts without user
> > intervention.

> Okay, if you can provide us the way to handle texmf.cnf
> (central configuration file for all TeX related packages)
> which can work well with jadetex, xmltex, ptex, jtex,
> dvipsk-ja etc. please let me know.

Sorry, I wasn't clear.  The current handling of texmf.cnf looks
reasonably sane to me - it's now not too dissimilar to how
/etc/modules.conf is handled.  What I was trying to say was that in the
past there were problems with the handling of some configuration files
in the tetex packages but that languages.dat hadn't really registered as
one that needed special treatment.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgpMYruMUZY2K.pgp
Description: PGP signature

Bug#189496: ITP: tuxmathscrable -- Tux Math Scrab*le is math version of the popular board game for ages 4-40.

[Mathias Gygax]

Package: wnpp
Version: unavailable; reported 2003-04-18
Severity: wishlist


* Package name: tuxmathscrable
  Version : 2.1
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.asymptopia.com/
* License : GPL
  Description : Tux Math Scrab*le is math version of the popular board game 
for ages 4-40.

Tux Math Scrab*le is a math version of the popular board game for
ages 4-40, which is highly entertaining as well as great educational
value. The game challenges young people to construct compound equations
and consider multiple abstract possibilities. There are three skill-levels
for practice from basic addition and subtraction through to multiplication
and division. 

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux zeus 2.4.20-evms-lsm-freeswan-ipvs-debianlogo #1 Mit Jan 15 
14:23:31 CET 2003 i686
Locale: LANG=de_CH, [EMAIL PROTECTED] (ignored: LC_ALL set)

Re: Bug#189370: acknowledged by developer (irrelevant)

[Bernd Eckenfels]

On Fri, Apr 18, 2003 at 01:08:28PM +0900, Atsuhito Kohda wrote:
> Former tetex packages provided language.dat as a
> conffile so if one changed (manually!) it then one would 
> be asked whether to replace it or not everytime at upgrading.

IMHO it should only ask if the file has changed upstream. I know this does
not always work, but this is still the way dpkg should handle it.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Work-needing packages report for Apr 11, 2003

[Nick Phillips]

On Sat, Apr 12, 2003 at 04:28:40PM +0100, Darren Salt wrote:

> [snip]
> > For instance, what are some good replacements for magicfilter?
> 
> apsfilter seems to work well.

Not For Me. Every time I've tried it it's been utter crap.
Magicfilter, OTOH, Just Works.


Just in case anyone out there was hovering on the verge of adopting
magicfilter... you know you want to ;)



Cheers,



Nick

-- 
Nick Phillips -- [EMAIL PROTECTED]
Do not sleep in a eucalyptus tree tonight.

Re: PostgreSQL admin tools (Was: Upcoming removal of orphaned packages)

[Steve Greenland]

On 16-Apr-03, 19:23 (CDT), Brian May <[EMAIL PROTECTED]> wrote: 
> On Tue, Apr 15, 2003 at 07:51:59PM -0300, Andre Luis Lopes wrote:
> > [EMAIL PROTECTED]:~$ apt-cache show rhdb-admin
> > Package: rhdb-admin
> 
> What is wrong here?
> 
> > rhdb-admin   
> > echo $?
> 1
> 
> I assume it is meant to do more then just emulate the false
> command? ;-)

It's a (reported) bug in the libpgtcl package:

/usr/lib/libtclpg.so is linked to ../postgresql/lib/libtclpg.so instead
of postgresql/lib/libtclpg.so. Fix the link, and it will work.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: stop the "manage with debconf" madness

[Steve Greenland]

On 16-Apr-03, 18:08 (CDT), Colin Walters <[EMAIL PROTECTED]> wrote: 
> Debconf is NOT a license to overwrite user's configurations!  

You've correctly identified the problem.

> I propose a different solution to this problem, which conforms much more
> with policy, while still allowing debconf to be used as much as
> possible.

But that's not the solution.

Debconf is *NOT* a general purpose configuration tool. Debconf is
*ONLY* a standardized way of interacting with the user during package
installation, for configuration values that *CANNOT* be reasonably
defaulted.

That's it. Any other use is a clear violation of Debian configuration
file policy. In particular, using debconf to modify existing
configuration files, whether conffiles or not, is wrong. I'd allow an
exception for "dpkg-reconfigure", since this is clear that the admin is
deliberately asking for it.

Steve, extremely disappointed about how chatty package installation has
become.

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: Bug#189370: acknowledged by developer (irrelevant)

[Atsuhito Kohda]

From: Mark Brown <[EMAIL PROTECTED]>
Subject: Re: Bug#189370: acknowledged by developer (irrelevant)
Date: Fri, 18 Apr 2003 12:09:38 +0100

> On Fri, Apr 18, 2003 at 06:07:28PM +0900, Atsuhito Kohda wrote:
> > From: Mark Brown <[EMAIL PROTECTED]>
> 
> > > Does this file really change so often that this is a problem?  Users
> > > will only be prompted if the distributed version of a conffile has
> > > changed.
> 
> > It is not problem how often language.dat changes but 
> > that if it was changed once then users will be prompted
> > everytime at upgrading.
> 
> As Colin says, this is not the case - users will only be prompted when
> the distributed file changes (which is why I was asking how often that
> happens).

Okay, I misunderstood a bit on this point, but I pointed
out that language.dat was changed between woody/sarge and 
sid at least.

> > And I suspect that for users in europe it is not rare to
> > add extra hyphenation pattern, at least.
> 
> Hmm, yes - especially since many of the European hyphenation patterns
> are disbled by default.

Once I overlooked british hyphenation pattern in the list
then I got a bug report soon.  cf. bug #183481

> /etc/modules.conf is handled.  What I was trying to say was that in the
> past there were problems with the handling of some configuration files
> in the tetex packages but that languages.dat hadn't really registered as
> one that needed special treatment.

It might be enough to say; please see bug #62271
(though its main issue was of language.def).

Thanks,2003-4-19(Sat)

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Tokushima Univ.

Re: Bug#189370: acknowledged by developer (irrelevant)

[Atsuhito Kohda]

From: Manoj Srivastava <[EMAIL PROTECTED]>
Subject: Re: Bug#189370: acknowledged by developer (irrelevant)
Date: Fri, 18 Apr 2003 04:21:17 -0500

>  >> I have an impression that such Policy understanding prevents sane
>  >> advance of packages.
> 
>   I am sorry, I do think that not preserving user changes is not
>  an advancement.

I said to you once before but the new mechanism preserves 
user change much clearly than the former one within the
new mechanism.  It could lost user change only at transition
from the old mechanism (conffile) to the new mechanism (configuration
file).

>   My as yet incomplete mechanism is to use debconf andother
>  means to generate a current configuration file on the fly, and use
>  ucf to prompt, somewhat like dpkg, as below:
> --
> Configuration file \`$dest_file'
>  ==> File on system created by you or by a script.
>  ==> File also in package provided by package maintainer.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
> 3 or T  : show a thre way difference between current, older,
>   and new versions of the file
>   M : Do a 3 way merge between current, older,
>   and new versions of the file [Very Experimental]
>   Z : start a new shell to examine the situation
>  The default action is to keep your current version.
> --

This doesn't work for texmf.cnf which also I told you
once before.  If the default is to keep your current
version then many TeX related packages should fail to
install.

The current mechanism is, at least at present, only one
solution which provides sufficiently flexible handling
and also preserves user changes.

Thanks, 2003-4-19(Sat)

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Tokushima Univ.

Re: libc6 (security) update does not restart system-services?

[Markus Amersdorfer]

On Fri, 18 Apr 2003 13:06:07 +0900
GOTO Masanori <[EMAIL PROTECTED]> wrote:

Hi!

> > I've recently upgraded my Woody-Servers according to the latest
> > libc6 security update (DSA-282), and it seems that services were
> > _not_ reloaded by the post-install-script!?
> > 
> > [...]
> > 
> > - /var/lib/dpkg/info/libc6.postinst checks for "$1" ==
> >   "configure"
> >   (which is the case when updating, isn't it?). If true it
> >   afterwards checks if "$2" is lower than "2.1.95-1" (I assume this
> >   corresponds to the previously installed version) and _only if this
> >   the case_ it restarts most of the services.
> > 
> > Woody comes with libc6 2.2.5-11.5, so the section about restarting
> > services is never reached.
> > 
> > This leaves the machine vulnerable as all services use the old
> > library until restarted.
> >
> > Shouldn't the services be restarted when installing a new
> > libc-version? What reasons would there be not to restart services?
> 
> Restarting services is needed only once: upgrading from 2.2.x to
> 2.3.x.  The reason is simple.  NSS (Name Service Switch) is much
> changed, and it becomes incompatible between 2.2 and 2.3.
> 
> So if you use woody server, not sarge, then you have no need to
> restart services.  If you use libc6 2.2.x, it's not related.

So restarting services is necessary when upgrading from 2.2.x to 2.3.x
to make sure everything works fine (as e.g. the example of xdm you
mention below). When staying with basically the same version and
"simply" doing a security-update, there are no compatability-problems,
of course, so everything keeps running smoothly.

But my concern is that running programs such as system services use the
old libraries instead of the new one as long as they continue running,
don't they? If they do the security bug is still exploitable though the
new libraries are already installed on the system.

> > If everything _is_ designed not to restart the services, I suppose
> > telling the users to take care of that theirselves would be a good
> > idea for example using a simple "echo" in the post-install script
> > (or similar).
> 
> The restarting message is not sufficient for you?

Of course, but the message is only shown if the services _are_ to be
restarted (which is only when doing a major version update). 
Services are not restarted by the security update though I think they
should be (as stated above).

If I'm wrong, please correct me. :)

> BTW, I plan to dupload 2.3.1-17 that has preinst message to choose
> libc6 upgrade or not.  It's needed because for example xdm cannot
> authenticate after installing libc6, but we cannot restart xdm with
> postinst automatically (user's X11 session is destroyed).  I add
> messages in next 2.3.1-17 as they have to restart xdm with their hand.
> If you have requests about restarting messages, please tell me.

Though I don't know enough about the detailed processes running inside
the library packages: Sounds great. :)
Perhaps it's possible to delay installation of the libraries until the
next reboot? The user would have the chance to have the libraries
installed "instantly" (which would break xdm), "automatically at the
next reboot" (is that what you meant above?) or "not at all" at the
moment (though I currently can't think of a good reason why to do that).

Cheers,
Max

-- 
The first time any man's freedom is trodden on, we're all damaged.
   

http://homex.subnet.at/~max/

why do we care about configuration files?

[Colin Walters]

On Thu, 2003-04-17 at 21:56, Colin Walters wrote:

> Debian has a long, hard-earned reputation for doing things "right".  We
> shouldn't toss that out the window in a mass of "manage /etc/foo.conf?"
> with debconf prompts.

Perhaps I've been overly strong with the rhetoric.  Let me give two
realistic scenarios where this "manage foo with debconf?" fails.
 
1) Hardcore Unix guy
   This person installed Debian because (among other reasons) he heard it 
   didn't force him to use "wimpy tools" to configure his system.   Hardcore 
   Unix guy likes to edit configuration files.  He doesn't like using 
   "redhat-config-network" or whatever.  Now he installs Debian, and gets the 
   first Debconf prompt about setting his debconf level.  He recoils, but then 
   notices that he can set it to "noninteractive".  There, now he won't ever 
   have to have be asked inane questions; he can just edit the configuration 
   files and be happy.  He gives Debian the benefit of the doubt on this.

Now, Hardcore Unix guy's needs should be especially important to us as a
project, because he happens to account for a relatively significant
fraction of our developer base (in my experience), as well as our user
base.  Hopefully the problem in the above scenario is obvious: Hardcore
Unix guy will have, unwittingly, agreed that some of his configuration
files in /etc/ can be overwritten.  He has no idea which ones.  He has
no simple, consistent way to stop it, or to change the default. 
However, he might not know this, and he might edit
/etc/texmf/language.dat or whatever.  Then on his next upgrade, it's
gone.  No warning.  Nothing.  Hardcore Unix guy says "screw this Debian
crap, it's just like SuSE"[1].

2) Semi-experienced Newbie
   This person doesn't know very much about GNU/Linux, but he heard this Debian
   thing has some advantages over other systems, so he thought he'd try it.  He
   has a friend who knows a lot about Red Hat help him set things up, and it
   mostly works.  He and his friend kept the default Debconf priority of 
   "critical".  Then later, he decides he needs to write a paper, and so he 
   calls his friend, who tells him to install a package named "tex".  He finds
   tetex-bin, and installs it.  Now, the hyphenation pattern is wrong, so he
   calls his friend again, who tells him to add a certain line at some magic
   place in /etc/texmf/language.dat.  He does that, not knowing anything at all
   about how the file works.

We need to support this kind of person and this kind of usage. In fact, 
Semi-experienced Newbie is exactly the kind of person I'm trying to have Debian 
support more with Debian Desktop.  Again, the problem here should be clear; on
upgrade, Semi-experienced Newbie's hyphenation fixes will mysteriously stop 
working.  He will have completely forgotten about those one or two mysterious
lines he added to some configuration file way back when.

There's other use cases too, but if we're not supporting the two big ones above,
we have completely failed.  I hope this makes things clearer.  There *is* a 
problem, and we need to fix it.

Incidentally, I should say here that this whole problem has almost nothing to do
with Debconf, really.  Debconf just happens to be the most popular way to ask
for permission to preempt people's configuration files.

[1] Not to bash SuSE, because I really don't know anything about it.  I've just
heard that it's particularly bad at this configuration file thing.

Re: stop the "manage with debconf" madness

[Steve Langasek]

On Fri, Apr 18, 2003 at 09:28:07AM -0500, Steve Greenland wrote:
> On 16-Apr-03, 18:08 (CDT), Colin Walters <[EMAIL PROTECTED]> wrote: 
> > Debconf is NOT a license to overwrite user's configurations!  

> You've correctly identified the problem.

> > I propose a different solution to this problem, which conforms much more
> > with policy, while still allowing debconf to be used as much as
> > possible.

> But that's not the solution.

> Debconf is *NOT* a general purpose configuration tool. Debconf is
> *ONLY* a standardized way of interacting with the user during package
> installation, for configuration values that *CANNOT* be reasonably
> defaulted.

If the package maintainers are correctly using the debconf priorities,
and the admin has chosen a debconf priority that accurately reflects
their preferences, why do you care?  By definition, any prompts at
priority medium or lower have reasonable defaults, so unless they're
shown to the admin *at his choice*, and the admin actively *chooses* a
non-default value, the configuration file won't be changed anyway.

Now, if there are questions being asked at priority high or higher that
have reasonable defaults, those are bugs.  I've had a few of these
myself, but no worries -- file and fix, and move on.  OTOH, if you're
running debconf with a priority preference of medium or lower... RTFM.

> That's it. Any other use is a clear violation of Debian configuration
> file policy. In particular, using debconf to modify existing
> configuration files, whether conffiles or not, is wrong.

This claim is not reflected in our actual policy.  It's perfectly valid
for a maintainer script to make changes to non-conffile config file in
response to a user's expression of assent.

-- 
Steve Langasek
postmodern programmer


pgp8OcZLMODzY.pgp
Description: PGP signature

Re: Bug#189370: acknowledged by developer (irrelevant)

[Steve Langasek]

On Fri, Apr 18, 2003 at 03:23:44AM -0400, Colin Walters wrote:

> > It breaks Policy to some extent but follows it to some
> > extent, IMHO.

> > Former tetex packages provided language.dat as a
> > conffile so if one changed (manually!) it then one would 
> > be asked whether to replace it or not everytime at upgrading.

> > I changed it a configuration file which would be generated
> > in postints (of tetex-base) and adopted debconf so that
> > a user can select to modify it or not with debconf.

> But the dpkg prompt was there for a reason; to preserve user changes.

> Your change may seem like an improvement, and in some ways it is.  But
> again, using Debconf is not a license to overwrite the file.

> > Though I didn't check this yet but if I (or some other tetex 
> > members) can understand it and find it useful for us then
> > tetex packages will adopt it but if not (and if the current
> > handling really breaks Policy), is it the only way to get
> > back to the former scheme?

> Well, it seems you're really not convinced Policy is being violated
> here.  That's understandable I guess.  I am hoping other people here
> will weigh in with their opinion.

There should be no room for misunderstanding here:  if you are using
debconf to ask the user's permission to modify a file, it means you're
doing something not allowed by policy to begin with.  Asking before you
violate does not make it ok!  (And if you're not violating policy, why
ask?)

Debian's conffile handling is at the very edge of what Policy allows: it
gives the user the option of overwriting their local changes, *and*
gives them the opportunity to see what these changes are *first*.
Nothing less than this is sufficient; certainly, a one-time blanket
question of "can I trash stuff?" is not acceptable.

-- 
Steve Langasek
postmodern programmer


pgp0FoRyidzCR.pgp
Description: PGP signature

Re: stop the "manage with debconf" madness

[Colin Walters]

On Fri, 2003-04-18 at 10:28, Steve Greenland wrote:

> > I propose a different solution to this problem, which conforms much more
> > with policy, while still allowing debconf to be used as much as
> > possible.
> 
> But that's not the solution.

Yep, I agree completely.  So let's talk about solutions.  One might be
to create a third class of configuration files; let's call them "managed
configuration files".

Now, managed configfiles can either be conffiles (i.e. included in the
package) or configuration files.  The key difference is that the admin
has full, standardized control over how packages can overwrite these
files.  For example, we'd have files /etc/conffiles/managed and
/etc/conffiles/unmanaged.  

The /etc/conffiles/managed file would itself be a conffile that would
list which configuration files a package can freely overwrite.  If the
configuration file is a conffile, then dpkg will never prompt even if
the file is locally modified; it will just replace it.  If it's a
configuration file, then the package is free to overwrite any changes in
its postinst.  I know for sure on my system I'd put all the X keymaps
and TeX stuff in here.  (Hm, we should probably support globs in this
file).

Likewise, /etc/conffiles/unmanaged is a list of files that should
explicitly never be overwritten by packages.

Oh, and we'll want a file like /etc/conffiles/default, which says how to
handle config files not in either list above.  Obviously, I think Debian
should default to config files being unmanaged.  But if we end up
implementing something like this, I might consider making the default to
be managed for Debian Desktop.  Or at least have a prompt about it.

We'd need a few new tools in (say) dpkg for packages to use to determine
whether or not a file is managed and stuff, but that's all mostly
detail.

Now, we can handle the two cases I posted; Hardcore Unix guy will
install Debian, and can rest secure in the knowledge that his manual
edits to anything in /etc/ will be preserved.  Semi-experienced Newbie
has a choice.  He can explicitly make stuff managed if he wants.

So, opinions?  Yeah, it's kind of gross.  But the way things are now is
far worse.

Re: Status of Sarge release issues

[Junichi Uekawa]

Your mail was a bit misleading, so a clarification will be needed:

> * The source packages should build-depend on libpng-dev or libpng12-dev,
> but those build-depending on libpng3-dev will still work.

A source package should never build-depend on libpng-dev,
especially if the source package builds a shared library.
It should explicitly build-depend on libpng3-dev, or preferrably
libpng12-0-dev.

A package being randomly built against libpng2 or libpng3 is a pretty
bad idea.



regards,
junichi

Re: Bug#189370: acknowledged by developer (irrelevant)

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 18:07:28 +0900 (JST),
>> Atsuhito Kohda <[EMAIL PROTECTED]> said: 

 >> Does this file really change so often that this is a problem?
 >> Users will only be prompted if the distributed version of a
 >> conffile has changed.

 > It is not problem how often language.dat changes but that if it was
 > changed once then users will be prompted everytime at upgrading.

Umm, you seem not to understand how dpkg conffile handling
 works, for this certainly is not the case. 

 > And I suspect that for users in europe it is not rare to add extra
 > hyphenation pattern, at least.

Local changes, you mean?

 > Note users can add local modification freely with the current
 > method, please read README.Debian.

But an admin may no longer freely synchronize the conffile
 across the whole heterogeneous installation. This assumption that all
 the world is Debian, and introducing gratituous incompatibility with
 the rest of the TeX world is what smacks of bad design decisions.

manoj

-- 
"...'fire' does not matter, 'earth' and 'air' and 'water' do not
matter.  'I' do not matter.  No word matters.  But man forgets reality
and remembers words.  The more words he remembers, the cleverer do his
fellows esteem him.  He looks upon the great transformations of the
world, but he does not see them as they were seen when man looked upon
reality for the first time.  Their names come to his lips and he
smiles as he tastes them, thinking he knows them in the naming."
Siddartha, _Lord_of_Light_ by Roger Zelazny
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#189370: acknowledged by developer (irrelevant)

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 12:09:38 +0100,
>> Mark Brown <[EMAIL PROTECTED]> said: 

 > Sorry, I wasn't clear.  The current handling of texmf.cnf looks
 > reasonably sane to me - it's now not too dissimilar to how
 > /etc/modules.conf is handled.  What I was trying to say was that in
 > the past there were problems with the handling of some
 > configuration files in the tetex packages but that languages.dat
 > hadn't really registered as one that needed special treatment.

Personally, I feel that one suboptimal design does not jsutify
 another; since both add to the cases that break the nice invariant
 that the admin may modify any file in /etc, and we do not mandate how
 the files are modified (if we can madate how conffiles may be
 modified, I would like to outlaw vim and mandate the one true editor
 to be used for all packages ;-) ;-)

I strongly believe that the properties that all configuration
 files reside in /etc, and that the admin may edit any of these files
 at will (no linux conf, etc, and a required intermediary) were the
 one of the stronger attractions of Debian; and now these invariants
 are slowly being snipped away by the restrictions on modification of
 these files. 

We may already be on the slippery slope, but we should not
 use that fact to accelerate our slide.

manoj
-- 
Blore's Razor: Given a choice between two theories, take the one which
is funnier.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#189370: acknowledged by developer (irrelevant)

[Manoj Srivastava]

>> On Sat, 19 Apr 2003 00:20:04 +0900 (JST),
>> Atsuhito Kohda <[EMAIL PROTECTED]> said: 

 > From: Manoj Srivastava <[EMAIL PROTECTED]> Subject: Re:
 > Bug#189370: acknowledged by developer (irrelevant) Date: Fri, 18
 > Apr 2003 04:21:17 -0500

 >> >> I have an impression that such Policy understanding prevents
 >> >> sane advance of packages.
 >>
 >> I am sorry, I do think that not preserving user changes is not an
 >> advancement.

 > I said to you once before but the new mechanism preserves user
 > change much clearly than the former one within the new mechanism.
 > It could lost user change only at transition from the old mechanism
 > (conffile) to the new mechanism (configuration file).

So? You could  have informed the user about the magnitude of
 the changes in the preinst, and let the USER make the decision;
 letting the package fail until they handled the configuration file
 issue. Alternately, change the location of the file the program looks
 at  and inform the user (this is the less preferred option).

Usurping the users right to make the decision, and using that
 to cloak a violation of policy is a flawed argument.

 >> My as yet incomplete mechanism is to use debconf andother means to
 >> generate a current configuration file on the fly, and use ucf to
 >> prompt, somewhat like dpkg, as below:
 >> --
 >> Configuration file \`$dest_file' ==> File on system created by you
 >> or by a script.  ==> File also in package provided by package
 >> maintainer.  What would you like to do about it ?  Your options
 >> are: Y or I : install the package maintainer's version N or O :
 >> keep your currently-installed version D : show the differences
 >> between the versions 3 or T : show a thre way difference between
 >> current, older, and new versions of the file M : Do a 3 way merge
 >> between current, older, and new versions of the file [Very
 >> Experimental] Z : start a new shell to examine the situation The
 >> default action is to keep your current version.
 >> --

 > This doesn't work for texmf.cnf which also I told you once before.

And why does it not?

 > If the default is to keep your current version then many TeX
 > related packages should fail to install.

So? The user made the choice As long as you inform the suer of
 the consequences of their action in the preinst, it is their machine,
 they may choose to have tetex break until they decide to deal with
 the issue, or they may decide to go with the new configuration
 file. Either way, the decision is not yours t make. it is the end
 users. 

 > The current mechanism is, at least at present, only one solution
 > which provides sufficiently flexible handling and also preserves
 > user changes.

I beg to differ.

manoj
-- 
Bones: "The man's DEAD, Jim!"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: why do we care about configuration files?

[Manoj Srivastava]

>> On 18 Apr 2003 11:15:50 -0400,
>> Colin Walters <[EMAIL PROTECTED]> said: 

 > There's other use cases too, but if we're not supporting the two
 > big ones above, we have completely failed.  I hope this makes
 > things clearer.  There *is* a problem, and we need to fix it.

I think more than just these use cases, we need to support the
 invariant that user changes in /etc/ are scrosanct, and we should not
 have screipts determining that they know better and blow awqay the
 changes. 

Indeed, if the users choices break the installation of the
 package, so be it.

After all, no one has written code into rm to prevent rm -rf /
 either. though that is inherently a dangerous operation.


manoj
-- 
While Europe's eye is fix'd on mighty things, The fate of empires and
the fall of kings; While quacks of State must each produce his plan,
And even children lisp the Rights of Man; Amid this mighty fuss just
let me mention, The Rights of Woman merit some attention. Robert
Burns, Address on "The Rights of Woman", 26/10 1792
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: stop the "manage with debconf" madness

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 10:28:57 -0500,
>> Steve Langasek <[EMAIL PROTECTED]> said: 

 > If the package maintainers are correctly using the debconf
 > priorities, and the admin has chosen a debconf priority that
 > accurately reflects their preferences, why do you care?  By
 > definition, any prompts at priority medium or lower have reasonable
 > defaults, so unless they're shown to the admin *at his choice*, and
 > the admin actively *chooses* a non-default value, the configuration
 > file won't be changed anyway.

OK, this is what bugs me. If I have a choice -- if I may chose
 to be prompted every time, and if I have the choice, every time, to
 look at the changes, and _then_ decide ot keep the old or move to the
 new, I have no problem.

It is an added bonus if I could have upstream changes merged
 into my local configuration file when I so desire (use the diff
 between the upstream maintainer files and patch it into my local
 file), but that is gravy.

What I do not like is being as ked to make a decision about
 all future upgrades *NO*, when I have no idea what the changes are
 going to look like.

If you give users a choice replace configuration files in the
 future:  'ask or 'always (pathologically, even 'never), I would be
 happy. 

Assuming it is 'always is wrong.

Giving user a choice of 'always, or "You are on your own,
 buddy" is also wrong.

manoj
-- 
Flee at once, all is discovered.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: stop the "manage with debconf" madness

[Manoj Srivastava]

>> On 18 Apr 2003 11:55:09 -0400,
>> Colin Walters <[EMAIL PROTECTED]> said: 

 > So, opinions?  Yeah, it's kind of gross.  But the way things are
 > now is far worse.

As long as /etc/conffiles/managed, /etc/conffiles/unmanaged,
 and /etc/conffiles/default are never themselves unmanaged, this would
 work. And the factory default for /etc/conffiles/default should be
 managed; and the other two files should be empty. 

If we standardize on a easy to interpret format for these
 files, I'll add the logic to ucf to handle these directives. (how
 about a configuration file path per line for /etc/conffiles/managed
 and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a
 single word, which is "managed" by default; anything other than
 "unmanaged" is interpreted as "managed?).

manoj
-- 
...computer hardware progress is so fast.  No other technology since
civilization began has seen six orders of magnitude in
performance-price gain in 30 years. Fred Brooks, Jr.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: stop the "manage with debconf" madness

[John Hasler]

Colin Walters writes:
> One might be to create a third class of configuration files; let's call
> them "managed configuration files".

Is the choice to be up to the maintainer?  If so, I'm afraid that over time
almost all configfiles would become managed, as that would be the easy way
for maintainers.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: Bug#189370: acknowledged by developer (irrelevant)

[David Schleef]

On Sat, Apr 19, 2003 at 12:20:04AM +0900, Atsuhito Kohda wrote:
> From: Manoj Srivastava <[EMAIL PROTECTED]>
> Subject: Re: Bug#189370: acknowledged by developer (irrelevant)
> Date: Fri, 18 Apr 2003 04:21:17 -0500
> 
> >  >> I have an impression that such Policy understanding prevents sane
> >  >> advance of packages.
> > 
> > I am sorry, I do think that not preserving user changes is not
> >  an advancement.
> 
> I said to you once before but the new mechanism preserves 
> user change much clearly than the former one within the
> new mechanism.  It could lost user change only at transition
> from the old mechanism (conffile) to the new mechanism (configuration
> file).

Such as in an upgrade from woody to sarge?  That sounds like a
RC bug to me.



dave...

[david@eelf.ddts.net: Re: why do we care about configuration files?]

[David B Harris]

On Fri Apr 18, 11:15am -0400, Colin Walters wrote:
> Perhaps I've been overly strong with the rhetoric.  Let me give two
> realistic scenarios where this "manage foo with debconf?" fails.

I like your two real-world examples, and I'd like to present a third.

3) Impatient but advanced user
   Somebody who dislikes being asked repeatedly whether or not a
   conffile can be overwritten. This user has tested xserver-xfree86's
   debconf interface, and has taken the time to understand how
   xserver-xfree86's postinst generates the configuration file based on
   the debconf information. He is very confident in it doing the right
   thing, and doesn't want to be bothered on each upgrade about whether
   or not it can overwrite it. More importantly, this user knows full
   well that, in the very rare circumstance where it *does* break, he
   can easily fix it within minutes.

This user will likely feel the same way about almost all
debconf/postinst-managed configuration files, excepting the few which he
knows will break repeatedly. He doesn't want to get asked 50 "may I
overwrite your file?" questions each upgrade. He knows that in the time
spent reading and answering all those questions, he could just has
easily fixed the two cases of breakage. Which he would have to do in
addition to answering the questions, were they forced upon him.

I liked the concept behind your suggestion of "managed" and "unmanaged"
configuration files. I would, however, suggest a slightly different
interface:

1) Package has a configuration file which can (optionally) be managed
   debconf/postinst
2) Package's .config asks, *once* (respecting debconf "seen" flag), the
   following question:

   "File /etc/foo/bar can optionally be managed by this package's
maintenance scripts in an automated manner. How would you like
changes to /etc/foo/bar to be handled?

ask-no: If /etc/foo/bar will be changed, ask first. Default to
`no'
   ask-yes: If /etc/foo/bar will be changed, ask first. Default to
`yes'
 always-no: Never automatically overwrite /etc/foo/bar, don't even
ask.
always-yes: Always automatically overwrite /etc/foo/bar, don't even
ask (warning: dangerous).

 ask-no
ask-yes
   always-no
   always-yes"

3) That question should be standard amongst all packages, identical. It
   should always be of priority "medium".
4) A standard interface for ask-yes and ask-no would also be required,
   similar to dpkg's conffile handling.

For ask-* interfaces, debconf's "seen" flag should (obviously) be
ignored, since it's *meant* to be asked repeatedly.

After some feedback, I will implement said standard interfaces as
example. I kind of like the idea of
/etc/conffiles/{managed,unmanaged,default}. That could easily be used as
the backend storage for the standard {ask,always}-{no,yes} question.


pgpddpFF01dCy.pgp
Description: PGP signature

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[David B Harris]

Apologies for starting a new thread, I accidentally replied to Colin
privately, and instead of re-writing the email, I simply forwarded it.
Bad clal :)


pgpLvG6UUTUOa.pgp
Description: PGP signature

Re: stop the "manage with debconf" madness

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 14:04:25 -0500,
>> John Hasler <[EMAIL PROTECTED]> said: 

 > Colin Walters writes:
 >> One might be to create a third class of configuration files; let's
 >> call them "managed configuration files".

 > Is the choice to be up to the maintainer?  If so, I'm afraid that
 > over time almost all configfiles would become managed, as that
 > would be the easy way for maintainers.  

From what I understand, the choice is _not_ the maintainers,
 since it is encapsulated in /etc/conffile/managed,
 /etc/conffile/unmanaged, and /etc/conffile/default; all of which are
 themselves conffiles which are under local admin control.

I am happy with the local admin deciding which ones are
 managed; or not, and where it is OK to blow away local changes;
 packages making this decision on their own ought to be considered in
 violation of policy.

manoj

-- 
Don't hit a man when he's down -- kick him; it's easier.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: stop the "manage with debconf" madness

[Colin Walters]

On Fri, 2003-04-18 at 15:04, John Hasler wrote:
> Colin Walters writes:
> > One might be to create a third class of configuration files; let's call
> > them "managed configuration files".
> 
> Is the choice to be up to the maintainer?  If so, I'm afraid that over time
> almost all configfiles would become managed, as that would be the easy way
> for maintainers.

No, in my proposal, it's a local system decision.  Package maintainers
will have to be aware of managed config files, but they don't control
which are and which aren't managed.

Re: stop the "manage with debconf" madness

[Colin Walters]

On Fri, 2003-04-18 at 13:54, Manoj Srivastava wrote:
> >> On 18 Apr 2003 11:55:09 -0400,
> >> Colin Walters <[EMAIL PROTECTED]> said: 
> 
>  > So, opinions?  Yeah, it's kind of gross.  But the way things are
>  > now is far worse.
> 
>   As long as /etc/conffiles/managed, /etc/conffiles/unmanaged,
>  and /etc/conffiles/default are never themselves unmanaged, this would
>  work. And the factory default for /etc/conffiles/default should be
>  managed; and the other two files should be empty. 

I agree.

>   If we standardize on a easy to interpret format for these
>  files, I'll add the logic to ucf to handle these directives. (how
>  about a configuration file path per line for /etc/conffiles/managed
>  and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a
>  single word, which is "managed" by default; anything other than
>  "unmanaged" is interpreted as "managed?).

Yep, that's exactly the way I was thinking of it.  Cool, I'm glad we're
on the same wavelength here.  Having it in ucf will be a good first
step.  In fact, ucf might be the logical place to keep this.

By the way, David B Harris has expressed interest in private mail to me
in tackling this problem too, hopefully he'll speak up here with his
ideas.

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[Colin Walters]

On Fri, 2003-04-18 at 15:16, David B Harris wrote:
> On Fri Apr 18, 11:15am -0400, Colin Walters wrote:
> > Perhaps I've been overly strong with the rhetoric.  Let me give two
> > realistic scenarios where this "manage foo with debconf?" fails.
> 
> I like your two real-world examples, and I'd like to present a third.

Your case is also one we'd like to tackle, I agree.

> This user will likely feel the same way about almost all
> debconf/postinst-managed configuration files, excepting the few which he
> knows will break repeatedly. He doesn't want to get asked 50 "may I
> overwrite your file?" questions each upgrade. 

I don't think anyone does :)

> I liked the concept behind your suggestion of "managed" and "unmanaged"
> configuration files. I would, however, suggest a slightly different
> interface:
> 
> 1) Package has a configuration file which can (optionally) be managed
>debconf/postinst

This is already the way things are now; a package doesn't have to do
anything special to create configuration files in its postinst.

> 2) Package's .config asks, *once* (respecting debconf "seen" flag), the
>following question:

Uggg.  We should be extremely hesitant about changing
/etc/conffiles/{managed,unmanaged,default} in maintainer scripts.  I
mean they exist solely *because* of the problems of changing
configuration files in maintainer scripts :)

I don't think we should use Debconf to prompt on each package
installation like this.  Your proposal would make the "medium" debconf
priority far more painful than it is even now.  Just think about how
many prompts you'd have to go through on an initial installation.  It
would be at least a hundred.

Basically, it seems to me that in your use case, the user could just:
echo managed > /etc/conffiles/default

And then explicitly list those files they want to keep unmanaged in
/etc/conffiles/unmanaged.

Now, it would be nice if at the end of a package installation run, dpkg
said something like:

The following new configuration files have been installed:
Managed:
  /etc/foo/foo.conf
  /etc/blah.config
Unmanaged;
  /etc/whee/moo.conf

That way if you see something you want to maintain yourself, you drop it
into /etc/conffiles/unmaanaged.

Re: stop the "manage with debconf" madness

[Jarno Elonen]

Would it already be time for a long term solution that no doubt has been 
discussed sometimes in the past:

looking at configuration files in /etc and ~/.*, most of them are actually 
very simple. Instead of treating them as flat files with arbitrary content 
and *generating* the managed ones from debconf DB, you could pretty easily 
*manipulate* them in a more structured and fine grained way by parsing and 
unparsing them according to developer/maintainer specified metaconfiguration 
files. In addition to making merging of version specific changes easier, it 
also allows different configuration interfaces like Debconf now does but 
during package use, not just installation.

In fact, I have previously experimented with such stuff on proprietary 
software at my work and our experiences there where quite encouraging: 
handling of blocks and order of configuration elements weren't as difficult 
as we though they would be, powerful metaconfiguration files could quite 
easily be created even with error-reducing GUI tools and while perfect 
solution apparently doesn't exist, comment preserving proved to be possible 
in practice.

It seems there is already at least one current project for developing a tool 
like this: http://config4gnu.sourceforge.net/
Comments?

- Jarno

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[J.Brown (Ender/Amigo)]

> 3) Impatient but advanced user
>Somebody who dislikes being asked repeatedly whether or not a
>conffile can be overwritten. This user has tested xserver-xfree86's
>debconf interface, and has taken the time to understand how
>xserver-xfree86's postinst generates the configuration file based on
>the debconf information. He is very confident in it doing the right
>thing, and doesn't want to be bothered on each upgrade about whether
>or not it can overwrite it. More importantly, this user knows full
>well that, in the very rare circumstance where it *does* break, he
>can easily fix it within minutes.
>
> This user will likely feel the same way about almost all
> debconf/postinst-managed configuration files, excepting the few which he
> knows will break repeatedly. He doesn't want to get asked 50 "may I
> overwrite your file?" questions each upgrade. He knows that in the time
> spent reading and answering all those questions, he could just has
> easily fixed the two cases of breakage. Which he would have to do in
> addition to answering the questions, were they forced upon him.

This also comes down to another matter, where a package upgrade may run an
external program for generating configfiles. It would be nice if this
could also be handled with a "don't reconfig" flag.

Ex.
 A while ago, although I believe this bug is fixed now, any upgrade to
XFree would automatically (!!) regenerate my XF86Config-4 file.
Unfortunatly, it would set the DefaultDepth to 24, which disables direct
rendering on my Voodoo3 machine. It was quite irritating with unstable
when occasionally OpenGL would just stop working and I would have to go
and manually reset DefaultDepth to 16.

Whilst this isn't happening anymore, I have seen other packaes do
similar things to deal with per-version configfile format changes, etc.

 - Ender

stop abusing debconf already

[Joey Hess]

Enough already.

Folks, if you don't stop abusing debconf with useless notes that belong
in README.Debian and config file overwriting, I will stop maintaining
it. 

Stop slapping incorrect uses of debconf in everywhere. Feel free to run
any package using debconf by me before you upload it, or take the time
to understand yourself how things should work.

-- 
see shy jo


pgpoqSfGnHPJ8.pgp
Description: PGP signature

Re: stop the "manage with debconf" madness

[David B Harris]

On Fri Apr 18, 12:54pm -0500, Manoj Srivastava wrote:
> >> On 18 Apr 2003 11:55:09 -0400,
> >> Colin Walters <[EMAIL PROTECTED]> said: 
> 
>  > So, opinions?  Yeah, it's kind of gross.  But the way things are
>  > now is far worse.
> 
>   As long as /etc/conffiles/managed, /etc/conffiles/unmanaged,
>  and /etc/conffiles/default are never themselves unmanaged, this would
>  work. And the factory default for /etc/conffiles/default should be
>  managed; and the other two files should be empty. 
> 
>   If we standardize on a easy to interpret format for these
>  files, I'll add the logic to ucf to handle these directives. (how
>  about a configuration file path per line for /etc/conffiles/managed
>  and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a
>  single word, which is "managed" by default; anything other than
>  "unmanaged" is interpreted as "managed?).

Something else worth thinking about, which I was gonna throw in my
example package for all this stuff, is config-file-change priority.

ie: It would be nice to differentiate between "the entire config format
has changed, I will break completely if the old one is used", "some
parameter options have changed; the old ones will still work - for now",
"I just changed some defaults, keep what they have now", and "I fixed a
typo in one of the documentation comments."

We could then respect things like DEBCONF_PRIORITY, and not bother the
user if all we've changed is the spelling of a descriptive (ie: not
example) word in a comment.

Pet peeve of mine in dpkg conffile handling :)


pgp9z3wRbXkEU.pgp
Description: PGP signature

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[David B Harris]

On Fri Apr 18, 05:28pm -0400, Colin Walters wrote:
> > 1) Package has a configuration file which can (optionally) be
> > managed
> >debconf/postinst
>
> This is already the way things are now; a package doesn't have to do
> anything special to create configuration files in its postinst.

Yeah, I was just setting out the scenario.

> > 2) Package's .config asks, *once* (respecting debconf "seen" flag), the
> >following question:
>
> Uggg.  We should be extremely hesitant about changing
> /etc/conffiles/{managed,unmanaged,default} in maintainer scripts.  I
> mean they exist solely *because* of the problems of changing
> configuration files in maintainer scripts :)

I think this is the *perfect* place for maintainer scripts. We can make
the format extraordinarily simple, such that anybody who is capable of
writing a maintainer script can take 60 seconds to parse it and write it
out. It could be as simple as:

if [[ "$always_yes" = "true" ]]; then
grep -v '^/etc/foo/bar$' /etc/conffiles/managed > "$tempfile" && cp 
"$tempfile" /etc/conffiles/managed
if ! grep '^/etc/foo/bar$' /etc/conffiles/unmanaged; then
echo /etc/foo/bar >> /etc/conffiles/unmanaged
fi
fi

I may have the meanings of unmanaged and managed backwards :)

The root of this problem isn't that maintainers are changing config
files in postinst scripts; the root is that those scripts aren't smart
enough to parse those config files and preserve user changes.

> I don't think we should use Debconf to prompt on each package
> installation like this.  Your proposal would make the "medium" debconf
> priority far more painful than it is even now.  Just think about how
> many prompts you'd have to go through on an initial installation.  It
> would be at least a hundred.

I dunno. I agree that it's unpleasant, but at least it'd only have to be
done once. (And that's a common strength in Debian; you usually only
need to do things once, as unpleasant as it might be. I think the
tradeoff has worked really well thus far.)

If /etc/conffiles/* *only* lists files that could possible be managed by
postinsts, then I could live with the question never being asked,
instead being maintained manually through editing /etc/conffiles.

> Basically, it seems to me that in your use case, the user could just:
> echo managed > /etc/conffiles/default 

Yeah, I'm starting to think this.

> And then explicitly list those files they want to keep unmanaged in
> /etc/conffiles/unmanaged.
>
> Now, it would be nice if at the end of a package installation run, dpkg
> said something like:
>
> The following new configuration files have been installed:
> Managed:
>   /etc/foo/foo.conf
>   /etc/blah.config
> Unmanaged;
>   /etc/whee/moo.conf
>
> That way if you see something you want to maintain yourself, you drop it
> into /etc/conffiles/unmaanaged.

Aaah. That's good, I like that.

But I dunno, the scenario I brought up would still remain. Even if a
file is in /etc/conffiles/managed, the user still needs to be asked if
it's okay to overwrite it, unless they tell the system otherwise.

How will we let them tell it otherwise? 

I'm thinking in the "may I upgrade your configuration file?" question,
have the options I mentioned before ("no", "yes", "always-no").

With "no" and "yes" being one-time-only things, "always-no" removing the
line from /etc/conffiles/managed and adding it to
/etc/conffiles/unmanaged.

How's that sound? It's unobtrusive, only adding a third option. We
ensure that /etc/conffiles/* is *extroardinarily* easy to deal with (we
can have a tool to do this for us, akin to
update-rc.d/update-inetd/etc), they'll only get changed when the user
tells us to change them, they're perfectly capable of changing it
themselves manually, and we end up with no more questions than we have
now.



pgp0J7QWh2iZv.pgp
Description: PGP signature

Re: stop the "manage with debconf" madness

[Colin Watson]

On Fri, Apr 18, 2003 at 05:06:15PM -0400, Colin Walters wrote:
> On Fri, 2003-04-18 at 13:54, Manoj Srivastava wrote:
> > If we standardize on a easy to interpret format for these
> >  files, I'll add the logic to ucf to handle these directives. (how
> >  about a configuration file path per line for /etc/conffiles/managed
> >  and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a
> >  single word, which is "managed" by default; anything other than
> >  "unmanaged" is interpreted as "managed?).
> 
> Yep, that's exactly the way I was thinking of it.  Cool, I'm glad we're
> on the same wavelength here.  Having it in ucf will be a good first
> step.  In fact, ucf might be the logical place to keep this.

Let's please try to keep this kind of complication to an absolute
minimum, though. Packages should be encouraged to use as simple
mechanisms as possible for their configuration files, I feel: where
possible, dpkg-handled conffiles should be quite adequate for a large
number of cases.

I find that the minimalist approach of using as simple configuration
file technology as I can in my packages means that I don't try to
over-extend them to deal with things which are really better documented
well and left up to the admin. IMHO, this is a win.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[David B Harris]

On Fri Apr 18, 07:06pm -0400, David B Harris wrote:
> I'm thinking in the "may I upgrade your configuration file?" question,
> have the options I mentioned before ("no", "yes", "always-no").
> 
> How's that sound? It's unobtrusive, only adding a third option. We
> ensure that /etc/conffiles/* is *extroardinarily* easy to deal with (we
> can have a tool to do this for us, akin to
> update-rc.d/update-inetd/etc), they'll only get changed when the user
> tells us to change them, they're perfectly capable of changing it
> themselves manually, and we end up with no more questions than we have
> now.
> 

Gar. We'd still need always-yes to deal with the case I raised. Don't
like it, but ...


pgpwpHDeAJjRA.pgp
Description: PGP signature

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 17:36:01 -0500 (CDT),
>> J Brown (Ender/Amigo) <[EMAIL PROTECTED]> said: 

 >> 3) Impatient but advanced user
 >> Somebody who dislikes being asked repeatedly whether or not a
 >> conffile can be overwritten. This user has tested
 >> xserver-xfree86's debconf interface, and has taken the time to
 >> understand how xserver-xfree86's postinst generates the
 >> configuration file based on the debconf information. He is very
 >> confident in it doing the right thing, and doesn't want to be
 >> bothered on each upgrade about whether or not it can overwrite
 >> it. More importantly, this user knows full well that, in the very
 >> rare circumstance where it *does* break, he can easily fix it
 >> within minutes.

 >> This user will likely feel the same way about almost all
 >> debconf/postinst-managed configuration files, excepting the few
 >> which he knows will break repeatedly. He doesn't want to get asked
 >> 50 "may I overwrite your file?" questions each upgrade. He knows
 >> that in the time spent reading and answering all those questions,
 >> he could just has easily fixed the two cases of breakage. Which he
 >> would have to do in addition to answering the questions, were they
 >> forced upon him.


If you use ucf like mechanisms, and you acpet the first
 debconf generated file, then you will never be asked to over write
 your file -- since the md5sum of the installed file shall match the
 previous maintainer version. Bingo, we cater to all these use cases
 at once.


manoj
-- 
We are MicroSoft.  You will be assimilated.  Resistance is
futile. (Attributed to B.G., Gill Bates)
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[David B Harris]

On Fri Apr 18, 06:37pm -0500, Manoj Srivastava wrote:
>   If you use ucf like mechanisms, and you acpet the first
>  debconf generated file, then you will never be asked to over write
>  your file -- since the md5sum of the installed file shall match the
>  previous maintainer version. Bingo, we cater to all these use cases
>  at once.

Wouldn't that only be accurate if the postinst generated an identical
config file every time?


pgp88NKTvdObo.pgp
Description: PGP signature

Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng

[Brian May]

On Fri, Apr 18, 2003 at 09:33:01PM +0200, [EMAIL PROTECTED] wrote:
> Package: amavisd-new
> Version: 20021227p2-5
> Severity: grave

Grave would seem to be a bit of an overkill? amavisd-new still works OK
for the majority of users...

> when 
>- amavis-ng is installed (I used version 0.1.6.2-1), 
>- and amavisd-new previously had been installed but now only its
>  config-files are present, 
> then 
>the init-scripts of _both_ packages start the program
>/usr/sbin/amavisd

I really don't know what to do about this bug. I think the
same thing has happened before with similar situations, but
I don't know what was decided.

Both init-scripts check for the existance of /usr/sbin/amavisd,
and assume it is their version of the program and will run it.

I believe amavis-ng and amavisd-new already conflict, so that isn't the
problem.

The problem is that when replacing amavis-ng with amavisd-new,
amavis-ng will leave behind /etc/init.d/ that conflict with
amavisd-new.

Any ideas?
-- 
Brian May <[EMAIL PROTECTED]>

imlib-linked-with-libpng3

[Steve M. Robbins]

Hello,

I'd like to solicit opinions about what to do with
imlib-linked-against-libpng3.

Until August 2002, the Debian imlib packages were linked with libpng2.
Even after libpng3 was released in early 2002, imlib remained linked
with the older libpng2.  This was done to retain the ABI of imlib,
especially the ABI of the GNOME version, gdk-imlib.

Imlib is more-or-less dormant upstream.  However, in late August, I
was under the impression that upstream imlib was going to release a
new version (with new SONAME) that would be linked with libpng3.  In
anticipation of that, I introduced imlib2/imlib-dev into Debian but
filed a Grave bug against it to keep it from moving to testing.

It is still not in testing.

I no longer believe that upstream will release any new versions of
imlib and I plan to ask that imlib2 be removed from the archive.  I
don't want to change the current imlib1 linkage since imlib is pretty
much dormant and probably on its way out.

There are six packages currently linked against imlib2:

chinput 
fnlib   
kdegraphics 
mgp 
picturebook 
wallp   

I'm not sure whether they strictly require png3 or whether they could
simply be rebuilt with imlib1 and libpng2.  In the past, however, some
KDE folks have explicitly requested imlib+png3.

What would be the best way to accomodate such a request?  I can
imagine introducing a new package of imlib linked with libpng3.  But
since it has to use the same SOVERSION as the current imlib1, it would
have to conflict with imlib1.  Each individual admin could then choose
to use imlib+png2 or to use imlib+png3.  However, each choice would
have its own set of incompatible programs so this option doesn't
appeal to me.

Another option is to drop the idea of imlib+png3.  The six packages
mentioned above would then have to build either with png2 or somehow
incorporate imlib into their source build.  For the maintainers of the
six packages: is that feasible?

-Steve

Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng

[David B Harris]

On Sat Apr 19, 10:22am +1000, Brian May wrote:
> Any ideas?

Share an initscript between them, if that's possible?


pgp2vmAEIdmO0.pgp
Description: PGP signature

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 20:03:04 -0400,
>> David B Harris <[EMAIL PROTECTED]> said: 

 > On Fri Apr 18, 06:37pm -0500, Manoj Srivastava wrote:
 >> If you use ucf like mechanisms, and you acpet the first debconf
 >> generated file, then you will never be asked to over write your
 >> file -- since the md5sum of the installed file shall match the
 >> previous maintainer version. Bingo, we cater to all these use
 >> cases at once.

 > Wouldn't that only be accurate if the postinst generated an
 > identical config file every time?

Nope. When you accept a config file, your md5sum uis the same
 as the one generated *then*.  Next upgrade, if the postinst generated
 file is different, it shall replace yours again -- since your file
 will still match the stored md5sum. 

If i did not work this way, ucf would not be anywhere near as
 useful. 

manoj
-- 
... C++ offers even more flexible control over the visibility of
member objects and member functions.  Specifically, members may be
placed in the public, private, or protected parts of a class.  Members
declared in the public parts are visible to all clients; members
declared in the private parts are fully encapsulated; and members
declared in the protected parts are visible only to the class itself
and its subclasses.  C++ also supports the notion of
*___friends*: cooperative classes that are permitted
to see each other's private parts. Grady Booch, "Object Oriented
Design with Applications"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: imlib-linked-with-libpng3

[Steve Langasek]

Hi Steve,

On Fri, Apr 18, 2003 at 08:43:45PM -0400, Steve M. Robbins wrote:

> I no longer believe that upstream will release any new versions of
> imlib and I plan to ask that imlib2 be removed from the archive.  I
> don't want to change the current imlib1 linkage since imlib is pretty
> much dormant and probably on its way out.

> There are six packages currently linked against imlib2:

>   chinput 
>   fnlib   
>   kdegraphics 
>   mgp 
>   picturebook 
>   wallp   

> I'm not sure whether they strictly require png3 or whether they could
> simply be rebuilt with imlib1 and libpng2.  In the past, however, some
> KDE folks have explicitly requested imlib+png3.

FWIW, fnlib does not require libpng itself; it is, however, linked
against libpng3 thanks to the usual libtool idiocy.

> What would be the best way to accomodate such a request?  I can
> imagine introducing a new package of imlib linked with libpng3.  But
> since it has to use the same SOVERSION as the current imlib1, it would
> have to conflict with imlib1.  Each individual admin could then choose
> to use imlib+png2 or to use imlib+png3.  However, each choice would
> have its own set of incompatible programs so this option doesn't
> appeal to me.

If upstream is dormant (and I know that's an understatement), you could
also try to coordinate with other vendors who might still ship imlib and
agree to pick a new soname anyway.  That seems a better choice than
creating a new package that conflicts with imlib1, IMHO.

> Another option is to drop the idea of imlib+png3.  The six packages
> mentioned above would then have to build either with png2 or somehow
> incorporate imlib into their source build.  For the maintainers of the
> six packages: is that feasible?

No problems here, at least.

Cheers,
-- 
Steve Langasek
postmodern programmer


pgpSZsPvEs6QY.pgp
Description: PGP signature

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 19:30:34 -0400,
>> David B Harris <[EMAIL PROTECTED]> said: 

 > Gar. We'd still need always-yes to deal with the case I
 > raised. Don't like it, but ...

I think that the /etc/conffiles/* files preclude any need for
 these quad questions.

manoj
-- 
(null cookie; hope that's ok)
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]

[Manoj Srivastava]

>> On Fri, 18 Apr 2003 19:06:34 -0400,
>> David B Harris <[EMAIL PROTECTED]> said: 

 > if [[ "$always_yes" = "true" ]]; then
 > grep -v '^/etc/foo/bar$' /etc/conffiles/managed > "$tempfile"
 > && cp "$tempfile" /etc/conffiles/managed if ! grep
 > '^/etc/foo/bar$' /etc/conffiles/unmanaged; then
 > echo /etc/foo/bar >> /etc/conffiles/unmanaged
 > fi
 > fi

ucf development has something like this, except it is more
 paranoid and checks to see if something is in managed and unmanaged
 at once.

 > But I dunno, the scenario I brought up would still remain. Even if a
 > file is in /etc/conffiles/managed, the user still needs to be asked if
 > it's okay to overwrite it, unless they tell the system otherwise.

Why? The only way a file would ever be lsited there is if the
 admin put it there. I say that policy states that be default _no_
 file goes into the managed list; and the shipped default for
 /etc/coonffile/default is unmanahed. (managed is a list of files that
 the package can freely over write). 

 > How will we let them tell it otherwise? 

They told us that by entering a conffile name in the managed list.

 > I'm thinking in the "may I upgrade your configuration file?" question,
 > have the options I mentioned before ("no", "yes", "always-no").

 > With "no" and "yes" being one-time-only things, "always-no" removing the
 > line from /etc/conffiles/managed and adding it to
 > /etc/conffiles/unmanaged.

 > How's that sound? It's unobtrusive, only adding a third option.

I think this is not needed. Since the shipped default is for
 all files to be unmanaged, ie, not ever written over by default; any
 files in the managed section were put in by explicit admin action.

manoj

-- 
Lost: gray and white female cat.  Answers to electric can opener.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Bug#189626: ITP: python-crack -- Python bindings for cracklib

[Domenico Andreoli]

Package: wnpp
Version: N/A; reported 2003-04-19
Severity: wishlist

* Package name: python-crack
  Version : 0.2
  Upstream Author : Domenico Andreoli <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/python-crack
* License : GPL
  Description : Python bindings for cracklib


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux filibusta.crema.unimi.it 2.4.18-cavok #1 Tue Aug 6 10:57:32 CEST 
2002 i686
Locale: LANG=C, LC_CTYPE=C

Re: /run and read-only /etc

[Anthony DeRobertis]

On Tue, 2003-04-15 at 15:19, Thomas Hood wrote:

> Unfortunately you seem to be wrong, at least with regard to
> bind version 1:8.3.4-4. 

Ah. That'd explain it. I'm using bind9.


signature.asc
Description: This is a digitally signed message part

Re: stop the "manage with debconf" madness

[Andrew Suffield]

On Fri, Apr 18, 2003 at 10:28:57AM -0500, Steve Langasek wrote:
> If the package maintainers are correctly using the debconf priorities,
> and the admin has chosen a debconf priority that accurately reflects
> their preferences, why do you care?  By definition, any prompts at
> priority medium or lower have reasonable defaults, so unless they're
> shown to the admin *at his choice*, and the admin actively *chooses* a
> non-default value, the configuration file won't be changed anyway.

One major problem is that I can't trust you arseholes (you know who
you are) to set sensible priorities and defaults.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpmhLO41HmQT.pgp
Description: PGP signature

Re: imlib-linked-with-libpng3

[Chris Cheney]

Why not simply make a imlib1p that conflicts with old imlib1 and rebuild
the remaining 11 sources that still use imlib1 with old libpng2? There
are fewer that would cause trouble in that batch, afaict only: chameleon,
ebview, endeavour, pixelize, vertex.

chameleon - dead upstream. (no website anymore)
ebview- no idea since its japanese.
endeavour - might work with gtk2? upstream is alive.
pixelize  - dead upstream. (last release 2000-01-17)
vertex- might work with gtk2? upstream is alive.

kdegraphics requires being able to link to imlib with png3 to work due
to png symbol collisions.


Why aren't we working to get rid of libpng2 anyway, libpng3 isn't even
current anymore.

Sources
---
libpng2- 134
libpng3-  23
libpng12-0 - 185

Of the ones linked to libpng2 about 20 of those are KDE related and will
go away soon (all associated packages have RC bugs). Many of the others
seem to link to libpng2 only due to maintainers not updating their
build-depends, like zsnes.

Chris

Re: multiarchitecture binaries - technical obstacles?

[Anthony DeRobertis]

On Mon, 2003-04-14 at 15:18, Barak Pearlmutter wrote:
> Years ago, NeXT modified GCC and the rest of the GNU tools to allow
> them to produce multi-architecture binaries, so that a single binary
> executable could run on both 68k and i386 platforms. 

I don't think that was with ELF. Was it Mach-O?


signature.asc
Description: This is a digitally signed message part

Re: imlib-linked-with-libpng3

[Chris Cheney]

By the way RedHat does it is as follows:

imlib-1.9.13-12.i386.rpm

/usr/lib

libgdk_imlib.so.1
libgdk_imlib.so.1.9.13
libimlib-bmp.so
libimlib-gif.so
libimlib-jpeg.so
libimlib-png.so
libimlib-ppm.so
libimlib-ps.so
libImlib.so.11
libImlib.so.11.0.0
libimlib-tiff.so
libimlib-xpm.so

ldd libImlib.so.11
--
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40035000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40052000)
libungif.so.4 => /usr/lib/libungif.so.4 (0x40095000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4009c000)<- ***
libz.so.1 => /lib/libz.so.1 (0x400c4000)
libm.so.6 => /lib/libm.so.6 (0x400d1000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x400f3000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400fb000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4011)
libc.so.6 => /lib/libc.so.6 (0x4011d000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4022d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
libdl.so.2 => /lib/libdl.so.2 (0x402e8000)

Perhaps it would be a good idea for debian to rebuild against newer
libraries... since otherwise we will always have these old libs in our
archive and we also knowingly become incompatible with other dists.

Chris

Re: imlib-linked-with-libpng3

[Chris Cheney]

On Fri, Apr 18, 2003 at 08:43:45PM -0400, Steve M. Robbins wrote:
> Imlib is more-or-less dormant upstream.  However, in late August, I
> was under the impression that upstream imlib was going to release a
> new version (with new SONAME) that would be linked with libpng3.  In

I forgot to comment on this part.  Its not upstreams place to deal with
what a particular user of the software decides to link stuff with. If
you break ABI that is no reason to mess with the ABI numbering which is
what SOVER's are for. This was already discussed to death in numerous
other threads the one that most readily comes to mind was the gcc c102
thread. In Debian's case if you break ABI you are supposed to add some
sort of differenation to the package name, such as imlib1foo and make
it conflict with the old version. From what I am able to tell, other
dists just rebuild against the current versions of libraries and don't
bother with renaming the packages themselves.

Chris

my computer

[JmGll3]

trying to fix my desktop setting  on my computer

Re: why do we care about configuration files?

[Anthony DeRobertis]

Is it just me, or would this fix the problem simply:

   1) If a postinst generates a configuration file with debconf, it
  must place the md5sum of the generated configuration file in
  /var

   2) A package should try and parse the current configuration file
  back into debconf before prompting.

   3) After prompting, the package must confirm that the current
  md5sum matches the one stored in /var. If it does and the
  package succeeded at (2) it may replace the configuration
  file. Otherwise, use ucf.


signature.asc
Description: This is a digitally signed message part