Subject: Bug#3459: inn should Depend on inewsinn, not contain it

From: Ian Jackson <[email-masked]>, Stephen Early <[email-masked]>, Owen Dunn <[email-masked]>
Date: Mon, 1 Jul 96 14:38 BST

Package: inn
Version: 1.4unoff4-1

 Replaces: inewsinn
 Provides: news-transport-system, inews
 Depends: libc5, cron, mail-transport-agent
 Recommends: news-reader
 Conflicts: inewsinn, news-transport-system, inews

The inn and inewsinn packages should be reorganised so that INN
depends on inewsinn, rather than conflicting with it.
This will make installing and removing INN with dselect much easier.

`Replaces: inewsinn' is not appropriate in this context.

Furthermore, `Recommends: news-reader' should be
`Recommends: trn | news-reader', so that there is a sensible default.

(This bug was encountered during a test installation of 1.1 done by
the three of us.)

Ian.

---

From: Ian Jackson <[email-masked]>, Stephen Early <[email-masked]>, Owen Dunn <[email-masked]>
Date: Mon, 1 Jul 96 15:36 BST

Package: inn
Version: 1.4unoff4-1

/etc/news/inn.conf is a dpkg-handled conffile, but is also modified by
the package's scripts.  It should not be included in the package;
instead, the postinst should create it if necessary.

We saw `INN is being upbraded from [illegible -iwj] to 1.4unoff4'
when we were doing an initial installation.

The default Path should be the machine's FQDN, not news.<domain>.

You can type `..' as your hostname.

Status/error messages should be sent to `news' (an existing username)
rather than usenet.  The script should check whether the `news' and
`usenet' mail aliases exist before trying to or asking whether to
create them.

The program should not create linux.*, comp.os.linux.*, &c because
they're `often used newsgroups'.  Doing this will merely result in
people having out of date news hierarchies on their server.  Create
local.test and local.general only, please.

Ian.

---

From: Ian Jackson <[email-masked]>, Stephen Early <[email-masked]>, Owen Dunn <[email-masked]>
Date: Mon, 1 Jul 96 15:21 BST

Package: auctex
Version: 9.3c-2

auctex says:
  You need to build AUC TeX auto-load files.  You can do this right
  now if you want.  Since this takes a long time, we will fork the
  process and leave the report in /tmp/TeX-auto-generate-global.out.
  If you want to build them later, or ever need to update the files,
  run the program /usr/sbin/auctex-auto-load.

  Would you like to build the auto-load files now [Y/n]?

Either the information in /tmp/wotsit is irrelevant, in which case it
should be sent to /dev/null or /var/log or some such, or it is
important, in which case it should be shown to the user in the
foreground.

It seems likely that errors during the generation wouldn't be caught
if the thing is run in the background.

Ian.

---

From: "James A. Robinson" <[email-masked]>
Date: Mon, 01 Jul 1996 17:08:46 -0400

> important, in which case it should be shown to the user in the

The information is not irrelevant, and will a) tells the person
whether or not the build succeeded, and b) tells the person when the
thing is complete.

i am not going to change the way I do this unless I am given a better
argument.  The generation of the files may easily take an hour on a
386, and I am not going to force the person to sit through it when it
can either do it later or just have it work in the background.

> if the thing is run in the background.

The script outputs STDOUT and STDERR to the file.  If they are too
silly to check it after being told what is going on, then that can't
be helped, can it?  

Whether or not the script has a problem with the build should not
affect dpkg -- at this point the package is installed properly.  What
the script does is build the knowledge base of what the user has on
their system by way of TeX style files.  This is part of the install
really, but is not vital for the package to work.  Therefore it does
not matter to dpkg whether or not it succeeds.

Jim

---

From: Lars Wirzenius <[email-masked]>
Date: Tue, 02 Jul 1996 06:14:23 +0300

> silly to check it after being told what is going on, then that can't

How about mailing it to root, if /bin/mail is available?

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Tue, 2 Jul 1996 13:25:04 +0200 (MET DST)

> This will make installing and removing INN with dselect much easier.

Ah. Good idea. However, the inewsinn and inn package have some things in
common; for example the manpage "inn.conf.5" is in both packages.

> `Replaces: inewsinn' is not appropriate in this context.

But in the other case it would be, because some files are in both
packages? What happens if you remove inn but keep inewsinn? Will that
remove the manpage or will dpkg realize that it's also part of inewsinn?

> `Recommends: trn | news-reader', so that there is a sensible default.

Matter of taste ofcourse. However I share your taste; trn is my news
reader of choise so I'll change that ;)

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Tue, 2 Jul 1996 13:34:37 +0200 (MET DST)

> instead, the postinst should create it if necessary.

Okay, no problem. However if I change inn to depend on or recommend
inewsinn, how will inn know wether it should remove /etc/news/inn.conf
when it is purged? inewsinn might still be installed and it might need
it. Hmm, perhaps a test by calling dpkg.. ugly though..

> when we were doing an initial installation.

Yes, I just noticed that (yesterday). The postinst script checks its
arguments and if $1 is configure and $2 != *unknown* it assumes
it is an upgrade. However newer dpkgs seem to pass an empty string
instead of "<unknown>" as the 2nd argument!

> The default Path should be the machine's FQDN, not news.<domain>.

I was just trying to emphasize that fact that one should name its
primary newsserver news.DOMAIN.

> You can type `..' as your hostname.

;) A "Restart" possibility might be nice ("are these values correct [Y/n] ")

> rather than usenet.

That *is* existing practice though, in all installations I've seen.

> The script should check whether the `news' and

It does. 
$usenet = 0;
if (open(FD, "/etc/aliases")) {
  while(<FD>) {
        if (/^usenet\s*:/i) {
                $usenet = 1;
                last;
        }
  }
  close FD;
}

> local.test and local.general only, please.

There might be something to say for that. I'll put more complete files
under /usr/doc/examples/inn, with a big disclaimer next to them.

> (This bug was encountered during a test installation of 1.1 done by

Which three? What are you setting up? A debian news server?

Mike.

---

From: [email-masked]
Date: Tue, 2 Jul 1996 23:03:57 +0200 (MET DST)

> > instead, the postinst should create it if necessary.

I would like to jump into this.  What about changing the config file
handling a little.  Making the md5sum available in the
/var/lib/dpkg/info/*.conffiles so that they can be easily changed by scripts
rather than that scripts need to acces the status file.  Why would I want to
do this:

- providing 'certified' scripts the oppertunity of handling configuration
files, and let dpkg think that the config file is up to date and ok.

Erick Branderhorst  http://www.iaehv.nl/users/branderh/

---

From: [email-masked] (Kai Henningsen)
Date: 06 Jul 1996 14:28:00 +0200

> files, and let dpkg think that the config file is up to date and ok.

An idea I've had for some time:

Provide some way for a package to denote package-managed files, such as  
could conflict with other packages, or be usefully removed on remove or  
purge.

This would make four classes of files:

normal        in .deb, installed & removed routinely by dpkg
conffile      in .deb, installed by dpkg, removed on purge
dynamic file  created by install scripts (maybe also later?),
              removed by dpkg (like old-style perl header files)
dynamic conf. created by install scripts, removed on purge

The install scripts should probably feed back a list of such files to dpkg  
- the list itself may be dynamic.

(Still another possible option would be jointly-owned files, probably  
always dynamic conffiles - like an inn.conf also needed by inewsinn, or a  
font directory for X. Dpkg would only remove these when purging the last  
owner.)

MfG Kai

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 19:58 BST

There is already one package, the Netscape installer, that expects
random files that it needs to be found in /tmp, and another, auctex,
which puts random stuff there.

IMO /tmp is unsuitable for these things because:

(a) It is a shared directory and thus has undesirable security
properties.

(b) It is often regularly cleaned by cron and bootup scripts or
mounted using volatile filesystems, so that data in it is not safe.

(c) It is not somewhere where sysadmins can be expected to look.

To my mind a better (default) place would root's home directory or a
subdirectory of it.  I propose that we decide on a name for this
application, and have packages use that.  If the admin wants the files
in ~root directly or elsewhere then they can make a symbolic link.

As a starting suggestion I propose the name `debian-pkg-stuff'.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 19:54 BST

James A. Robinson writes:
> [Ian Jackson:]

But it doesn't.  In practice it just sits there until some cron script
removes it again.

> can either do it later or just have it work in the background.

You should at least give the user the option of running it in the
foreground - and of course you need to make sure that it doesn't
generate lots of junk output, then.

You also really ought to provide some mechanism that will ensure that
the user gets told if there's an error.

...
> silly to check it after being told what is going on, then that can't

This IMO is not a good attitude towards users.  They are installing a
large and complex piece of software - an operating system - on their
computer, and I wouldn't consider expecting this kind of presence of
mind to be reasonable.

> not matter to dpkg whether or not it succeeds.

Does it matter to the user ?  If so then whether it has succeeded
should be communicated via dpkg, so that dpkg won't think the package
is properly installed.  If not then surely the output in the file is
not important and could be discarded ...

Finally, I don't think that /tmp is the right place for this file.
How about ~root ?

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 20:15 BST

Miquel van Smoorenburg writes ("Re: Bug#3462: INN postinst and configuration problems"):
..
> Which three? What are you setting up? A debian news server?

The three people who were in the From line of the original bug report.
Stephen Early, Owen Dunn and myself.  It seems that your mailer can't
handle that.  See our other bug reports.

We were doing a test installation, not setting anything up !

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 20:21 BST

> files, and let dpkg think that the config file is up to date and ok.

Absolutely not.  I'm not having random maintainer scripts messing with
dpkg's internals.

The right way to do this is to not make the thing a conffile at all.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 20:13 BST

...
> common; for example the manpage "inn.conf.5" is in both packages.

So put it in the inewsinn package.  If inn depends on it then it will
be installed.

> reader of choise so I'll change that ;)

No, it's not a matter of taste here - we should make the default be
the same everywhere :-).

Ian.

---

From: "James A. Robinson" <[email-masked]>
Date: Tue, 09 Jul 1996 17:26:25 -0400

> But it doesn't.  In practice it just sits there until some cron script

Erm, whatever.

> generate lots of junk output, then.

Ok on the first part, _no_ on the second.  If you want it in the
foreground find, but I'm not going to waste my time parsing it. If you
want to take over, or find somebody who does, fine.

I'll make it so that If there is an error it will exit with status -1.

> This IMO is not a good attitude towards users.  They are installing a

Well, you HO is different from MO.

> not important and could be discarded ...

Please back up your assertion.  Did you understand what I wrote
before?

> Finally, I don't think that /tmp is the right place for this file.

Sure.

Jim

---

From: Ian Jackson <[email-masked]>
Date: Wed, 10 Jul 96 01:34 BST

Kai Henningsen writes ("Conffiles &c. (Was: Re: Bug#3462: INN postinst and configuration probl"):
...
> could conflict with other packages, or be usefully removed on remove or  

Something like this, at least for the benefit of dpkg --search, is on
the wishlist.

> dynamic conf. created by install scripts, removed on purge

I don't plan to have dpkg try to remove anything it didn't create -
that sounds like a recipe for trouble.

Ian.

---

From: [email-masked] (Kai Henningsen)
Date: 10 Jul 1996 10:01:00 +0200

[email-masked] (Ian Jackson)  wrote on 10.07.96 in <[email-masked]>:

> Kai Henningsen writes ("Conffiles &c. (Was: Re: Bug#3462: INN postinst and
> configuration probl"): ...

I don't quite see why this would be any more trouble than the current  
behaviour.

I do see how it could be less trouble.

And anyway, you could argue that if the install scripts (that are executed  
by dpkg) do it (and tell dpkg about it), then these files _are_  
effectively created by dpkg.

MfG Kai

---

From: Buddha Buck <[email-masked]>
Date: Wed, 10 Jul 1996 17:16:16 -0400

> IMO /tmp is unsuitable for these things because:
	[Reasons against /tmp deleted]

In addition, I have /tmp on a small partition, since I don't expect much
to go there.   An installation of Netscape is a killer.

> As a starting suggestion I propose the name `debian-pkg-stuff'.

I would prefer a directory under /var/lib/dpkg myself.  Dpkg-ftp 
already 
places temporary files under /var/lib/dpkg/methods/ftp, so I think
a /var/lib/dpkg/tmp would be a reasonable choice.

--
     Buddha Buck                      [email-masked]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

---

From: "James A. Robinson" <[email-masked]>
Date: Wed, 10 Jul 1996 16:46:06 -0400

> (a) It is a shared directory and thus has undesirable security

You should submit to the FSSTND that they add to the definition of
/tmp to indicate this concern.  

> mounted using volatile filesystems, so that data in it is not safe.

Ok, does Netscape rely on the data being there for installation?  I
know AucTeX doesn't.

> (c) It is not somewhere where sysadmins can be expected to look.

Perhaps you're different from many of us, but when I read that I
should look in /tmp, I usually think I should look in /tmp.  Granted a
package should not stick any semi-important stuff in /tmp without
telling you.

> As a starting suggestion I propose the name `debian-pkg-stuff'.

This general concept sounds fine -- but are you sure people will want
~root cluttered up?  I know that I would not; which is why I used /tmp
in the first place (from the FSSTND, it seemed like the ideal place
for a temporary logfile).  Perhaps a /var/lib/dpkg/ subdirectory would
be better, especially if this is stuff packaged up with dpkg.

Jim

---

From: Lars Wirzenius <[email-masked]>
Date: Thu, 11 Jul 1996 08:11:15 +0300

[ NB: I read the list.  Don't CC replies to me.  I pay for my PPP.  Thanks ]

> As a starting suggestion I propose the name `debian-pkg-stuff'.

Is it really necessary to force a standard location?  Can't the script
just ask the filename?  A default is OK, but it should not be forced.
Something along the lines of:

	f=/root/debian-pkg-stuff/netscape-1.2.3.4.5.tar.gz
	if [ ! -f "$f" ]
	then
		echo "Original Netscape package (netsacpe*.tar.gz) not found."
		echo "(Looked in $f)"
		echo -n "Enter correct location: "
		read f
	fi

The answer might even be stored in /etc/default/netscape...

---

From: Lars Wirzenius <[email-masked]>
Date: Fri, 12 Jul 1996 15:34:29 +0300

> ~root cluttered up?  I know that I would not; which is why I used /tmp

Some people will object to /tmp, others to ~root.  I object to both.
Why not ask for a suitable pathname, and give a suitable default?
And, if /usr/bin/mail is available (it often is), offer to mail the log
file, or at least a notification (ask for the address to mail it to, as
well, since mail to root might be shared and the log file of interest only
to one person).

---

From: "James A. Robinson" <[email-masked]>
Date: Sat, 13 Jul 1996 15:51:01 -0400

> Why not ask for a suitable pathname, and give a suitable default?

Because then we would have to check that they didn't stick in

	/etc/passwd

or something.  We can't just say "if (!-f file" because it might be a
legitimate file from a previous install.  And I don't want to get into
opening the file to check the contents... :-(

> file, or at least a notification (ask for the address to mail it to, as

Ok, you suggested this before, and I'm sorry I didn't get back to you
on it.  This sounds like a fine idea, but is mail doing local delivery
something we can rely on if the /usr/bin/mail is there?  I mean, what
if they install smail, mailx, and auctex at once -- does smail get set
up before auctex? (I don't know the answer -- this is a serious
question.)

This reminds me, has anybody else had a problem with smail not setting
up an aliases driver?  I had to fix such a problem on my system to get
/etc/alias working -- but I could have screwed something up earlier
and forgetten about it.

Jim

---

From: Guy Maor <[email-masked]>
Date: Mon, 15 Jul 1996 10:46:15 -0500 (CDT)

> opening the file to check the contents... :-(

Doing 'dpkg -S $file' is better, but I don't think we should go too far
down this path.  Assuming a few connected neurons in the installer's
brain is reasonable.

(or not...)

Guy

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 02:25 BST

James A. Robinson writes ("Re: Installer packages and arbitrary files
> /tmp to indicate this concern.  

This is not within their scope, I think.  Anyway, the FSSTND group are
too busy reorganising /var to make it BSD-compatible and retargeting
themselves not to be Linux-specific and flaming me for not liking it.
Bitter, me ?  Never.

> Ok, does Netscape rely on the data being there for installation?  I

Yes, it does.

> package should not stick any semi-important stuff in /tmp without

I just think that /tmp is rather out of the way.  Look, I'm not trying
to get at you here, honest !  I'd just like to see a consistent and
sensible policy on this issue.

> be better, especially if this is stuff packaged up with dpkg.

/var/lib/dpkg is definitely inappropriate.

Would everyone be happy if I changed the guidelines to say that things
like this (output from scripts that needs to be dumped somewhere, and
files that packages, eg installer packages, need to read to install)
should have a filename prompted for, and that the default should be
~root/<packagename><somethingorother> and preferably kept in some way
from one installation to the next ?

Do we need a special file in /etc giving a default directory name for
this ?

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 02:28 BST

Buddha Buck writes ("Re: Installer packages and arbitrary files referenced by   packages "):
...
> a /var/lib/dpkg/tmp would be a reasonable choice.

(a) Packages shouldn't mess with /var/lib/dpkg (dpkg-ftp is in some
sense part of dpkg, so it has an excuse - it owns
/var/lib/dpkg/methods/ftp).

(b) Users should certainly not be encouraged to mess with
/var/lib/dpkg !  Reading it is fine, fair enough, but if they go
around editing stuff it will probably break something.  I don't think
that using /var/lib/dpkg in a published interface is at all a good
idea.

(c) It needs to be prompted for, since obviously everyone has
different ideas.

(d) I think ~root is much better as a default.  /home is for people
and programs they communicate with; /var is for programs to store
their internal guts.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 13:52 BST

...
> I don't quite see why this would be any more trouble than the current  

The boundary between dpkg and packages is getting rather fuzzy; this
makes debugging difficult.

It is better for packages to take responsibility for a file, or for
dpkg to take responsibility for it, than to have some kind of mixed
scheme.

Look what has happened to the sys[k]logd packages, which try to mess
with dpkg's conffiles in their maintainer scripts ...

Ian.

---

From: [email-masked]
Date: Tue, 16 Jul 1996 15:09:04 +0200 (MET DST)

> from one installation to the next ?

I would be happy if this would go in the guidelines. What else is ~root
intended for than these kind of things? It must be good for something!

Additionally I would like to see some kind of standardized interface 
like we have we conffiles at this moment.  It can be very handy is 
one can shell out to inspect situation in this situations (grab the
netscrape tar.gz or something).

> Do we need a special file in /etc giving a default directory name for

The directory name is in the concept of unix all ready: ~root

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 14:19 BST

James A. Robinson writes ("Re: Installer packages and arbitrary files referenced by packages "):
> [ Lars: ]
> or something.

Nonsense.  If we give them a sensible default and then they type in
/etc/passwd then that's their fault.

We can't stop them from screwing up their system like this.  By this
logic we should change bash so that you can't do
  $ >/etc/passwd RET
either.

...
> up before auctex? (I don't know the answer -- this is a serious

No, unfortunately you can't guarantee that it will be.  However, it's
quite OK to use dpkg --list or dpkg --status to check to see whether
mailx is configured.

Ian.

---

From: [email-masked] (Emilio Lopes)
Date: Tue, 16 Jul 96 17:01 EST

>>>>> "IJ" == Ian Jackson <[email-masked]> wrote:

IJ> Would everyone be happy if I changed the guidelines to say that
IJ> things like this (output from scripts that needs to be dumped
IJ> somewhere, and files that packages, eg installer packages, need to
IJ> read to install) should have a filename prompted for, and that the
IJ> default should be ~root/<packagename><somethingorother> and
IJ> preferably kept in some way from one installation to the next ?

Seems very reasonable.

IJ> Do we need a special file in /etc giving a default directory name
IJ> for this ?

Nice idea, but not necessary.

Emilio.

-- 
                 Emilio C. Lopes <mailto:[email-masked]>
               Instituto de Fisica da Universidade de Sao Paulo
             Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL
              Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)

---

From: Christian Hudon <[email-masked]>
Date: Wed, 17 Jul 1996 06:51:12 -0700 (PDT)

> from one installation to the next ?

And personally I'd be happy with any default location as long as packages
always prompt.

For some people ~root is on the (small) root partition while /tmp is a
symlink to the (roomier) /var/tmp on the var partition. But hey, if it
prompts then what do I care.

  Christian

---

From: "James A. Robinson" <[email-masked]>
Date: Thu, 18 Jul 1996 16:16:33 -0400

> /etc/passwd then that's their fault.

I disagree with this.  In following up with what somebody said
earlier, everything we have done with dpkg and Debian in general seems
to stem from the believe that we _don't_ assume the installer has a
few firing neurons.  That aside, I think we should at least check to
see if the file exists, and then warn then about it -- with a default
of no overwrite.

> We can't stop them from screwing up their system like this.  By this

Sure we can.  If they do it from the root prompt in a shell, that
isn't our problem.  But if that do it from a Debian provided
installation program, we can and probably should watch for things like
that.

> quite OK to use dpkg --list or dpkg --status to check to see whether

Hmm...  I really hate to slow the install down more then needed, but I
guess I will add this.  If I write a perl script that accepts as an
argument the program to run and the default output file and gives a
prompt for mailing, output to screen, or output to file, can it be
included in dpkg?  It seems wasteful to have everybody writing the
same code for the same process.

Jim

---

From: Ian Jackson <[email-masked]>
Date: Fri, 19 Jul 96 21:56 BST

> installation program, we can and probably should watch for things like

dpkg -S takes 3.5 seconds on my 32Mb Cyrix 5x86/120 with /var on a
9.5ms SCSI disk.

On my 8Mb 486/33 laptop it takes 7.8 seconds.

On a 4Mb machine it will probably take more like 20.

Is this really appropriate at this point ?

> Hmm...  I really hate to slow the install down more then needed,
>  [...]

And now you're worrying about dpkg --status, which takes around a
quarter of that time ?  :-)

>  but I

Yes, that would be great.

The default output file should be just a plain filename, so that the
script specifies the default directory.

Ian.

---

From: "James A. Robinson" <[email-masked]>
Date: Fri, 19 Jul 1996 23:11:21 -0400

> dpkg -S takes 3.5 seconds on my 32Mb Cyrix 5x86/120 with /var on a

Well, it takes a _lot_ longer on a 386DX33 w/4 megs of RAM.  I've
haven't worked on that machine for awhile, but doing a Debian install
on it was very painful.  It tooks _hours_ to finish.

> script specifies the default directory.

Ok, I will start working on one and submit it to you.

Jim

---

From: [email-masked] (Kai Henningsen)
Date: 21 Jul 1996 19:13:00 +0200

> makes debugging difficult.

I certainly don't see how this proposal could have that effect.

> with dpkg's conffiles in their maintainer scripts ...

There's an important difference. I was proposing that there be an official  
interface. (And one with fairly simple semantics, too.)

MfG Kai