From debian-devel@pixar.com Mon Jun  6 21:18:02 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA29178; Mon, 6 Jun 94 21:17:54 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qAqdI-0007sqa; Mon, 6 Jun 94 19:11 PDT
Date: Mon, 6 Jun 94 19:11 PDT
Message-Id: <199406070207.TAA03768@bismarck.egbt.org>
Errors-To: bruce@pixar.com
Reply-To: ian@egbt.org
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Ian McCloghrie <ian@egbt.org>
To: debian-devel@pixar.com
Subject: Re: twm in xbase 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

On Jun 6, 1994 Daniel Quinlan wrote:
> I, of course, agree that twm should be included, but I'd like to offer
> the suggestion that each window manager's default setup be similar in
> nature (background menus, window placement, etc.) for purely aesthetic
> reasons.

Hmmm... I'd suggest leaving /usr/X11/lib/twm/system.twmrc (or whatever
it's called) the way it comes from MIT.  People are used to working
with that as a base.

> Personally, I'd like to see tvtwm included as well... perhaps even
> lieu of twm since it is compatible with twm and adds the all important
> "v" factor (virtual).

I like tvtwm as well, but it's a bit... quirky.  It's supposed to be
100% compatible, but there's a few things broken.  Probably better to
leave it as an option.

--
____
\bi/  Ian McCloghrie      | FLUG:  FurryMUCK Linux User's Group
 \/   email: ian@ucsd.edu | Card Carrying Member, UCSD Secret Islandia Club
GCS (!)d-(--) p c++ l++(+++) u+ e-(soon) m+ s+/+ n+(-) h- f+ !g w+ t+ r y*

From debian-devel@pixar.com Mon Jun  6 21:31:54 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA29304; Mon, 6 Jun 94 21:31:52 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qAqqn-0007t5a; Mon, 6 Jun 94 19:25 PDT
Date: Mon, 6 Jun 94 19:25 PDT
Message-Id: <199406070224.AA02108@SunSITE.Unc.EDU>
Errors-To: bruce@pixar.com
Reply-To: mdw@sunsite.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@sunsite.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: twm in xbase
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian McCloghrie <ian@egbt.org> writes:
> Hmmm... I'd suggest leaving /usr/X11/lib/twm/system.twmrc (or whatever
> it's called) the way it comes from MIT.  People are used to working
> with that as a base.

Right. Include a facnier .twmrc in the skel directory for adduser
if you'd like, but the system.twmrc should be the one from MIT.

From debian-devel@pixar.com Mon Jun  6 23:21:00 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA29669; Mon, 6 Jun 94 23:20:57 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qAsYM-0007tea; Mon, 6 Jun 94 21:14 PDT
Date: Mon, 6 Jun 94 21:14 PDT
Message-Id: <199406071349.AA29211@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: DIST files and SysV packages
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Jackson wrote:

> Suggestions such as reading the tarfile twice or only reading the
> first part of it have arised from the requirement to extract the pre-
> and postinstall scripts and other administrative information before
> actually untarring all the files in the package.

Thanks for clearing that up. I did indeed have a large misunderstanding.

After sorting out my mental picture of what was going on, the only remaining
problem I can see is if one of the files in the package happen to end in
*.DIST, by chance.

The "control file" suggestion by mdw covers that though. You could change
*.DIST to *.DebianDIST, but I like my suggestion of a description field to
tell the user what the config file is for. :)

An alternative approach is that the control file could have the names of
config files to be preserved, rather than the *.DIST name.

  Eg, "PRESERVE=/etc/passwd" in the control file.

The front end can copy it before installing and then copy it back after
installing. This would mean that the file only gets listed once, and
packages can be put straight into the archive without files being renamed.

The file to be preserved could be copied to *.DebianOLD. The front-end would
be doing:

  if *.DebianOLD exists, then assume the copy has already been made.

So it wouldn't bugger up any files if the process was aborted and then
re-run.

I guess this is the same as your *.DIST suggestion, but from the opposite
direction. It certainly wouldn't be possible without the two archives,
reading it twice, or forcing tar to only read the first few bytes.

Now I understand that problem, I'd have to say that I personally prefer the
two archives approach. If packages are packed using the "*.DebianOLD" method
I've suggested above, then they can be unpacked straight out without the use
of Debian (making it useful to people with other distributions).

Then a Debian package descriptor file (like the *.lsm files on Sunsite) can
be used to update a dpkg package database so Debian can handle upgrades and
package removals.

Comments? I hope this is a lot better thought out than my earlier comments.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Tue Jun  7 06:07:54 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04236; Tue, 7 Jun 94 06:07:51 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qAyu8-0007tPa; Tue, 7 Jun 94 04:01 PDT
Date: Tue, 7 Jun 94 04:01 PDT
Message-Id: <199406071058.GAA18320@nova.umd.edu>
Errors-To: bruce@pixar.com
Reply-To: rockwell@nova.umd.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Raul Deluth Miller <rockwell@nova.umd.edu>
To: debian-devel@pixar.com
Subject: Re: DIST files and SysV packages
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White:
  After sorting out my mental picture of what was going on, the only
  remaining problem I can see is if one of the files in the package
  happen to end in *.DIST, by chance.
.
  The "control file" suggestion by mdw covers that though.

Not completely, it doesn't.

There's still a .dist file it [potentially] leaves around.  This is
something that could, in principle, be configured on a per-package
basis, but would be better handled in a /usr/adm/dpkg/ database of
some sort.  In other words, yet another complication to manage...

A better option [in my opinion]: don't make .DIST and .dist
configurable.

Unless there are major packages with instances of this problem [which
I doubt], I think it's better to leave this a "non-configurable
option".  It's mildly risky: maybe the author of package fooblitz
always uses a .DIST suffix for database files and .dist for
configuration files -- but then he probably switched to that
convention after finding that .o had problems.

Seriously, I recommend we don't solve this problem until it turns into
a problem.  If there are .DIST/.dist files in a distribution that
conflict with the debian usage they can always be renamed [.Dist or
-dist] and a note of explanation included.  I'd be more worried about
the novice administrator deleting the *.dist files.  But even there
the consequences are not all that severe.

In other words, is there any basis for thinking this is a real
problem?

Raul D. Miller
<rockwell@nova.umd.edu>

From debian-devel@pixar.com Tue Jun  7 08:27:01 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04629; Tue, 7 Jun 94 08:26:58 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB14l-0007tYa; Tue, 7 Jun 94 06:20 PDT
Date: Tue, 7 Jun 94 06:20 PDT
Message-Id: <m0qB166-0000Y2C@debra>
Errors-To: bruce@pixar.com
Reply-To: imurdock@murdoc.pnet.msen.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@murdoc.pnet.msen.com (Ian Murdock)
To: debian-devel@pixar.com
Subject: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Matt Welsh writes:
   dhs%firefly@uu5.psi.com (David H. Silber) writes:
   > 1)     If each package maintainer would update some central database (or
   > send the figures for the amount of space needed in each partition to a
   > diskspace document maintainer), a list could be provided and an installer
   > could add up the space used by the various packages which are to be
   > installed before partitioning the disk(s).
   
   Oh, this will be one of the jobs of the Debian front-end. Thank
   you for reminding me. It will determine what filesystems you
   have an how much space will be required on each due to package
   installation. I'll add it to the spec.

   You don't need to add lines to the package control file for this;
   it can be determined by using dpkg --contents. 

The problem with depending on `dpkg --contents' is that each package
will have to be available to the front-end as it is selected so that
the front-end can read the package for the disk usage summary.  This
is entirely reasonable to expect if installing from hard disk or
CD-ROM, but what about floppy disk?  The packages themselves will not
necessarily be available for reading.

The user will want to select all packages at once, with disk usage
totals updated per selection, without having to worry about changing
disks.  In order to do this, we would have to provide an independent
summary file, or, I suppose, make the feature unavailable to floppy
installations.

Reading disk usage information from the control file presents the same
problem.

From debian-devel@pixar.com Tue Jun  7 08:28:28 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04635; Tue, 7 Jun 94 08:28:25 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB16A-0007sfa; Tue, 7 Jun 94 06:21 PDT
Date: Tue, 7 Jun 94 06:21 PDT
Message-Id: <m0qAy1a-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: install-info
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

"James A. Robinson" writes ("install-info"):
> I don't know if it was my man package, but it could not handle Ian
> Jackson's man page for install-info(8).  I assume it failed to
> recognize the macros without the "." in them.  Here is one that works
> for my man docs, your mileage may vary.
> [ another copy with the `.'s deleted :-) ]

"James A. Robinson" writes ("ARGHHH"):
> Ok, I just learned something know about the mail system.  It stripped
> the blinking "." from the man page!  Is it just my machine?  If not,
> here is a uuencoded version.  Yesh.

It's not just your machine.  My own copy came back to me without the
`.'s.  This is almost certainly a bug in the SMTP dotstuffing very
close to pixar.com or even in the listserver.  Whom do we contact to
get it fixed ?

Unfortunately your uuencoded one, since it had to have the `.'s
manually reinserted, inevitably has a mistake or two.  Here is a
uuencoded copy of the one on my hard disk :-).

Ian.

begin 664 install-info.8
M+EPB($EN<W1A;&PM:6YF;R!A;F0@=&AI<R!M86YP86=E(&%R92!#;W!Y<FEG
M:'0@,3DY-"!B>2!)86X@2F%C:W-O;BX*+EPB"BY<(B!4:&ES(&ES(&9R964@
M<V]F='=A<F4[('-E92!T:&4@1TY5($=E;F5R86P@4'5B;&EC($QI8V5N8V4@
M=F5R<VEO;B`R"BY<(B!O<B!L871E<B!F;W(@8V]P>6EN9R!C;VYD:71I;VYS
M+B`@5&AE<F4@:7,@3D\@=V%R<F%N='DN"BY42"!)3E-404Q,+4E.1D\@."`B
M5F5R<VEO;B`P+C,B(")$96)I86X@1TY5+TQI;G5X(@HN4T@@3D%-10II;G-T
M86QL7"UI;F9O(%PM(&-R96%T92!O<B!U<&1A=&4@96YT<GD@:6X@26YF;R!D
M:7)E8W1O<GD*+E-((%-93D]04TE3"BY"(&EN<W1A;&Q<+6EN9F\*6UPM7"UV
M97)S:6]N72!;7"U<+6AE;'!=(%M<+5PM9&5B=6==(%M<+5PM;6%X=VED=&@]
M;FYN70I;7"U<+7-E8W1I;VX@<F5G97AP('1I=&QE72!;7"U<+6EN9F]D:7(]
M>'AX72!;7"U<+6%L:6=N/6YN;ET*6UPM7"UQ=6EE=%T@6UPM7"UM96YU96YT
M<GD]>'AX72!;7"U<+61E<V-R:7!T:6]N/7AX>%T@6UPM7"U=(&9I;&5N86UE
M"BY32"!$15-#4DE05$E/3@HN4%`*+D(@:6YS=&%L;"UI;F9O"FUA:V5S(&]R
M('5P9&%T97,@96YT<FEE<R!I;B!T:&4@26YF;R!D:7)E8W1O<GDL('1H90HN
M0B!D:7(*9FEL92X@($EF(&YO(&1E<V-R:7!T:6]N(&ES('-P96-I9FEE9"!O
M;B!T:&4@8V]M;6%N9"!L:6YE(&]R(&EN('1H90I);F9O(&9I;&4@:70@871T
M96UP=',@=&\@9W5E<W,@82!D97-C<FEP=&EO;B!F<F]M('1H92!C;VYT96YT
M<R!O9B!T:&4*9FEL92X*"E-E92!T:&4@9&5S8W)I<'1I;VX@;V8@=&AE"BY"
M(%PM7"US96-T:6]N"F]P=&EO;B!F;W(@9&5T86EL<R!O9B!W:&5R92!T:&4@
M96YT<GD@=VEL;"!B92!P;&%C960@86YD(&$@9&5S8W)I<'1I;VX*;V8@=&AE
M(&5X<&5C=&5D(&9O<FUA="!O9B!T:&4*+D(@9&ER"F9I;&4N"BY34R!/4%1)
M3TY3"BY44`HN0DD@(EM<+5PM72`B(&9I;&5N86UE"D=I=F5S('1H92!F:6QE
M;F%M92!O9B!T:&4@26YF;R!F:6QE('=H;W-E(&UE;G4@96YT<GD@:7,@=&\@
M8F4@8W)E871E9`IO<B!U<&1A=&5D+B`@5&AE(&)A<V5N86UE(&]F('1H:7,@
M9FEL96YA;64@:7,@=7-E9"!A<R!T:&4@<F5F97)E;G0@;V8*=&AE(&UE;G4@
M96YT<GD@=VAI8V@@:7,@8W)E871E9"P@<V\@=&AE(&9I;&4@;75S="!E>&ES
M="`H;W(@8F4@86)O=70*=&\@8F4@:6YS=&%L;&5D*2!I;B!T:&4@<V%M92!D
M:7)E8W1O<GD@87,@=&AE"BY"(&1I<@IF:6QE("AS964@=&AE"BY"(%PM7"UI
M;F9O9&ER"F]P=&EO;BDN"BY44`HN0DD@(EPM7"US96-T:6]N("(@(G)E9V5X
M<"!T:71L92(*4W!E8VEF:65S('1H870L(&EF(&$@;F5W(&5N=')Y(&ES('1O
M(&)E(&UA9&4L(&ET('-H;W5L9"!B92!P;&%C960@:6X@80IS96-T:6]N(&]F
M('1H90HN0B!D:7(*9FEL92!W:&]S92!T:71L92!M871C:&5S"BY)4B!R96=E
M>'`@+@I)9B!N;R!S=6-H('-E8W1I;VX@97AI<W1S(&]N92!W:6QL(&)E(&-R
M96%T960@87,@=&AE('-E8V]N9"!L87-T"G-E8W1I;VX@:6X@=&AE(&9I;&4@
M*'-E92!B96QO=RDL('=I=&@@=&ET;&4*+DE2('1I=&QE("X*02!S96-T:6]N
M(&ES(&$@<&%R="!O9B!T:&4*+D(@9&ER"FUE;G4@9&5L:6UI=&5D(&)Y(&)L
M86YK(&QI;F5S.R!T:&4@9FER<W0@;&EN92!I<R!A<W-U;65D('1O(&)E('1H
M90IT:71L92X*"DEF(&$@;F5W(&5N=')Y(&ES('1O(&)E(&-R96%T960*+D(@
M:6YS=&%L;"UI;F9O"G=I;&P@871T96UP="!T;R!I;G-E<G0@:70@=VET:&EN
M('1H92!S96-T:6]N(&%C8V]R9&EN9R!I;B!A;'!H86)E=&EC"F]R9&5R.R!I
M9B!T:&4@96YT<FEE<R!I;B!T:&4@<V5C=&EO;B!A<F5N)W0@86QR96%D>2!S
M;W)T960@=&AE(&YE=PIL;V-A=&EO;B!W:71H:6X@=&AE('-E8W1I;VX@=VEL
M;"!B92!U;G!R961I8W1A8FQE+B`@5&AE(&]R9&5R(&]F"F5X:7-T:6YG(&5N
M=')I97,@=VEL;"!N;W0@8F4@8VAA;F=E9"X*"E1H92!D969A=6QT(&ES('1O
M(&%P<&5N9"!N97<@96YT<FEE<R!T;R!T:&4@96YD(&]F('1H92!F:6QE+B`@
M5&AE(&QA<W0*<V5C=&EO;B`H979E;B!I9B!I="!O;FQY(&-O;G-I<W1S(&]F
M('1H92!T:71L92!L:6YE*2!S:&]U;&0@86QW87ES"F5X:7-T+"!T;R!E;G-U
M<F4@=&AA="!N97<@<V5C=&EO;G,@87)E(&-R96%T960@:6X@=&AE(')I9VAT
M('!L86-E+@I4:&4@9FEN86P@<V5C=&EO;B!S:&]U;&0@8F4@=&ET;&5D('1O
M(')E9FQE8W0@=&AE(&9A8W0@=&AA="!);F9O(&9I;&5S"G=I=&@@;F\@;6]R
M92!W96QL('-P96-I9FEE9"!L;V-A=&EO;B!A<F4@87!P96YD960@=&\@:70N
M"@I)9B!T:&5R92!I<R!A;')E861Y(&%N(&5N=')Y(&9O<B!T:&4@26YF;R!F
M:6QE(&)E:6YG(&EN<W1A;&QE9"!I="!I<PIR97!L86-E9"!I;B!S:71U('=I
M=&@@=&AE(&YE=R!E;G1R>2X*+E10"BY"22!<+5PM86QI9VX](&YN;@I3<&5C
M:69I97,@=&AA="!T:&4@9&5S8W)I<'1I;VX@<VAO=6QD(&)E(&EN9&5N=&5D
M(&%T(&QE87-T"BY)(&YN;@IC:&%R86-T97)S.R!E>'1R82!S<&%C97,@=VEL
M;"!B92!A9&1E9"!A<R!R97%U:7)E9"X@($EF(&YE8V5S<V%R>0IB96-A=7-E
M(&]F('1H92!L96YG=&@@;V8@=&AE"BY"(&1I<@IM96YU(&5N=')Y(&1E=&%I
M;',@=&AE(&1E<V-R:7!T:6]N(&UA>2!B92!O9F9S970@;6]R93L@:68@<V\@
M=&AE('=H;VQE"F5N=')Y('=I;&P@8F4@<VAI9G1E9"!A8W)O<W,N("!4:&4@
M9&5F875L="!I<R`R-RX*+E10"BY"22!<+5PM:6YF;V1I<CT@:6YF;V1I<@I3
M<&5C:69I97,@=&AA="!B;W1H('1H90HN0B!D:7(*9FEL92!A;F0@86X@:6YS
M=&%L;&5D(&-O<'D@;V8@=&AE(&YE=R!);F9O(&9I;&4@87)E(&QO8V%T960@
M:6X*+DE2(&EN9F]D:7(@+@I4:&4@9&5F875L="!I<PHN0E(@+W5S<B]I;F9O
M("X*+E10"BY"22!<+5PM;6%X=VED=&@](&YN;@I3<&5C:69I97,@=&AA="!T
M:&4@;6%X:6UU;2!W:61T:"!F;W(@=&AE($EN9F\@9FEL92!I<PHN25(@;FYN
M("X*5&AI<R!I<R!U<V5D('=H96X@=V]R9'=R87!P:6YG('1H92!D97-C<FEP
M=&EV92!T97AT+@I4:&4@9&5F875L="!I<R`W.2X*+E10"BY"(%PM7"UQ=6EE
M=`I0<F5V96YT<R!T:&4@=7-U86P@9&ES<&QA>2!O9B!T:&4@;F5W(&UE;G4@
M96YT<GD@:G5S="!B969O<F4@:70@:7,*:6YS97)T960L(&%N9"!T:&4@;65S
M<V%G97,@=VAI8V@@;F]T92!T:&4@<F5P;&%C96UE;G0@;V8@86X@97AI<W1I
M;F<*96YT<GD@86YD('1H92!C<F5A=&EO;B!O9B!A(&YE=R!S96-T:6]N+@HN
M5%`*+D(@7"U<+6AE;'`*0V%U<V5S"BY"(&EN<W1A;&PM:6YF;PIT;R!D:7-P
M;&%Y(&ET<R!U<V%G92!I;F9O<FUA=&EO;B!A;F0@97AI="X*+E10"BY"(%PM
M7"UV97)S:6]N"D-A=7-E<PHN0B!I;G-T86QL+6EN9F\*=&\@9&ES<&QA>2!I
M=',@=F5R<VEO;B!A;F0@8V]P>7)I9VAT(&EN9F]R;6%T:6]N(&%N9"!E>&ET
M+@HN5%`*+D))(%PM7"UD97-C<FEP=&EO;CT@>'AX"E-P96-I9FEE<R!T:&%T
M('1H92!D97-C<FEP=&EO;B!T;R!U<V4@869T97(@=&AE(&UE;G4@96YT<GD@
M8F4*+DE2('AX>"`N"E1H92!D969A=6QT(&ES('1O('5S92!T:&4@=&AE('9A
M;'5E('-P96-I9FEE9"!I;B!T:&4@26YF;R!F:6QE(&ET<V5L9CL*=&AI<R!I
M<R!F;W5N9"!B>2!S96%R8VAI;F<@9F]R(&$@<V5C=&EO;B!O9B!T:&4@9F]R
M;0HN8G(*+D(@4U1!4E1<+4E.1D]<+41)4EPM14Y44ED*+F)R"BY"("H@075T
M;RU01U`Z("AA=71O+7!G<"DN("!01U`@=6YD97(@1TY5($5M86-S+@HN8G(*
M+D(@14Y$7"U)3D9/7"U$25)<+45.5%)9"@I)9B!T:&ES(&ES(&YO="!P<F5S
M96YT('1H92!P<F]G<F%M('=I;&P@=')Y('1O(&9I;F0@82!P87)A9W)A<&@@
M96%R;'D*:6X@=&AE(&9I;&4@<W1A<G1I;F<*+D)2(")T:&ES(&9I;&4@9&]C
M=6UE;G1S(B`N"DET('=I;&P@<W1R:7`@86YY(&QE861I;F<*+D)2('1H92`L
M"F-A<&ET86QI<V4@=&AE(&9I<G-T(&-H87)A8W1E<B!O9B!T:&4@<F5M86EN
M9&5R+"!A;F0@=7-E('1H870N"@I)="!I<R!A;B!E<G)O<B!F;W(@;F]N92!O
M9B!T:&5S92!M971H;V1S('1O('EI96QD(&$@9&5S8W)I<'1I;VXN"BY44`HN
M0DD@7"U<+6UE;G5E;G1R>3T@>'AX"E-P96-I9FEE<R!T:&%T('1H92!E;G1R
M>2!I;B!T:&4@;65N=2!S:&]U;&0@8F4*+DE2('AX>"`N"E1H92!D969A=6QT
M(&ES('1O('5S92!T:&4@=&AE('9A;'5E('-P96-I9FEE9"!I;B!T:&4@26YF
M;R!F:6QE(&ET<V5L9BX*268@=&AI<R!I<R!N;W0@<')E<V5N="!T:&4@8F%S
M96YA;64@;V8@=&AE($EN9F\@9FEL92!I<R!U<V5D"BY20B`B*&%N>2`B("(N
M:6YF;R`B(")I<R!D96QE=&5D+"!A;F0@=&AE(&5N=')Y(&ES(&UA9&4@;6EX
M960@8V%S92DN(@I3964@86)O=F4@9F]R(&1E=&%I;',@;V8@=&AE(&9O<FUA
M="!E>'!E8W1E9"!F;W(@=&AE(&UE;G4@96YT<GD@:6X@=&AE"DEN9F\@9FEL
M92X*+E10"BY"(%PM7"UD96)U9PI%;F%B;&5S(&1E8G5G9VEN9R!M;V1E+"!I
M;B!W:&EC:"!T:&4@<F5S=6QT<R!O9B!S;VUE(&EN=&5R;F%L"G!R;V-E<W-I
M;F<@<W1E<',@87)E('-H;W=N+@HN4T@@(E-%12!!3%-/(@IE;6%C<R@Q*2P@
M:6YF;R@Q*0HN4T@@0T]065))1TA4"D-O<'ER:6=H="`Q.3DT+"!)86X@2F%C
M:W-O;BX*+D(@:6YS=&%L;%PM:6YF;PII<R!F<F5E('-O9G1W87)E.R!S964@
M=&AE($=.52!'96YE<F%L(%!U8FQI8R!,:6-E;F-E('9E<G-I;VX@,B!O<@IL
M871E<B!F;W(@8V]P>6EN9R!C;VYD:71I;VYS+B`@5&AE<F4@:7,*+DD@;F\*
*=V%R<F%N='DN"F]P
`
end

From debian-devel@pixar.com Tue Jun  7 08:29:11 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04640; Tue, 7 Jun 94 08:29:04 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB16m-0007soa; Tue, 7 Jun 94 06:22 PDT
Date: Tue, 7 Jun 94 06:22 PDT
Message-Id: <m0qAzNn-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Availability of Perl (was Re: partitioning & base vs installed /usr)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Raul Deluth Miller writes:
> Bill Mitchell:
>    What say we move perl to /bin, put a symlink in /usr/bin, and
>    retain a minimal functionality /usr/bin on the root partition,
>    mounting a full functionality /usr over top of the minimal one if
>    /usr/<whatever> is placed on a separate partition at install time.
> 
> Ugh..  do we have to?

Well, that depends.  Unless someone can come up with a better solution
I see the following range of alternatives:

  1. Ignore the problem, leave perl in /usr/bin.  This makes it
     impossible to reinstall from just the root partition and is
     generally a pain, but is very standard.  It does however make the
     root partition 200-odd K smaller.
  2. Put a copy of perl in /bin.  This wastes a lot of space (but only
     on the /usr partition, compared to 3, 4 and 5.)
  3. Put perl in /bin, with a link from /usr/bin, and make a `fake'
     /usr/bin on the root partition which can be mounted over,
     containing the required link.  This is somewhat ugly and will
     make backup/restore operations very painful.
  4. Put perl in /bin, with a link from /usr/bin on the real /usr
     partition only.  This requires changing the #! line on all
     Debian-specific installation/recovery Perl scripts to
     #!/bin/perl.  Unfortunately this is nonstandard, and might
     encourage package maintainers and users of Debian to distribute
     #!/bin/perl scripts, which won't work elsewhere.  (According to
     Larry Wall, perl belongs in /usr/bin.)
  5. Put perl in /bin with no links.  This is even worse - no scripts
     which haven't been specially hacked up for Debian will work.

Of these I favour 4 I think, but I'd really like to see someone come
up with a better solution or better arguments.

> /bin/perl seems like a good idea.
> 
> /usr/bin/perl -> /bin/perl seems like a decent compatability hack,
> if we need it [though, properly, I feel this should be a part of a
> compatability package or something, and not part of the base
> distribution]. 

It is definitely required.  Larry Wall's stated opinion (in a footnote
on the first dozen pages or so of the Perl book) is that Perl belongs
in /usr/bin, and so we should make it available there.  If we don't
then we'll find it increasingly difficult to port and use software
from elsewhere.

> /usr/garbage seems like a dreadful concept.  [I didn't know you could
> mount a partition over a directory which wasn't empty.  Even if
> possible it seems inefficient and pointless.]

It is possible, and can be useful sometimes.  If the directory that is
hidden by mounting over contains only symlinks it's not too bad
spacewise.  However, backup and restore, package maintenance, etc.
will be very awkward if we do this.

I don't understand where `/usr/garbage' came from.

Ian.

From debian-devel@pixar.com Tue Jun  7 08:35:33 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04680; Tue, 7 Jun 94 08:35:30 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB1D2-0007uOa; Tue, 7 Jun 94 06:28 PDT
Date: Tue, 7 Jun 94 06:28 PDT
Message-Id: <m0qAyTm-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Complaints about *.DIST
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Salvatore Valente writes ("Re: Complaints about *.DIST"):
> As for depending on the output of "tar": it's not necessary.  I can
> put in the control file:
> CONFIG_FILES: etc/mail.rc
> CONFIG_SUFFIX: DIST
> which can be used by the front end.  (Oops, just found out that mdw
> suggested this a few hours ago.)

This is a possibility; however it provides something else for the
package maintainer to get wrong.  It is silly to require them to
specify the same thing in two places.

How about simply allowing the CONFIG_SUFFIX to be specified just in
case some bozo has made their program require files called *.DIST, and
have the package installation software use the tar output to find them ?
Remember, it doesn't need to read the tarfile specially, just
capture the output during unpacking and use that.

Certainly in either case CONFIG_SUFFIX should be optional, defaulting
to *.DIST.

I'm trying to make life as easy as possible for package maintainers.
The easiest thing for them is to do as little as possible, and as
simple things as possible.  In this context this means just calling
configuration files *.DIST.

Matt Welsh writes ("Re: Private groups"):
> If you're concerned that there might be files called *.DIST that 
> are _meant_ to be called that, we can change the magic filename, or
> include a list of *.DIST files in the control file (i.e., not call
> them *.DIST, just include a list somewhere of files that can be
> updated in this way).

They mustn't be called the same as the actual configuration files, of
course, or the whole thing falls over (and even if you fix that it
becomes impossible to recover from a half-done botched upgrade).

Stephen White writes:
> The *.DIST scheme is more suited to a package with hundreds of configuration
> files that have to be preserved. If there were hundreds of files, then it'd
> be worth implementing something that complicated.

Remember, the whole of Debian is likely to have at least dozens if not
hundreds of configuration files - these will rapidly become a
maintenance nightmare if we don't solve the problem now.

Stephen White <steve@adam.com.au> writes:
> Another problem that occurs to me with the *.DIST scheme is - what
> happens if there are already some files ending with *.DIST or *.dist in
> the original package? It's not going to get caught in the packaging
> stage - it'll just screw up silently in the unpacking.

Why can it not be caught during the packaging stage ?  Surely there is
going to have to be a tool to assist in making packages.

Even if not, the package maintainer will notice that sie has to call
configuration files *.DIST and this will hopefully cause hir to notice
*.DIST files in their package that aren't config files.

Stephen White writes ("Re: Private groups"):
> The list of *.DIST files in a control file sounds good. It removes most of
> my problems with the scheme.

You have never clearly expressed your problems; most of your
complaints appear to be objections to something almost but not quite
completely unlike my *.DIST scheme.

> [someone, Matt Welsh perhaps, wrote:]
> > Even a package with one configuration file needs some kind of logic to
> > handle upgrades. I don't see why you want to force package maintainers
> > to write that logic into the postinst script by hand, when the dpkg
> > front-end can do it rather nicely.
> 
> Because I wanted to avoid having to read the tar file twice, force tar to
> only read the first few bytes, or have dpkg (front-end) search the entire
> disk.

Again, this (reading the tarfile twice or forcing it only to read the
first few blocks) has nothing to do with *.DIST or configuration
files.

> An idea; it won't make much sense to the user if it just says something
> like:
>     /usr/lib/X386/tvwm.config; update?
> Perhaps the control file can have the filename and a description field:
> /usr/lib/X386/tvwm.config.DIST   The configuration file to control the
>                                  overall behaviour of X-Window's tvwm
>                                  window manager.
> So it can present a more meaningful prompt?

This is a useful suggestion.  However, I'm not sure whether asking
package maintainers to do this is a good idea.  Perhaps it should be
made optional ?  Ie, if you like you can provide a section in the
control file which gives descriptions of the config files in your
package, but if you don't it works anyway and is just less informative
when it asks the installer.

Stephen White writes ("Re: DIST files and SysV packages"):
> [Someone, Matt Welsh perhaps, wrote:]
> > No... this forces package maintainers to write all of that logic
> > into the scripts, and leaves open the possibility that they will do
> > it incorrectly. Your solution is prone to human error.
> 
> But you don't realise that package maintainers _are_ writing all that logic
> anyway! But instead of writing the logic in a logical place like a script
> file, they're writing the logic as expressed by filenames.

No, they're expressing *one bit* per file in the filenames.
The bit that says "this is a configuration file".

> Instead of "rm filename" in the script, they create "filename.DIST" and
> "filename.dist" and let the frontend delete it instead. It's still the same
> logic!

You have clearly grossly misunderstood the proposal.  Please read it
again, notably the section entitled "from the point of view of the
package maintainer" rather than the section entitled "from the point
of view of dpkg" (I wrote it before I heard there was to be a separate
front-end program).

> Instead of a script test like "if [ -f /etc/passwd ]", you could simply
> have:
>   dpkgmate -notexist /etc/passwd /etc/passwd.DIST
> in the script.

This is not a good idea, because it places a much greater
responsibility on the package maintainers' shoulders.  Now they have
to remember the arguments to dpkgmate or whatever it is.  They also
(shudder) have to read its specification to decide what exactly it
does - the specification whose complexity you are objecting to.

If we do it automatically we just say "name config files *.DIST" and
the package maintainer can forget about exactly what is going to
happen - everything is just fixed automagically.

> Benefits? No need for multiple archives, no need to force tar to only read
> the first few bytes of an archive, no need to read the tar file twice, no
> need for version numbers (since the scripts can handle that).

See my recent message: you are once again confusing *.DIST with the
requirement to read the archive twice, etc.  They two having nothing
to do with one another.

Ian.

From debian-devel@pixar.com Tue Jun  7 08:37:00 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04725; Tue, 7 Jun 94 08:36:57 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB1EQ-0007v1a; Tue, 7 Jun 94 06:30 PDT
Date: Tue, 7 Jun 94 06:30 PDT
Message-Id: <m0qAyog-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Private groups
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White writes (rearranged):
> We have this weird directory setgid, private groups, and now the packaging
> is being buggered by some weird *.DIST scheme as well. Debian's going to get
> a reputation similar to Fred's LINUX-PRO system; it works, but it's weird.

This is not going to happen.  Both of these things will be invisible
to most users and *.DIST is invisible to sysadmins.  Admittedly the
sysadmin would have to be very stupid not to notice the user private
groups, but it is unlikely to significantly affect their activities,
except that sometimes it will make life a little easier.

User private groups is not a weird scheme, it is a tried and tested
one that has been used to great effect on many systems I have used.  I
have never known it cause problems of any kind (!).

Whether *.DIST is unusual or not is irrelevant.  It's not something
that will be visible to anyone except package maintainers, and even to
them most of it is hidden.  What people will see when they use it is
that things just *work* without fuss, and they'll like it.

> While I'm in this mood, I may as well bring up the hoary old saw again.
> I run a multi-user system with a couple of hundred users, and there are a
> couple of projects going on it. The users wanted to be able to work on the
> same files and share files. All I did was create a project ID, and give them
> the password. It's worked great. They're happily working on their projects
> with no trouble at all.
> 
> If my users need to transfer files, they just use FTP. However, copying
> between home and project directories rarely happens. Project work stays in
> the project directory, and personal files stay in personal directories.
> That's just the way it naturally happens.
>
> So can someone tell me just what advantage Private Groups provide that is so
> compelling as to implement a non-standard permissions scheme on all the
> users directories and fill up /etc/group?

It's not non-standard.  I have seen it used on many systems, and in
each case it works well and noone comments.

> All I can see is that they can use "cp" instead of "ftp" in the rare case of
> wanting to copy files. The disadvantages are the file ownerships not being
> consistent (hence no chgrp or chmod), and a non-standard permissions scheme.

You are making unwarranted assumptions about people's usage patterns.

You have also forgotten that userids on Unix are not just the unit of
access control but also of accountability.  Shared accounts are a Bad
Thing because they make it almost impossible to tell who did what to
whom.

> As for setgid on directories; Remy's been away, but he's back now and he
> still intends to make BSD mounting the default. This is going to bugger up
> Debian in a later kernel version if this happens.

I had assumed that the fact that Remy hasn't been replying to me
recently (I sent the most recent message on this topic to him on the
13th of April) meant that I'd convinced him that it was a bad idea.
My conversation with Remy has certainly convinced me that if it were
brought up on the KERNEL channel it would be quickly abandoned.

Debian (and anything else) would probably be buggered anyway if BSD
mounting was used.  However, that BSD mounting would bugger things up
and should not therefore be used is indeed exactly what I was saying
to Remy.  I'm glad to see that you agree.

> I'm not trying to be nasty, flame anyone, or prove a point. I really am
> getting depressed.

Perhaps you should try to understand what's going on first, then.  I'm
getting rather tired, I'm afraid, of having continually to correct
your misconceptions.

I think that if you consider the issues rationally without emotionally
attaching yourself to the way you currently want things done you'll
find that things are going the right way.

Ian.

From debian-devel@pixar.com Tue Jun  7 08:38:27 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04738; Tue, 7 Jun 94 08:38:24 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB1Fp-0007uCa; Tue, 7 Jun 94 06:31 PDT
Date: Tue, 7 Jun 94 06:31 PDT
Message-Id: <m0qAzAX-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: twm in xbase
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Matt Welsh writes ("twm in xbase"):
> I think that it would be a good idea to include twm in Debian's X package.
> I've spoken with several new Debian users who are annoyed at the fact that
> they can't port their .twmrc over to Linux and use twm, without downloading
> twm separately. It's all right if we want to be window manager bigots and
> push fvwm onto people, but let's not alienate old X users who prefer twm.

No, it's NOT all right to be "window manager bigots" and "push fvwm
onto people".  This is on exactly the same level as saying that vi is
better than emacs and we're only going to have vi.

Sorry to put this so strongly, but it is emphatically not our place to
say "thou shalt use this software".

twm is a standard part of X; an X distribution that does not include
it is incomplete.  There is no question that Debian's xbase package
should include twm by default, and quite frankly I was amazed and
horrified to find that at least one version of Debian didn't.

fvwm is the optional extra, not twm.

The question of what window manager to put in the default
configuration is entirely different, of course.

Ian.

From debian-devel@pixar.com Tue Jun  7 08:40:43 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04753; Tue, 7 Jun 94 08:40:41 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB1I2-0007usa; Tue, 7 Jun 94 06:34 PDT
Date: Tue, 7 Jun 94 06:34 PDT
Message-Id: <m0qAzj5-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Matt Welsh writes ("Re: Binary Package and Installation Tools Spec"):
> iwj10@cus.cam.ac.uk (Ian Jackson) writes:
> [...]
> > What about /usr/doc/copyright ?  If you like the idea we should
> > require that every package install a file in there.  
> 
> If you want a /usr/doc/copyright directory with files for each
> package, so be it. That's up to the filesystem standard, not
> dpkg. 

No, it's not up to the filesystem standard (or rather, I don't think
the FSSTND should be mandating it).  However, I think it would be very
useful.  I have attached a copy of my original message on the subject
here - I think it may originally have gone only to the debian-team
list.  ...  Err, it seems that I never posted a coherent summary, so
I'll write one now.

> > [A-Za-z][-A-Za-z0-9]{0,7} (do we want to use `_'s or `-'s ?  We should
> > specify which, for consistency, and I'd plump for `-'.)
> 
> I don't see why this is necessary.

Don't the names have to be valid DOS file basenames ?


The /usr/doc/copyright proposal:

That each package maintainer supply its copyright notice in
/usr/doc/copyright/<package> or make a symlink to or provide a file
referring to one or other of the two standard ones
/usr/doc/copyright/GPL and /usr/doc/copyright/BSD.  If a package is in
the public domain rather than copyrighted a statement to that effect
should be provided.

That means that the rather legalese-laden issue and motd can be made
at once more lightweight and more informative:

	 		*** Debian Linux 1.0 ***
 Copyright (C) 1994 Ian A. Murdock <imurdock@shell.portal.com> and others.
      Please see the file /usr/doc/copyright/README for information
   about copyright, licensing, lack of warranty and authorship details.

and you can scrap the top-of-program-source style `this is free
software' notice.

When I first proposed this someone suggested that it should be part of
the control file.  However, I think I disagree.  The control file is
for automatic processing, and the the copyright definitely isn't
amenable to being handled automatically - it's just there for
information.  It's really a piece of human-readable documentation
(hence my suggestion to put it in /usr/doc).

In any case, putting all this stuff in /usr/doc will almost certainly
make it much easier to comply with requirements that certain
information be given to people you give the software to, and also
probably with the ones that require that you list the authors.

The point of /usr/doc/copyright is not to serve as a copyright notice
(which clearly it can't do, it's too well placed/hidden).  The
purposes are:

1. To give the issue and motd somewhere to refer to, so that they
don't have to contain all the information themselves;

2. To have a single place to look for a package's copyright (even if
you don't have the source, or the installation documents, etc.).

We can only achieve 2 if every package is required to have a
/usr/doc/copyright/xyz file, even if only to say "xyz is in the public
domain".

Ian.

From debian-devel@pixar.com Tue Jun  7 09:23:54 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05024; Tue, 7 Jun 94 09:23:51 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB1xo-0007tna; Tue, 7 Jun 94 07:17 PDT
Date: Tue, 7 Jun 94 07:17 PDT
Message-Id: <m0qB1zh-0000Y2C@debra>
Errors-To: bruce@pixar.com
Reply-To: imurdock@murdoc.pnet.msen.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@murdoc.pnet.msen.com (Ian Murdock)
To: debian-devel@pixar.com
Subject: Re: Partition sizing and arrangement
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

charlieb@budge.apana.org.au writes:
   
   Back a long time ago, when perl was being rejected out of hand from the 
   base package, I suggested that one use for it would be to allow the 
   installation script to add up the disk used/disk free per partition as 
   packages were checked/unchecked, so that the partition decision could be 
   got right before installing. It's a very important decision in setting up 
   Linux, but there is very little guidance out there.

I would very much like to do it, but with the current setup it would
be impossible to combine disk partitioning and package selection, as
the former is done from the bootdisk and the latter is done from the
installed base system.  Would the ability to do this be considered a
valuable enough addition to move package selection and installation
back to the bootdisk, where it used to be?

At present, we could provide partitioning _suggestions_ on the
bootdisk based on available hard drive space, and as packages are
selected with the front-end from the installed base system, running
disk usage totals could indicate how much space is left on each
partition.  At least there would be a way to let the user know that
they might need to go back and repartition before committing to
installation.

Hmm.  Something to think about.

From debian-devel@pixar.com Tue Jun  7 09:49:33 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05313; Tue, 7 Jun 94 09:49:31 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB2Md-0007tra; Tue, 7 Jun 94 07:42 PDT
Date: Tue, 7 Jun 94 07:42 PDT
Message-Id: <9406071441.AA14054@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Murdock said:

>[...]
> The user will want to select all packages at once, with disk usage
> totals updated per selection, without having to worry about changing
> disks.  In order to do this, we would have to provide an independent
> summary file, or, I suppose, make the feature unavailable to floppy
> installations.

Between these two offered alternatives, let me chime in on the side of
the summary file -- and chime in against depriving floppy installers of
the functionality implied by the presence of such a file.  Presumably,
the summary file would be constructed by the distribution packager from
information available from each of the individual binary packages.

A summary file on its own separate package-selection floppy would be OK,
IMHO.  The thought of a separate package-selection floppy raises the
question of whether it might be useful to move all items used only at
package-selection time to a separate package-selection floppy, and thereby
free up some root-floppy space.


From debian-devel@pixar.com Tue Jun  7 10:08:35 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05482; Tue, 7 Jun 94 10:08:31 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB2f2-0007ufa; Tue, 7 Jun 94 08:01 PDT
Date: Tue, 7 Jun 94 08:01 PDT
Message-Id: <m0qB2g7-0000Y2C@debra>
Errors-To: bruce@pixar.com
Reply-To: imurdock@murdoc.pnet.msen.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@murdoc.pnet.msen.com (Ian Murdock)
To: debian-devel@pixar.com
Subject: Projects... volunteers?
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I've fallen slightly behind in everything, I apologize.  The final
0.93 release and a preliminary dpkg won't be much longer.  In the
meantime, I need volunteers for a few projects.

BTW, no one contacted me about package-specific documentation.
Please, please, please send me a short note if the package(s) you
maintain have documentation suitable for inclusion in our set of
manuals.

And now...

* I want to bring up the subject of a bug reporting and tracking
system again.  I would very much like to have one setup by the release
of 0.94, if possible.

* Is there any interest in a structured testing environment such as
Matt Welsh brought up a few weeks back?  I would like to talk about
that, too, if there is interest.

* I'm going to release new versions of the files found at sunsite in
the `info' directory very soon.  I need a volunteer to HTMLize them.

* The FSF is going to snail a copy of the Debian GNU/Linux CD-ROM
cover art to me.  We have permission to use this as a logo.  Does
anyone have access to a scanner that would be willing to scan it?

* More later, as I think of it...

And... speaking of projects, I would like to construct a file with
suggestions for smaller projects that could be done to help improve
Debian.  Many people write to me and ask what they could do to help.
This file would give them some ideas.

An example of what might be included in this file is this:

   * fix xterm to write ut_host correctly to /var/adm/utmp and
     write entries to /var/adm/wtmp and /var/adm/lastlog

If you have complaints about how certain programs work or useful
features that could be added to Debian, this is the place for them.

Here's what I have thus far.  These are just examples; I haven't
really thought about it much yet.  Please send additions to me.
Volunteers should contact me.  As soon as we have a substantial enough
collection of ideas, I'll send them to debian-announce.

-------------------------------------------------------------------------------
Projects					-*- Indented Text -*-

Last updated: Thu May 26 12:45:19 EDT 1994

These are miscellaneous projects that could be done for the Debian
project.  If you want to work on one of them or have a suggested
addition, please contact Ian Murdock <imurdock@gnu.ai.mit.edu>.

   * add a beep-only option to biff (`biff b') that would beep twice
   when the user receives new mail instead of displaying the header
   and first few lines of the message (I find the interruption most
   annoying).  The current (annoying) behavior should still be
   available.

   * fix xterm to write ut_host correctly to /var/adm/utmp and write
   /var/adm/wtmp and /var/adm/lastlog

   * write (or change) a chfn program that can change not only real
   name in pw_gecos, but office, office phone and so on

   * write (or change) a chsh program that checks /etc/shells before
   changing the login shell

   * write a manual page for adduser
-------------------------------------------------------------------------------

Thanks.

From debian-devel@pixar.com Tue Jun  7 10:20:53 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05606; Tue, 7 Jun 94 10:20:50 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB2qx-0007tea; Tue, 7 Jun 94 08:14 PDT
Date: Tue, 7 Jun 94 08:14 PDT
Message-Id: <m0qB2sO-0000Y2C@debra>
Errors-To: bruce@pixar.com
Reply-To: imurdock@murdoc.pnet.msen.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@murdoc.pnet.msen.com (Ian Murdock)
To: debian-devel@pixar.com
Subject: Re: ps(1) dumps core
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Jonathan Rozes writes:
   
   In the everlasting confusion created between SYSV and BSD syntaxes for 
   ps(1), we just did 'ps -u root' and lo and behold, ps dumps core with a 
   segmentation fault. Seems kinda odd don't it? I'd appreciate it if 
   somebody could try to repeat this behavior on their machine. Thanks...

Hmm... works fine here.

From debian-devel@pixar.com Tue Jun  7 12:44:12 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA06648; Tue, 7 Jun 94 12:44:08 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB55d-0007qfa; Tue, 7 Jun 94 10:37 PDT
Date: Tue, 7 Jun 94 10:37 PDT
Message-Id: <9406071736.AA26871@polyhymnia.iwr.uni-heidelberg.de>
Errors-To: bruce@pixar.com
Reply-To: Helmut.Geyer@iwr.uni-heidelberg.de
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Helmut Geyer <Helmut.Geyer@iwr.uni-heidelberg.de>
To: debian-devel@pixar.com
Subject: Re: twm in xbase
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> 
> Matt Welsh writes ("twm in xbase"):
> > I think that it would be a good idea to include twm in Debian's X package.
> > I've spoken with several new Debian users who are annoyed at the fact that
> > they can't port their .twmrc over to Linux and use twm, without downloading
> > twm separately. It's all right if we want to be window manager bigots and
> > push fvwm onto people, but let's not alienate old X users who prefer twm.
> 
> No, it's NOT all right to be "window manager bigots" and "push fvwm
> onto people".  This is on exactly the same level as saying that vi is
> better than emacs and we're only going to have vi.
> 
> Sorry to put this so strongly, but it is emphatically not our place to
> say "thou shalt use this software".

Ever thought of reading what else is in your mailbox before replying?
twm _is_ part of xbase and will stay there. This has been pointed out several 
times as well as in the announcement to the xbase test package. Sometimes I 
feel people here are not reading anything I post.

	Helmut

------------------------------------------------------------------------------
Helmut Geyer                                Helmut.Geyer@iwr.uni-heidelberg.de

From debian-devel@pixar.com Tue Jun  7 16:20:02 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA09188; Tue, 7 Jun 94 16:19:59 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qB8SW-0007rRa; Tue, 7 Jun 94 14:13 PDT
Date: Tue, 7 Jun 94 14:13 PDT
Message-Id: <199406072111.AA03044@SunSITE.Unc.EDU>
Errors-To: bruce@pixar.com
Reply-To: mdw@sunsite.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@sunsite.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

iwj10@cus.cam.ac.uk (Ian Jackson) writes:
> 
> No, it's not up to the filesystem standard (or rather, I don't think
> the FSSTND should be mandating it).  However, I think it would be very
> useful.  I have attached a copy of my original message on the subject
> here - I think it may originally have gone only to the debian-team
> list.  ...  Err, it seems that I never posted a coherent summary, so
> I'll write one now.

If this is the case then we need to put together a supplimentary
set of notes for directory hierarchy standards used by Debian.
This is not just the kind of thing that package maintainers
need to know about, but also end-users. Right now the binary
and source specs share the same set of notes; I think that these
should be move out to another spec which explains all aspects of
what permissions and locations to use for files in a package.

> > > [A-Za-z][-A-Za-z0-9]{0,7} (do we want to use `_'s or `-'s ?  We should
> > > specify which, for consistency, and I'd plump for `-'.)
> > 
> > I don't see why this is necessary.
> 
> Don't the names have to be valid DOS file basenames ?

No, read the spec. The .deb filename has nothing to do with the
package name. PACKAGE: names in the control file should be more
descriptive, as in, Xfree86-server, X-base, and so on. The
actual filenames used will valid DOS filenames, I suppose.

> 	 		*** Debian Linux 1.0 ***
>  Copyright (C) 1994 Ian A. Murdock <imurdock@shell.portal.com> and others.

I assume that this will eventually be "The Debian Linux Association" to
refer to all of us.



From debian-devel@pixar.com Wed Jun  8 00:06:15 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA12177; Wed, 8 Jun 94 00:06:12 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBFjg-0007tNa; Tue, 7 Jun 94 21:59 PDT
Date: Tue, 7 Jun 94 21:59 PDT
Message-Id: <199406081436.AA09387@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: Complaints about *.DIST
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Jackson wrote:
> > Perhaps the control file can have the filename and a description field:
> 
> This is a useful suggestion.  However, I'm not sure whether asking
> package maintainers to do this is a good idea.

Certainly should be made optional. Have a look at my message to Ian Murdoch
which covers the contents plus *.DebianOLD plus using packages from other
distributions. I would appreciate your comments.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Wed Jun  8 00:31:55 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA15472; Wed, 8 Jun 94 00:31:52 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBG8W-0007qpa; Tue, 7 Jun 94 22:25 PDT
Date: Tue, 7 Jun 94 22:25 PDT
Message-Id: <199406081500.AA10130@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: Private groups
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Jackson wrote:
> I had assumed that the fact that Remy hasn't been replying to me
> recently (I sent the most recent message on this topic to him on the
> 13th of April) meant that I'd convinced him that it was a bad idea.

I don't presume to speak for Remy, but I don't think you have.

> Debian (and anything else) would probably be buggered anyway if BSD
> mounting was used.  However, that BSD mounting would bugger things up
> and should not therefore be used is indeed exactly what I was saying
> to Remy.  I'm glad to see that you agree.

I don't agree with you. A lot of programs available for Unix assume BSD
directory semantics (MTAs are a good example).

It wouldn't bugger up any other distribution except Debian because only
Debian uses setgid on directories to such an extent.

/tmp remains irrelevant, and Remy agrees with this. Since he wrote the
ext2 filesystem, he should have, at the least, an adequate understanding
of how Unix filesystems hang together.

I'm aware that my last few messages on *.DIST were very inaccurate, but
when I'm awake I do have a good grasp on computing. 14 years generally
tends to do that to a person.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Wed Jun  8 01:41:53 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA15703; Wed, 8 Jun 94 01:41:46 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBHE9-0007tDa; Tue, 7 Jun 94 23:35 PDT
Date: Tue, 7 Jun 94 23:35 PDT
Message-Id: <199406081611.AA10550@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

  Ian Murdock wrote:
>    You don't need to add lines to the package control file for this;
>    it can be determined by using dpkg --contents. 
> 
> The problem with depending on `dpkg --contents' is that each package
> will have to be available to the front-end as it is selected so that
> the front-end can read the package for the disk usage summary.

dpkg could maintain its own information files(s) on various packages. All
the information would be optional, but it could have the following:

  Contents listing for total accumulated sizes.
  Installation scripts.
  Listing of config files to preserve (+ optional description).

Packages can update dpkg with an optional second archive file containing
information. (In a similar fashion to how anti-virus software keeps up to
date)

All the package information can be run through dpkg before beginning
selection (dpkg could come with all the core package information
pre-installed), which solves the informational chicken-and-egg problem.

That's the first half. The next half is to use the *.DebianOLD I proposed
before, with some beefing up.

The information file would list any configuration files in the format:

  PRESERVE=/etc/passwd
  DESCRIPTION=Listing of users on the system. Not recommended for update.

dpkg would copy any files to preserve to *.DebianOLD. If the user doesn't
want to update the file, then it copies *.DebianOLD back.

If *.DebianOLD already existed while running the install, dpkg wouldn't
copy the file hence aborting the install and re-running isn't a problem.

At this stage, you're probably wondering what the point behind *.DebianOLD
is, since it does the same as *.DIST. The point is two-fold.

  1) It keeps all the package control information in one place, instead
     of script files here and filename changes over there.

  2) It makes Debian packages the same as packages from other distributions,
     and dpkg's functioning is independant of what's in the archive. This
     has a couple of ramifications:

       a) People from other distributions can use Debian packages without
          needing dpkg.

       b) Debian packages can be created by taking a package from
          another distribution and supplying a dpkg installation file.
          This is a serious advantage, IMHO.

>From the package maintainer's viewpoint:

Just as simple as the prior *.DIST proposal, except instead of renaming the
file, it is just:

  PRESERVE=filename

instead.

-- 
  steve@adam.com.au


From debian-devel@pixar.com Wed Jun  8 09:38:49 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA16472; Wed, 8 Jun 94 09:38:45 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBOfl-0007u5a; Wed, 8 Jun 94 07:32 PDT
Date: Wed, 8 Jun 94 07:32 PDT
Message-Id: <m0qBLGS-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: DIST files and SysV packages
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White writes:
> After sorting out my mental picture of what was going on, the only remaining
> problem I can see is if one of the files in the package happen to end in
> *.DIST, by chance.

This is stunningly unlikely, and the packaging guidelines will make it
clear by implication that this would be a problem.

I doubt there really will be packages which is so broken and whose
files can't be renamed.

If we really think there will we could, just in case, add an option to
dpkg/frontend in the control file to change the .DIST and .dist
suffixes for that package.  The documentation should forbid its use
unless there is a real problem, of course.

> The "control file" suggestion by mdw covers that though. You could change
> *.DIST to *.DebianDIST, but I like my suggestion of a description field to
> tell the user what the config file is for. :)

I thought you were in favour of making things easy for package
maintainers ?  We should definitely not require that package
maintainers write descriptions for all their config files and put them
in the control file.

> An alternative approach is that the control file could have the names of
> config files to be preserved, rather than the *.DIST name.
>   Eg, "PRESERVE=/etc/passwd" in the control file.
> The front end can copy it before installing and then copy it back after
> installing. This would mean that the file only gets listed once, and
> packages can be put straight into the archive without files being renamed.

Why does the file need to be listed more than once in my proposal ?

> The file to be preserved could be copied to *.DebianOLD. The front-end would
> be doing:
>   if *.DebianOLD exists, then assume the copy has already been made.
> 
> So it wouldn't bugger up any files if the process was aborted and then
> re-run.

No, it won't be able to tell how far it got through asking the user
about the config files after unpacking.  Ie, it won't be able to tell
the difference between a file that wasn't modified and one that has
already been modified.

This idea strikes me as needlessly less robust.

> Now I understand that problem, I'd have to say that I personally prefer the
> two archives approach. If packages are packed using the "*.DebianOLD" method
> I've suggested above, then they can be unpacked straight out without the use
> of Debian (making it useful to people with other distributions).

They can be unpacked anyway if we use .DIST - in fact, they'd be more
useful, because people with other distributions wouldn't have their
configuration files overwritten every time they upgrade.

> Comments? I hope this is a lot better thought out than my earlier comments.

Better, yes.  IMHO you still need to think about the issues more
before making proposals (sorry to say this, but you did ask).

Ian.

From debian-devel@pixar.com Wed Jun  8 09:39:27 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA16515; Wed, 8 Jun 94 09:39:22 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBOgL-0007tSa; Wed, 8 Jun 94 07:32 PDT
Date: Wed, 8 Jun 94 07:32 PDT
Message-Id: <m0qBLTB-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: twm in xbase
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Helmut Geyer writes ("Re: twm in xbase"):
> [Ian Jackson wrote:]
> > No, it's NOT all right to be "window manager bigots" and "push fvwm
> > onto people".  This is on exactly the same level as saying that vi is
> > better than emacs and we're only going to have vi.
> > 
> > Sorry to put this so strongly, but it is emphatically not our place to
> > say "thou shalt use this software".
> 
> Ever thought of reading what else is in your mailbox before replying?
> twm _is_ part of xbase and will stay there. This has been pointed out several 
> times as well as in the announcement to the xbase test package. Sometimes I 
> feel people here are not reading anything I post.

Firstly, my email travels back and forth on a floppy disk.  I hadn't
seen your most recent message when I wrote mine.  Please don't assume
that everybody's network connection is as good as yours.

Secondly, I wasn't criticising you, but rather the attitude that Matt
seemed to have that twm was somehow `optional'.

Ian.

From debian-devel@pixar.com Wed Jun  8 09:46:53 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA16553; Wed, 8 Jun 94 09:46:39 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBOnO-0007uPa; Wed, 8 Jun 94 07:39 PDT
Date: Wed, 8 Jun 94 07:39 PDT
Message-Id: <m0qBLVm-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Availability of Perl
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Daniel Quinlan writes ("Re: Availability of Perl"):
> If it is required during the first stage of the installation process,
> then perl could temporarily be placed in /bin and moved to /usr/bin
> after /usr is created and mounted.  I don't think there is any reason to
> use symbolic links, overmount, or have two copies of Perl.

Urgh, that's even worse than the 5 possibilities I posted.  It is
messy, and uses the space on the root partition anyway (but frees it
again).

It also doesn't solve the whole problem: it will prevent the use of
Perl in system startup scripts which have to work while /usr is
unmounted, and it doesn't allow you to recover from a disaster by
reinstalling damaged packages: you have to reinstall completely or
restore from a system backup.

> After all, any installing which is going to be going on will presumably
> take place *after* /usr is available.

That depends on your installation model, and what possibilities you're
trying to support.

Ian.

From debian-devel@pixar.com Wed Jun  8 10:14:00 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA16743; Wed, 8 Jun 94 10:13:56 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBPDo-0007uIa; Wed, 8 Jun 94 08:07 PDT
Date: Wed, 8 Jun 94 08:07 PDT
Message-Id: <m0qBPFV-0000YEC@debra>
Errors-To: bruce@pixar.com
Reply-To: imurdock@murdoc.pnet.msen.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@murdoc.pnet.msen.com (Ian Murdock)
To: debian-devel@pixar.com
Subject: Re: Availability of Perl
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Jackson writes:

     4. Put perl in /bin, with a link from /usr/bin on the real /usr
        partition only.  This requires changing the #! line on all
        Debian-specific installation/recovery Perl scripts to
        #!/bin/perl.  Unfortunately this is nonstandard, and might
        encourage package maintainers and users of Debian to distribute
        #!/bin/perl scripts, which won't work elsewhere.  (According to
        Larry Wall, perl belongs in /usr/bin.)

This is entirely reasonable, and it's not going to cause any more
trouble than the thousands of sites that have Perl installed to
/usr/local/bin and scripts that use that path in the `#!' line.

If there are no serious objections, I'm going to do the above in the
0.93 release.

From debian-devel@pixar.com Wed Jun  8 10:44:40 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA16981; Wed, 8 Jun 94 10:44:36 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBPhT-0007tMa; Wed, 8 Jun 94 08:37 PDT
Date: Wed, 8 Jun 94 08:37 PDT
Message-Id: <9406081543.AA16955@thorplus.lib.purdue.edu>
Errors-To: bruce@pixar.com
Reply-To: mdickey@thorplus.lib.purdue.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdickey@thorplus.lib.purdue.edu (Mike D.)
To: debian-devel@pixar.com
Subject: Re: Availability of Perl
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Murdock wrote:
>Ian Jackson writes:
>
>     4. Put perl in /bin, with a link from /usr/bin on the real /usr
>     ....
>
>....
>If there are no serious objections, I'm going to do the above in the
>0.93 release.

I scrapped a longer discussion on this not more than 3 minutes ago.  This
should make it shorter.

I personally like the idea of having a copy of perl on the root
partition's /usr/bin as well as on the /usr parition.  I would settle
with the extra disk space required for this.  And I do not think symlinks
would be necessary.  Everything is where it is supposed to be.  No perl
scripts have to be changed.  Etc....

But, I am sure that people who run perl scripts are well aware of the
gripes they get when the wrong path is in the #! line.  It's an easy fix.
So, it's not like we're introducing any new problems.  Like Ian said, all
the scripts that come as #!/usr/local/bin/perl have weathered us into the
changes.

One way or another, we're going to have to make do with a certain quirk.
I suppose that choosing the #/bin/perl line versus 250k of disk space on
the root partition is a no-brainer.  At least as far as mass distribution
of this package is concerned....

Mike D.
-------
mdickey@thorplus.lib.purdue.edu        Use Debian Linux

From debian-devel@pixar.com Wed Jun  8 14:44:48 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19117; Wed, 8 Jun 94 14:44:42 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBTRp-0007txa; Wed, 8 Jun 94 12:38 PDT
Date: Wed, 8 Jun 94 12:38 PDT
Message-Id: <m0qBTQJ-000023C@plato.simons-rock.edu>
Errors-To: bruce@pixar.com
Reply-To: jimr@simons-rock.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: "James A. Robinson" <jimr@simons-rock.edu>
To: debian-devel@pixar.com
Subject: Re: DIST files and SysV packages 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Wed, 8 Jun 94 07:32 PDT  Ian Jackson wrote:
   This is stunningly unlikely, and the packaging guidelines will make it
   clear by implication that this would be a problem.
   
   I doubt there really will be packages which is so broken and whose
   files can't be renamed.

1st Para: No it is not stunningly unlikely.  It CAN happen, and we
should NOT make a policy on "Well, it is unlikely.  If it happens we
should make the maintainer deal with it."

I prefer White's approach *if* I understand what he is saying.

Let me give it a shot:
--------
	A maintainer has a package that updates /etc/mail.rc:

	He simply builds and customizes the app.
	He archives it without renaming any files.
	He places the name of the config file ONCE into .DEBIAN/config

	dpkg front end unarchives .DEBIAN, reads in the config file.
	sees the name of the config file, sees if it exists on the
	drive already,

		if it exists: # we are updating
			echo "Do you want to update /etc/mail.rc?"
			if yes: # copy the old config to backup, install new.
				cp /etc/mail.rc /etc/mail.rc.DebianOld
				tar xzf mailx.deb
				[this unarchives a /etc/mail.rc]
			if no: # copy new config to <file>.dist
				cp /etc/mail.rc /etc/mail.rc.DebianOld
				tar xzf mailx.deb
				[this unarchives a /etc/mail.rc]
				mv /etc/mail.rc /etc/mail.rc.dist
				mv /etc/mail.rc.DebianOld /etc/mail.rc
		if not:	# We are installing for the first time.
			tar xzf mailx.deb.
--------
If I have this wrong, please correct me! Now if I have this
correct, the maintainer still has to only put in the name
of the config file once, instead of

		CONFIG: /etc/mail.rc
		CONFIG_SUFFIX: .DIST

	he puts in

		CONFIG: /etc/mail.rc

And that, in my mind, is all the simpler, and tar can handle
unarchiving just one directory, the .DEBIAN to scan everything
in before starting on the real package.  I can see where this
might be a problem, so are there easy solutions to this? Say
the other suggestion of package.deb and package.cfg, the cfg
holding only .DEBIAN?
   
   I thought you were in favour of making things easy for package
   maintainers ?  We should definitely not require that package
   maintainers write descriptions for all their config files and put them
   in the control file.

In a previous this is what I thought you were saying.  Each
config file gets named in "CONFIG:" in .DEBIAN/config???
      
   No, it won't be able to tell how far it got through asking the user
   about the config files after unpacking.  Ie, it won't be able to tell
   the difference between a file that wasn't modified and one that has
   already been modified.

Sure it does.  It unarchives .DEBIAN first, scans the config file, and
asks the user...  Or the two file approach.
   
   They can be unpacked anyway if we use .DIST - in fact, they'd be more
   useful, because people with other distributions wouldn't have their
   configuration files overwritten every time they upgrade.

How about writing dpkg in such a way as to be used on any system?  How
hard would it be?  The reason I ask is because every other system,
with the exception of MCC, has been a pain for me to copy pkg files
from.  I agree that there should be some way for porting it, but can
we say that we should put Debian before any other?  How difficult
would it be to make dpkg front end work on any system?  We might
consider making the maintainers lives this much simpler (naming the
config file once, and that is all he has to do before archiving).

Jim
--
Jim Robinson			Email:    jimr@plato.simons-rock.edu
84 Alford Road			Nextmail: jimr@abel.simons-rock.edu
Great Barrington, MA 01230	Phone:    (413) 528-7685, 528-0771

From debian-devel@pixar.com Wed Jun  8 15:43:58 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19748; Wed, 8 Jun 94 15:43:48 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBUMx-0007tia; Wed, 8 Jun 94 13:37 PDT
Date: Wed, 8 Jun 94 13:37 PDT
Message-Id: <9406082033.AA05708@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Complaints about *.DIST
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Salvatore Valente <svalente@MIT.EDU> writes:
> As for depending on the output of "tar": it's not necessary.  I can
> put in the control file:
> CONFIG_FILES: etc/mail.rc
> CONFIG_SUFFIX: DIST
> which can be used by the front end.  (Oops, just found out that mdw
> suggested this a few hours ago.)

Well, how about this: a file .DEBIAN/dist-files that contains a list
of files to apply the "intelligent" update to? (No need to name them
*.DIST, of course.)

From debian-devel@pixar.com Wed Jun  8 15:46:09 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19761; Wed, 8 Jun 94 15:46:02 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBUP9-0007uLa; Wed, 8 Jun 94 13:39 PDT
Date: Wed, 8 Jun 94 13:39 PDT
Message-Id: <9406082036.AA05739@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: DIST files and SysV packages
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

iwj10@cus.cam.ac.uk (Ian Jackson) writes:
> Dealing with your particular complaint, the output format of GNU tar
> is unlikely to change significantly, and even if it did or we decided
> to use another tar instead the change would be easy to cope with.

The only significant complaint about using tar is that it might
cause use to read the entire tarfile just to abstract .DEBIAN.
Perhaps at some point we'll use cpio archives instead, but in the
interest of getting something implemented I think that tar is the
best option for now.


From debian-devel@pixar.com Wed Jun  8 15:48:21 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19786; Wed, 8 Jun 94 15:48:18 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBURN-0007taa; Wed, 8 Jun 94 13:41 PDT
Date: Wed, 8 Jun 94 13:41 PDT
Message-Id: <9406082039.AA05762@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Complaints about *.DIST
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

iwj10@cus.cam.ac.uk (Ian Jackson) writes:
> How about simply allowing the CONFIG_SUFFIX to be specified just in
> case some bozo has made their program require files called *.DIST, and
> have the package installation software use the tar output to find them ?

All right, I'll add that to the spec. This is the best course of action,
I believe...


From debian-devel@pixar.com Thu Jun  9 03:55:37 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA27416; Thu, 9 Jun 94 03:55:33 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBfn9-0007uPa; Thu, 9 Jun 94 01:48 PDT
Date: Thu, 9 Jun 94 01:48 PDT
Message-Id: <199406091825.AA24384@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Big Bugs in Debian Base
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Symptoms: GAS (GNU Assembler) won't "make" properly, and the -z option on
tar gives a harmless "broken pipe" message on large archives.

I have a 386 machine with an IDE hard drive with the old Debian (0.91).

I am installing a 486 machine with a SCSI drive, using the new Debian base
(0.93).

I started off with the 0.93 base, and added the new C libraries, headers,
extras, and GCC compiler. I then compiled binutils, GNU make and bin86 so I
could compile the 1.1.18 Linux kernel. No problems. Installed librl to get
ftp working.

I then compiled bison, flex, and m4 without any problems. However, GAS won't
compile properly. It configures (seemingly correctly), but make goes into an
eternal loop.

GAS will compile and make properly on the old Debian base. I considered it
could be a problem with the C libraries, so I upgraded all the libraries on
the old system to see if it would stop working. It didn't.

I then considered it could be the SCSI driver, 1.1.18 kernel, or the fact
that it's on a 486. I took the IDE drive out of the 386 and put it into the
486. Trying to "make" GAS on the IDE drive still didn't work, so that ruled
out the SCSI driver.

I recompiled the kernel back to 1.1.16 (which the old system was running),
and tried make again on the IDE drive. Still no go, so that ruled out
1.1.18.

I recompiled the kernel to enable kernel math emulation and disable the 486
optimisation. Still didn't work.

I then booted up the IDE drive, and it started working. So I wiped off the
SCSI drive, and "cp -a"'d all the IDE drive files over to the SCSI disk.
300MB later, I booted off the SCSI drive.

"make" worked. This eliminated both the SCSI driver being faulty, and the
486 CPU being faulty.

I then re-installed the new Debian base onto the SCSI drive, re-installed
the libraries and C compiler and tools. I then kept trying "make" while
copying all the libraries over from the IDE drive, trying to find out when
it would start working.

I even deleted the /dev directory on the SCSI drive and copied in the old
Debian /dev directory. Still doesn't work.

At the moment, I still haven't put either of the two machines back together
(I'm typing on this whie it's half disassembled), so I haven't yet tried out
the last remaining thing I can think of.

The system binaries must be stuffed up. As I don't know anything about this
QMAGIC that has been talked about, I cannot really test this properly. The
make for GAS calls too many programs and I can't work out which one is
stuffing up.

So, that's my bug report. I can't do any more than this, sorry. Oh well, at
least I eliminated a lot of possibilities.


PS; I did compile the linux kernel, bison, flex, m4, binutils, and joe with
the new libaries and compiler, so I know I installed it properly.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Thu Jun  9 08:48:14 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA28248; Thu, 9 Jun 94 08:48:09 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBkMK-0007tna; Thu, 9 Jun 94 06:41 PDT
Date: Thu, 9 Jun 94 06:41 PDT
Message-Id: <m0qBhHD-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Matt Welsh writes (regarding /usr/doc/copyright etc.):
> iwj10@cus.cam.ac.uk (Ian Jackson) writes:
> > No, it's not up to the filesystem standard (or rather, I don't think
> > the FSSTND should be mandating it).  However, I think it would be very
> > useful.
> 
> If this is the case then we need to put together a supplimentary
> set of notes for directory hierarchy standards used by Debian.

That depends, I suppose, on how much there would be to document.

> This is not just the kind of thing that package maintainers
> need to know about, but also end-users.

Well, if we're just talking about /usr/doc/copyright then the
reference to it from the issue message would probably sufficient.

> Right now the binary
> and source specs share the same set of notes; I think that these
> should be move out to another spec which explains all aspects of
> what permissions and locations to use for files in a package.

If we want thank kind of thing, should it go into the Debian
administration supplement ?

> > 	 		*** Debian Linux 1.0 ***
> >  Copyright (C) 1994 Ian A. Murdock <imurdock@shell.portal.com> and others.
> 
> I assume that this will eventually be "The Debian Linux Association" to
> refer to all of us.

Whatever - it was just an example.

Regards,
Ian.

From debian-devel@pixar.com Thu Jun  9 08:50:30 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA28303; Thu, 9 Jun 94 08:50:26 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBkOW-0007uJa; Thu, 9 Jun 94 06:43 PDT
Date: Thu, 9 Jun 94 06:43 PDT
Message-Id: <m0qBhdP-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: BSD grpid mounting (was Re: Private groups)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White writes ("Re: Private groups" but actually about BSD mount):
> Ian Jackson wrote:
> > I had assumed that the fact that Remy hasn't been replying to me
> > recently (I sent the most recent message on this topic to him on the
> > 13th of April) meant that I'd convinced him that it was a bad idea.
> 
> I don't presume to speak for Remy, but I don't think you have.

Have you had recent correspondance from Remy on the subject ?
I can of course only speculate about his reasons.

> > Debian (and anything else) would probably be buggered anyway if BSD
> > mounting was used.  However, that BSD mounting would bugger things up
> > and should not therefore be used is indeed exactly what I was saying
> > to Remy.  I'm glad to see that you agree.
> 
> I don't agree with you.

Yes, I knew that.  Obviously my irony wasn't clear enough, my
apologies.

However, I'm not going to go into this argument here.  It has nothing
to do with Debian.  

> [ reasons deleted:
>    2 factual mistakes
>    1 argumentam ad verecundiam based on unsupported hearsay (!) ]

> I'm aware that my last few messages on *.DIST were very inaccurate, but
> when I'm awake I do have a good grasp on computing. 14 years generally
> tends to do that to a person.

This is not the right place for this discussion.  That said, if you
are going to debate it you could address the issues rather than just
trying to demonstrate how experienced you are.

Ian.
(Cambridge University Computer Laboratory, Security Group)

From debian-devel@pixar.com Thu Jun  9 09:08:36 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA28547; Thu, 9 Jun 94 09:08:33 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBkg4-0007uLa; Thu, 9 Jun 94 07:01 PDT
Date: Thu, 9 Jun 94 07:01 PDT
Message-Id: <m0qBhjf-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White writes ("Re: Disk usage totals"):
> That's the first half. The next half is to use the *.DebianOLD I proposed
> before, with some beefing up.

As I have pointed out earlier, this is less robust than renaming the
configuration files.

It is also more work for the package maintainer (renaming files is
easier than editing the control file), and makes it more likely that
they'll get it wrong.

Furthermore, it means that if you try to unpack using plain `tar'
you'll wipe out your existing configuration.

> At this stage, you're probably wondering what the point behind *.DebianOLD
> is, since it does the same as *.DIST. The point is two-fold.

It doesn't - especially when things go slightly wrong.  It fails
ungracefully and will probably do so more often.

>   1) It keeps all the package control information in one place, instead
>      of script files here and filename changes over there.

There is a substantial amount of package control information in the
tarfile file headers (filenames, etc.).  Would you like to bring that
out into the control file too ?

>   2) It makes Debian packages the same as packages from other distributions,
>      and dpkg's functioning is independant of what's in the archive. This
>      has a couple of ramifications:
> 
>        a) People from other distributions can use Debian packages without
>           needing dpkg.

They can do this better with *.DIST, see above.

>        b) Debian packages can be created by taking a package from
>           another distribution and supplying a dpkg installation file.
>           This is a serious advantage, IMHO.

On the contrary, it is likely to result in packages that don't conform
properly to Debian packaging guidelines.  A better idea would be to
unpack the tarfile and repackage it.

In any case, we may well end up using cpio instead of tar.

Ian.

From debian-devel@pixar.com Thu Jun  9 09:34:17 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA28816; Thu, 9 Jun 94 09:34:13 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBl4u-0007tua; Thu, 9 Jun 94 07:27 PDT
Date: Thu, 9 Jun 94 07:27 PDT
Message-Id: <m0qBl47-00002LC@plato.simons-rock.edu>
Errors-To: bruce@pixar.com
Reply-To: jimr@simons-rock.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: "James A. Robinson" <jimr@simons-rock.edu>
To: debian-devel@pixar.com
Subject: Re: Disk usage totals 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

On Thu, 9 Jun 94 07:01 PDT  Ian Jackson wrote:
   
   As I have pointed out earlier, this is less robust than renaming the
   configuration files.

Can you please explain how it is less robust?  The only quasi-problem
I see is if, as you point out, you try and unarchive the thing
straight out it will overwrite old configuration.  Any package does
this already, and if we make dpkg front end as robust and portable as
what White suggests, any person can use dpkg to install the software.
Now THAT would be a lot better then any other package I have seen.
   
   It is also more work for the package maintainer (renaming files is
   easier than editing the control file), and makes it more likely that
   they'll get it wrong.

Renaming the file is not any easier, it is just your personal
preference.  Please don't tell me it is "easier" when I know which *I*
think is easier, just tell me *you* happen to feel X, Y, or Z is
easier.

   It doesn't - especially when things go slightly wrong.  It fails
   ungracefully and will probably do so more often.

Did you read what he wrote (or what I wrote)?  It has as many backup
fail safes as possible, and if dpkg is written to properly handle the
install somehow bombing, it will figure out exactly where it was left
off.  Even a power outage killing all processes can be recovered from
by simply looking at the file names. Do you want me to go through it?
   
   >   1) It keeps all the package control information in one place, instead
   >      of script files here and filename changes over there.
   
   There is a substantial amount of package control information in the
   tarfile file headers (filenames, etc.).  Would you like to bring that
   out into the control file too ?

Where exactly does he say this Ian? I did not see it, so why are you
bringing it up?  If the point is to say "I think we should put as
little in the config files as possible" I must counter with "I think
we should mess with the source and binaries as little as possible."

   They can do this better with *.DIST, see above.

Isn't it a royal pain for them to go through and rename every file if
they need to install if for the first time?  Why not make dpkg and its
front end work on all systems? Best of both worlds IMO.
   
   On the contrary, it is likely to result in packages that don't conform
   properly to Debian packaging guidelines.  A better idea would be to
   unpack the tarfile and repackage it.

He never claimed it would just be zipped right up if it did not
conform to the Debian standards, just that if it happened to have the
right FSSTND layout, one can just check the permissions, write a
config file, and then zip it up.  Just as easy as your meathod IMO.

   In any case, we may well end up using cpio instead of tar.

Well, I don't know which is better, that is one thing that I
don't care which is decided upon.


Jim
--
Jim Robinson			Email:    jimr@plato.simons-rock.edu
84 Alford Road			Nextmail: jimr@abel.simons-rock.edu
Great Barrington, MA 01230	Phone:    (413) 528-7685, 528-0771

From debian-devel@pixar.com Thu Jun  9 14:34:30 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02052; Thu, 9 Jun 94 14:34:25 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBplP-0007u2a; Thu, 9 Jun 94 12:27 PDT
Date: Thu, 9 Jun 94 12:27 PDT
Message-Id: <199406100504.AA29793@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: Big bugs in Base
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


I omitted something important...

It isn't the system binaries, because I tried "chroot()"ing myself to the
IDE partition so it would use the binaries and libraries on the IDE drive
instead of the SCSI drive (boot drive).

It didn't work.

So - the problem is somewhere in the boot up, or somewhere in files
(libraries?) that get loaded up once and stay in memory thereafter.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Thu Jun  9 14:35:58 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02105; Thu, 9 Jun 94 14:35:55 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBpmr-0007uca; Thu, 9 Jun 94 12:29 PDT
Date: Thu, 9 Jun 94 12:29 PDT
Message-Id: <199406100505.AA29829@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: DIST files and SysV packages
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

James A. Robinson wrote:
> I prefer White's approach *if* I understand what he is saying.

Yep, you got it right.

> 	He simply builds and customizes the app.
> 	He archives it without renaming any files.
> 	He places the name of the config file ONCE into .DEBIAN/config

Correct.

> 		if it exists: # we are updating
> 			echo "Do you want to update /etc/mail.rc?"
> 			if yes: # copy the old config to backup, install new.
> 				cp /etc/mail.rc /etc/mail.rc.DebianOld
> 				tar xzf mailx.deb
> 				[this unarchives a /etc/mail.rc]

".DebianOld" would be for temporary backup, and ".old" would be the final
result. Hence, before the tar:
                                cp /etc/mail.rc /etc/mail.rc.old

Other than that, the rest of your handling is correct.

It's probably worth commenting that the cp'ing and mv'ing can be repeated
for however many config files there are - it's not limited to just one
config file. It would handle being aborted at any time too.

> If I have this wrong, please correct me!

Well, if you were wrong, you'd have become right by making a better
suggestion. :)

> Say the other suggestion of package.deb and package.cfg, the cfg
> holding only .DEBIAN?

[and]

> How about writing dpkg in such a way as to be used on any system?  How
> hard would it be?  The reason I ask is because every other system,
> with the exception of MCC, has been a pain for me to copy pkg files
> from.  I agree that there should be some way for porting it, but can
> we say that we should put Debian before any other?  How difficult
> would it be to make dpkg front end work on any system?  We might
> consider making the maintainers lives this much simpler (naming the
> config file once, and that is all he has to do before archiving).

With separate control files and *.DebianOld, dpkg becomes independant of the
files in the archive. That has the following results:

  dpkg can be run on any distribution.

  Descriptions can be written for each config file to help the users know
  what they are updating. dpkg would only need CONFIG=/etc/blah, but a
  quick description isn't hard to do and would help a lot.

  Other distributions can use Debian packages, and Debian can directly
  use packages from other distributions (needing only a small control file
  if there are configuration files to be preserved).

  Creating new contribution packages would be as simple as peeking inside an
  existing package, writing a few "CONFIG=" lines and uploading the package
  and the dpkg control file to an FTP site.

For example; it would be trivial to write some control files for the
existing LibC, Ext, and GCC images. The original archives (as uploaded by
H J Lu) needn't be touched at all.

The end result would be that dpkg is a generally available tool, and Debian
would be a distribution where dpkg is used from the very start.

It does mean that Debian loses its claim to uniqueness, and would have to
be popular solely on how well its packages work together. I don't think this
is such a bad thing though.

-- 
  steve@adam.com.au


From debian-devel@pixar.com Thu Jun  9 14:49:09 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02275; Thu, 9 Jun 94 14:49:07 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBpzd-0007tEa; Thu, 9 Jun 94 12:42 PDT
Date: Thu, 9 Jun 94 12:42 PDT
Message-Id: <9406091938.AA09407@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

imurdock@murdoc.pnet.msen.com (Ian Murdock) writes:
> The problem with depending on `dpkg --contents' is that each package
> will have to be available to the front-end as it is selected so that
> the front-end can read the package for the disk usage summary.  

Of course. The froont-end will be able to "select" packages for 
operations to be done on several of them (e.g., print a disk usage
summary). In general this will be done on a per-package basis.
In the case of floppies for the initial install, each floppy can
have a disk usage summary for the packages contained on it. (In fact,
each .deb file on the archives may want to have a .README file with
information on the package, list of contents, and disk usage summary.) 
These files won't be part of the package, just found on the archive
so that users will know how space each disk (and each package) will
require.

At any rate, anyone who can't do the siumple math required to add up 
disk usage totals across packages shouldn't be using Debian. 


From debian-devel@pixar.com Thu Jun  9 14:50:44 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02364; Thu, 9 Jun 94 14:50:38 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBq16-0007uFa; Thu, 9 Jun 94 12:43 PDT
Date: Thu, 9 Jun 94 12:43 PDT
Message-Id: <9406091940.AA09417@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Partition sizing and arrangement
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

imurdock@murdoc.pnet.msen.com (Ian Murdock) writes:
> I would very much like to do it, but with the current setup it would
> be impossible to combine disk partitioning and package selection, as
> the former is done from the bootdisk and the latter is done from the
> installed base system.  Would the ability to do this be considered a
> valuable enough addition to move package selection and installation
> back to the bootdisk, where it used to be?

No. Provide disk usage summaries on the archives (and in the
documentation). Moving package installation to the bootdisk 
SERIOUSLY restricts what the installation tools can do. 
In short we should allow fdisk to be manual, but provide
reasonable numbers for space requirements.

From debian-devel@pixar.com Thu Jun  9 14:53:49 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02427; Thu, 9 Jun 94 14:53:46 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBq49-0007uCa; Thu, 9 Jun 94 12:47 PDT
Date: Thu, 9 Jun 94 12:47 PDT
Message-Id: <9406091944.AA09448@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White <steve@adam.com.au> writes:
> That's the first half. The next half is to use the *.DebianOLD I proposed
> before, with some beefing up.

Not necessary. I'm adding information to the spec to include a 
CONFIG_PREFIX: option to the control file, which will allow you to
override the default .DIST if necessary. 

Are there any other pending issues for the dpkg spec that need to be
addressed? 

>   1) It keeps all the package control information in one place, instead
>      of script files here and filename changes over there.

Who cares? The latter provide more power and flexibility if you need it,
the former simplicity for updating most configuration files.

And I'm not going to support a package format that can be used without
dpkg. That seriously limits what dpkg can do. 

mdw

From debian-devel@pixar.com Thu Jun  9 16:00:22 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA03620; Thu, 9 Jun 94 16:00:19 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBr6X-0007tba; Thu, 9 Jun 94 13:53 PDT
Date: Thu, 9 Jun 94 13:53 PDT
Message-Id: <199406100629.AA31825@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: BSD grpid mounting (was Re: Private groups)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Jackson wrote:
> > I don't presume to speak for Remy, but I don't think you have.
> 
> Have you had recent correspondance from Remy on the subject ?

Yes.

[BSD mounting]
> However, I'm not going to go into this argument here.  It has nothing
> to do with Debian.

It does actually, in terms of future possibility. However, it's probably
better to wait and see at this point.

> This is not the right place for this discussion.  That said, if you
> are going to debate it you could address the issues rather than just
> trying to demonstrate how experienced you are.

I believe I have done that. I have offered a proposal which performs the
same function as your *.DIST proposal, but which also has additional
benefits.

> (Cambridge University Computer Laboratory, Security Group)

I'm sorry, but I don't care. My credentials are more impressive. I form my
opinions on performance and demonstrated capabilities, not on rank.

I have been consistently insulted and condescended to by your arrogant
attitudes. Despite this, I have repeatedly tried to be polite and
co-operative by asking for your opinions on something I have said.

You have only used this to make further disparaging comments about my lack
of thinking. I continued to try and be co-operative by passing your
misunderstanding off as being my fault because I failed to express myself
clearly.

But it isn't. Jim understood my proposal, the advantages, and ramifications
from the very first message - not needing to read the later message to Ian
Murdoch or even my clarification to you.

I am requesting that you start treating other people with more respect and
with a more co-operative attitude.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Thu Jun  9 16:33:33 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04372; Thu, 9 Jun 94 16:33:30 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBrce-0007tna; Thu, 9 Jun 94 14:26 PDT
Date: Thu, 9 Jun 94 14:26 PDT
Message-Id: <199406100703.AA31975@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Jackson wrote:
> > That's the first half. The next half is to use the *.DebianOLD I proposed
> > before, with some beefing up.
> 
> As I have pointed out earlier, this is less robust than renaming the
> configuration files.

Only if you don't use dpkg to unarchive the package. However, every other
Linux package is already like that. It makes more sense to get dpkg to
handle normal packages than be unneccessarily reliant on special archives.

> It is also more work for the package maintainer (renaming files is
> easier than editing the control file), and makes it more likely that
> they'll get it wrong.

Huh? You're not making sense. How difficult do you think it is to create a
file with "CONFIG=/etc/blah" in it? What editor do you use?

> Furthermore, it means that if you try to unpack using plain `tar'
> you'll wipe out your existing configuration.

Ditto for any other package. Try LibC images. Try Slackware packages. Or
packages on Sunsite.

The "rm" command can blast away a system too. There are so many ways of
damaging a system that unpacking a tar archive in the root directory is
insignificant in comparision.

> > At this stage, you're probably wondering what the point behind
> > *.DebianOLD is, since it does the same as *.DIST.
> 
> It doesn't - especially when things go slightly wrong.  It fails
> ungracefully and will probably do so more often.

Incorrect. It can be aborted, cancelled, power-failured, and re-run at any
time and still keep track of where it was up to.

> There is a substantial amount of package control information in the
> tarfile file headers (filenames, etc.).  Would you like to bring that
> out into the control file too ?

That was not part of my proposal and is a seperate issue. The interaction
between tar and dpkg is not affected by my proposal, other than not needing
to look for *.DIST files in tar's output.

However, it would be possible to include some information about how much
room some directories take up so the user can calculate how to partition his
disks. Something along the lines of "SPACE=/usr 356K" is possible. Again, I
stress that this is not part of my proposal, and it remains purely optional
in any case.

The ONLY requirement would be "CONFIG=/etc/blah".

> On the contrary, it is likely to result in packages that don't conform
> properly to Debian packaging guidelines.  A better idea would be to
> unpack the tarfile and repackage it.

Debian conforms to FSSTND. Slackware conforms to FSSTND. The packages could
be and should be interchangable. There is a lot of work that we could get
for nothing by using packages from other distributions.

Other distributions could benefit from our work by using our packages. dpkg
could be portable onto any distribution.

And when this could be done with such a minor change as "CONFIG=/etc/blah"
instead of "mv /etc/blah /etc/blah.DIST", then what _logical_ reason
remains as to why we shouldn't?

> In any case, we may well end up using cpio instead of tar.

How is it that you can make major changes like that without sweating, and
yet scream about a minor proposal that has so many benefits?

You may feel that you don't have to explain your actions to me or anyone
else, but while you're in a position where you control the project, you
remain accountable to the developers.

This doesn't mean "I'm tired of explaining to you". It means you should
provide explanations that are logical, coherent, and make sense. Saying
it's harder to make a file with "CONFIG=/etc/blah" in it just doesn't
qualify.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Thu Jun  9 16:39:12 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04463; Thu, 9 Jun 94 16:39:10 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBri8-0007tna; Thu, 9 Jun 94 14:32 PDT
Date: Thu, 9 Jun 94 14:32 PDT
Message-Id: <9406092131.AA20374@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

mdw%merengue@merengue.oit.unc.edu (Matt Welsh) said:

> Of course. The froont-end will be able to "select" packages for 
> operations to be done on several of them (e.g., print a disk usage
> summary). In general this will be done on a per-package basis.
> In the case of floppies for the initial install, each floppy can
> have a disk usage summary for the packages contained on it. (In fact,
> each .deb file on the archives may want to have a .README file with
> information on the package, list of contents, and disk usage summary.) 
> These files won't be part of the package, just found on the archive
> so that users will know how space each disk (and each package) will
> require.
> 
> At any rate, anyone who can't do the siumple math required to add up 
> disk usage totals across packages shouldn't be using Debian. 

That's a bit harsh.  I'd say, rather,  that the packagers of debian
should be making a serious effort to make the burden on debian users
as light as possible.  (Hmmmm.... I wonder if the .com vs .edu environment
has any bearing on that ;-).

I this case, part of that effort should be presenting users with the
information they'll need to figure out how to size their disk partitions
before we ask them what sizes of partitions they would like -- and not
requiring those users installing from floppies to cycle a couple of dozen
disks through the machine to get the information.


From debian-devel@pixar.com Thu Jun  9 16:44:02 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04507; Thu, 9 Jun 94 16:43:58 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBrmm-0007uOa; Thu, 9 Jun 94 14:37 PDT
Date: Thu, 9 Jun 94 14:37 PDT
Message-Id: <9406092136.AA19540@spectrum.cs.bucknell.edu>
Errors-To: bruce@pixar.com
Reply-To: quinlan@spectrum.cs.bucknell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)
To: debian-devel@pixar.com
Subject: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Ok, let's all take a deep breath and calm down.  This debate is
beginning to get somewhat long-winded and I think a few basic
principles are getting lost in the process.

First, let's all remember that we've agreed that Ian Murdock is the
person who makes the final decisions -- not anyone else.

I also believe that we can safely assume that most people here have
good credentials.  If someone truly didn't know what they were talking
about, it would show soon enough.  Just because someone is not a
prominent Linux personality, it does not mean that they are less
experienced with Linux.  You get the point, I hope.

--

Since I can't even remember who has said what or what it all means
anymore, I'm starting this message from scratch.

I've remained rather quiet in this debate on configuration files, but
I'm ready to have my say in the matter now.  I want to see action soon
and not at some distant point when the discussion dies from sheer
exhaustion.  I hope to backup my statements with 2 basic principles
that we seem to have forgotten.

(1) We want something yesterday.  We want a stable packaging guideline.

    I believe that this points the way for putting a list of
    configuration files in the control file.

    - dpkg can ignore the field for the first release so we
      can get something out sooner.

    - changes in how the configuration files are handled can be
      orchestrated by dpkg without making changes to any one
      package.

    - packages will not be required to be changed if we change the
      handling of the field.  Any additional "behavior" can be
      put into additional fields.

      For example, start with a "CONFIGURATION_FILE:" field.  Later,
      if some packages need to do something different with a class of
      configuration files, we can add a "CONFIGURE_THIS_WAY:" field
      or whatever.

    - It will also be possible to handle them differently by passing
      different options to dpkg.  One user my prefer *.old while
      another may prefer *.new.

    This will let us end the debate NOW and release a new version of
    Debian ASAP.  It can be *extended* without breaking anything.

(2) We should want to work with the rest of the Linux world,
    especially with any packages which are FSSTND/Debian compliant.

    A simple software-based solution can allow non-Debian users to use
    Debian packages safely.  It will also allow Debian users to
    utilize non-Debian, but compliant packages with the addition of a
    control file.

    This will also pave the way for working with other Linux
    distributions, instead of against them.  dpkg (and related tools)
    will be publicly accessible (and GPL'ed) for this purpose.

    In addition, allowing a Slackware or SLS devotee to install
    Debian's excellent Groff or Emacs package :-) would increase
    the popularity of the Debian release as a whole.

Enough said.  And yes, this is basically the system that Stephen White
favors if I'm not too mistaken.  This system is a win-win situation
for the Debian release and we can implement it quickly and without
further debate.

If there are any problems, we can work them out.  Instead of knocking
on any possible shortcomings, I sincerly ask that you try to work with
this scheme, fix any oversights, and get us moving again.  Thanks.

Dan

From debian-devel@pixar.com Thu Jun  9 16:53:55 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04659; Thu, 9 Jun 94 16:53:46 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBrwG-0007uIa; Thu, 9 Jun 94 14:47 PDT
Date: Thu, 9 Jun 94 14:47 PDT
Message-Id: <199406100721.AA32028@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

James A. Robinson wrote:
> He never claimed it would just be zipped right up if it did not
> conform to the Debian standards, just that if it happened to have the
> right FSSTND layout, one can just check the permissions, write a
> config file, and then zip it up.  Just as easy as your meathod IMO.

That's right.

I see it more as FSSTND as the standard, rather than Debian as the standard.
I don't see any reason for creating yet another standard when dpkg could
be an independant packaging tool available to all users.

In any case, I would like to resolve and close this argument quickly. The
case for *.DebianOLD has been presented and shown to be superior to *.DIST.
I would like to see a concrete and _factual_ example of why my proposal is
inferior and wouldn't work.

If it cannot be shown that the benefits are non-existent, or that it is
inferior and unreliable, then that's the end of the argument. Perhaps I
should re-summarise my proposal in one message so it can be looked at as a
whole.

Anyone reading this - please feel free to request a summary.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Thu Jun  9 17:09:28 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04844; Thu, 9 Jun 94 17:09:25 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBsBP-0007tFa; Thu, 9 Jun 94 15:02 PDT
Date: Thu, 9 Jun 94 15:02 PDT
Message-Id: <9406092200.AA10547@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White <steve@adam.com.au> writes:
> Only if you don't use dpkg to unarchive the package. However, every other
> Linux package is already like that. It makes more sense to get dpkg to
> handle normal packages than be unneccessarily reliant on special archives.

You two can stop this inane flamewar now, as I have no intentions
of implementing Steve's proposal (whatever it is---with this gigantic 
deluge of e-mail it's difficult to determine what the argument is about). 
As far as I can tell, all problems with the current system are solved by 
adding an optional CONFIG-SUFFIX: line to the control file. If there are
any other uncovered issues please bring them up with me (personally)
and we'll look into them.


From debian-devel@pixar.com Thu Jun  9 17:11:45 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04915; Thu, 9 Jun 94 17:11:42 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBsDc-0007u3a; Thu, 9 Jun 94 15:05 PDT
Date: Thu, 9 Jun 94 15:05 PDT
Message-Id: <9406092202.AA10557@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) writes:
>     I believe that this points the way for putting a list of
>     configuration files in the control file.

No, you still need to call them *.DIST in order to prevent overwrite
when unpacking the tar file. Therefore I propose CONFIG_SUFFIX
in case the magic pattern *.DIST conflicts with anything. 
Unless someone can demonstrate that this won't work, I will be
implementing it.


From debian-devel@pixar.com Thu Jun  9 17:14:03 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04963; Thu, 9 Jun 94 17:14:00 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBsFr-0007tra; Thu, 9 Jun 94 15:07 PDT
Date: Thu, 9 Jun 94 15:07 PDT
Message-Id: <9406092204.AA10572@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Partition sizing and arrangement
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

mitchell@mdd.comm.mot.com (Bill Mitchell) writes:
> > No. Provide disk usage summaries on the archives (and in the
> > documentation). Moving package installation to the bootdisk 
> > SERIOUSLY restricts what the installation tools can do. 
> > In short we should allow fdisk to be manual, but provide
> > reasonable numbers for space requirements.
> 
> That's one alternative.  Provide users with hand-waving seat-of-the-pants
> summary with magic numbers, something like what I posted at the start of
> this thread:

How is this different than summaries culled from the packages
themselves?

> Another alternative would be to have the distribution packager collect
> information from the individual binary packages, probably using a script,
> and consolidate this information in one place so that package selection
> can be done from that information before disk partitioning, and the
> partitioning decisions can the be made on actual space requirements
> for the selected packages.

Perhaps we'll do that eventually, but that's really an fdisk issue and
doesn't have anything to do with dpkg. dpkg provides enough information
to be extended in a number of ways. I like the idea, but let's worry
about that level of automation for later.

mdw

From debian-devel@pixar.com Thu Jun  9 17:33:51 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05193; Thu, 9 Jun 94 17:33:49 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBsZ1-0007tia; Thu, 9 Jun 94 15:27 PDT
Date: Thu, 9 Jun 94 15:27 PDT
Message-Id: <9406092232.AA05172@thorplus.lib.purdue.edu>
Errors-To: bruce@pixar.com
Reply-To: mdickey@thorplus.lib.purdue.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdickey@thorplus.lib.purdue.edu (Mike D.)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Matt Welsh writes:
>...I have no intentions
>of implementing Steve's proposal (whatever it is

Careful now.  We don't want anyone here to get the idea that all of this
discussion was for naught since you had made up your mind some time ago.
If you would've posted this attitude two or three days ago we could've
saved everyone's time.  I mean, don't let anyone else stand in the way of
how you are going to build a project for Debian or anything.

>---with this gigantic
>deluge of e-mail it's difficult to determine what the argument is about).

I have asked Steve to make a summary and post it to the list (for
archives reasons and to make sure everyone is clear on it).

>If there are
>any other uncovered issues please bring them up with me (personally)
>and we'll look into them.

This sounds better.  It seems as if some people have a problem with being
openminded around here these days... is it the heat of summer?  I think
the discussion should be kept on the list, though.

But nothing like this should go on behind closed doors.  I learned that
lesson already.  If there is something to discuss, use the list.  That's
what it's for.  However, it's not a playground for flamethrowers.

Mike D.
-------
mdickey@thorplus.lib.purdue.edu        Use Debian Linux

From debian-devel@pixar.com Thu Jun  9 17:56:19 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05322; Thu, 9 Jun 94 17:56:13 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBsuh-0007txa; Thu, 9 Jun 94 15:49 PDT
Date: Thu, 9 Jun 94 15:49 PDT
Message-Id: <9406092247.AA11018@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

mdickey@thorplus.lib.purdue.edu (Mike D.) writes:
> Careful now.  We don't want anyone here to get the idea that all of this
> discussion was for naught since you had made up your mind some time ago.

No, I never "made up my mind" and ignored discussion. There are two
issues:
	1) I didn't see any good reason to abandon the previous policy;
	2) It was difficult to follow Steve's proposal with all of the
	   ensuing flamage/noise.

If Steve can send me his proposal (personally) we'll discuss it, but
from what I can tell my solution fixes all of those problems.

> If you would've posted this attitude two or three days ago we could've
> saved everyone's time.  

I haven't had time to catch up on most of my Debian mail spool
until today. With > 200 pending mail messages on this account, 
it's a bit difficult to do...

> But nothing like this should go on behind closed doors.  

Well, I think that we've gone over these issues time and time again.
If you want me to be able to implement something or include it in
the spec, talk to me directly. Things will go much more quickly
that way. I agree that initial discussions should be in the open,
but at this point I think it's time for one-on-one.


From debian-devel@pixar.com Thu Jun  9 17:57:50 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05333; Thu, 9 Jun 94 17:57:48 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBswE-0007txa; Thu, 9 Jun 94 15:51 PDT
Date: Thu, 9 Jun 94 15:51 PDT
Message-Id: <9406092248.AA11031@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: johnsonm@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: ""Michael K. Johnson"" <johnsonm@merengue.oit.unc.edu>
To: debian-devel@pixar.com
Subject: Re: Enough's enough 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Matt Welsh writes:
>quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) writes:
>>     I believe that this points the way for putting a list of
>>     configuration files in the control file.
>
>No, you still need to call them *.DIST in order to prevent overwrite
>when unpacking the tar file. Therefore I propose CONFIG_SUFFIX
>in case the magic pattern *.DIST conflicts with anything. 

You obviously haven't been listening; Steve has very clearly pointed
out why what you have said is not correct.

First you go through all the files that are declared to be config
files, renaming them to something (he suggested .DebianOLD).
*Then* you unpack the archive.
Then you apply *exactly* the same logic to all the config files that
you applied to the DIST files, reversed.

That is, to leave it alone, rename foo.DebianOLD to foo.

>Unless someone can demonstrate that this won't work, I will be
>implementing it.

Steve's solution takes no more programming, and is technically
superior.  Yours will work, but is more of a kludge and makes the
CONFIG_SUFFIX kludge also necessary.

michaelkjohnson

From debian-devel@pixar.com Thu Jun  9 18:05:58 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05353; Thu, 9 Jun 94 18:05:55 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBt45-0007uQa; Thu, 9 Jun 94 15:59 PDT
Date: Thu, 9 Jun 94 15:59 PDT
Message-Id: <9406092256.AA11325@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

""Michael K. Johnson"" <johnsonm@merengue.oit.unc.edu> writes:
> First you go through all the files that are declared to be config
> files, renaming them to something (he suggested .DebianOLD).

Thanks for putting that into a nutshell. Unless anyone can provide
useful objections to this, I'll include something along these lines
in the spec. Please mail me directly. I tried my best to follow
the flamewar, but a great deal of context was lost.

From debian-devel@pixar.com Thu Jun  9 19:30:01 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05888; Thu, 9 Jun 94 19:29:59 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBuNR-0007txa; Thu, 9 Jun 94 17:23 PDT
Date: Thu, 9 Jun 94 17:23 PDT
Message-Id: <9406100029.AA05878@thorplus.lib.purdue.edu>
Errors-To: bruce@pixar.com
Reply-To: mdickey@thorplus.lib.purdue.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdickey@thorplus.lib.purdue.edu (Mike D.)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Matt wrote:
>	2) It was difficult to follow Steve's proposal with all of the
>	   ensuing flamage/noise.

I agree totally, Matt.  I do not profess to understand it completely
either.  That is another reason I asked Steve to summarize.

>If Steve can send me his proposal (personally) we'll discuss it, but
>from what I can tell my solution fixes all of those problems.

Ok, this sounds good.  Since you are implementing it you _should_ have a
one-on-one discussion with him about it.  I believe that people are
realizing the goodness of the idea and are giving it their approval, at
least for the time-being.  (See other posts recently.)

>I haven't had time to catch up on most of my Debian mail spool
>until today. With > 200 pending mail messages on this account, 
>it's a bit difficult to do...

This is very understandable.  I think we could all relate if we were
behind like that.

>Well, I think that we've gone over these issues time and time again.
>If you want me to be able to implement something or include it in
>the spec, talk to me directly. Things will go much more quickly
>that way. I agree that initial discussions should be in the open,
>but at this point I think it's time for one-on-one.

Ok agreed then.  Again, I think that Steve's proposal is gaining the
approval of the list.  It seems to suffice for now anyway (I do not 
keep saying that because I do not think it will stand over time, only 
that, as Daniel mentioned, we need a product yesterday).  Maybe you two
should discuss this in private.  That way the traffic on here will slow
down so you can get some work done on it.  ;)

Mike D.
-------
mdickey@thorplus.lib.purdue.edu        Use Debian Linux

From debian-devel@pixar.com Thu Jun  9 19:40:41 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05961; Thu, 9 Jun 94 19:40:38 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBuXk-0007tea; Thu, 9 Jun 94 17:33 PDT
Date: Thu, 9 Jun 94 17:33 PDT
Message-Id: <199406101011.AA00164@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: SUMMARY: *.DebianOld vs *.DIST
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I've looked back over my mailbox, and my proposal is spread out over several
messages. As a result, it is hard to work out exactly what I am proposing
unless you have been following the argument closely. Hence, here is the
summary of *.DebianOld vs *.DIST:

1) The *.DIST proposal renames files in the archives, so when the archive is
   extracted it doesn't wipe over existing configuration files. dpkg handles
   updating.

   The *.DebianOld proposal leaves the archive alone. dpkg handles updating.

2) *.DIST archives are prepared by "mv /etc/blah /etc/blah.DIST" before
   packaging up.

   *.DebianOld has "CONFIG=/etc/blah" in a control file.

Both proposals are identical up to here. They both accomplish exactly the
same thing in an equally reliable manner (see below for how *.DebianOld
achieves the reliability).

Where they differ is that *.DIST requires a specially packed archive and a
control file (with the latest suggestions). *.DebianOld only requires a
control file.

To port a package from another distribution using *.DIST, the archive is
unpacked, files renamed, control file created, and the archive repackaged.

With *.DebianOld, only the control file needs to be made.

That's the direct difference. The ramifications in terms of end-user ease
and dpkg's future are considerable.

With dpkg's independance from archive format, it becomes portable to other
distributions. Debian would be a distribution that uses dpkg right from the
start, but other distributions are free to join in as well.

The basic point at issue here is one of an unneccessary standard.

  * Why should a new archiving standard be created, when it is just as
    easy to put the information into a control file?

That's all there is to it.

Do "CONFIG=/etc/blah" and dpkg is portable and users can exchange archives
between distributions.

Do "mv /etc/blah /etc/blah/DIST", and dpkg requires specially packaged
archives and exchanging between distributions becomes a pain in the arse.


At the dpkg level, this is how the file handling works:

  Pre-installation:

    if *.DebianOld doesn't exist then copy, else assume already copied.

  Post-installation:

    If * and *.DebianOld are the same, delete *.DebianOld.

    If user wants to upgrade, "mv *.DebianOld *.old".

    If user wants to keep old config: "mv * *.new" "mv *.DebianOld *"

That's all. This will allow it to keep track of exactly where it was up to
so the installation can be aborted at any time. The above is not just for a
single file - it handles multiple files too.

Notice that *.DebianOld only ever exists when the original configuration
file is in flux, therefore if the installation is restarted and *.DebianOld
exists, then *.DebianOld always contains the original configuration file.


All in all, if what I have said here is accurate then *.DebianOld is a
superior proposal. If you do not believe I am accurate, then please show a
concrete example of where *.DebianOld would fail.

Please make the example a good one, instead of extreme cases ("What if the
IRA blew up the computer?") or opinions like "It's easier to rename a file".

-- 
  steve@adam.com.au

From debian-devel@pixar.com Thu Jun  9 19:53:01 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA06053; Thu, 9 Jun 94 19:52:58 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBujg-0007t1a; Thu, 9 Jun 94 17:46 PDT
Date: Thu, 9 Jun 94 17:46 PDT
Message-Id: <9406100043.AA11586@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: SUMMARY: *.DebianOld vs *.DIST
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White <steve@adam.com.au> writes:
> I've looked back over my mailbox, and my proposal is spread out over several
> messages. As a result, it is hard to work out exactly what I am proposing
> unless you have been following the argument closely. Hence, here is the
> summary of *.DebianOld vs *.DIST:

I'd appreciate it if Ian and others who had objections to this can
mail me PERSONALLY about them. No need to rehash what's already been
said to the entire list.

>    The *.DebianOld proposal leaves the archive alone. dpkg handles updating.

Good idea; it means that the source package Makefile doesn't have to
do anything special.

>    *.DebianOld has "CONFIG=/etc/blah" in a control file.

I will be doing this with .DEBIAN/config-files, which will just contain
a list of all files to update in this way. This simply makes parsing
easier and makes it less likely that the format of the control file
will be botched. Plus it allows you to automatically create 
DEBIAN/config-files (from within a Makefile, for instance).

> Where they differ is that *.DIST requires a specially packed archive and a
> control file (with the latest suggestions). *.DebianOld only requires a
> control file.

Plus pre/post installation scripts.

> Do "CONFIG=/etc/blah" and dpkg is portable and users can exchange archives
> between distributions.

Your proposal also doesn't deal with the case of multiple config files, 
but my notes above generalize that.

>   Pre-installation:
> 
>     if *.DebianOld doesn't exist then copy, else assume already copied.

I wish you'd be more specific here. I can guess what you mean, but no
proposal is well-formed unless it is specific and unambiguous.

Also, I am not going to strive for compatibility with other distributions,
necessarily. All distributions which want to use .deb files MUST USE
DPKG TO INSTALL THEM. PERIOD. I am NOT going to guarantee that the
underlying format of .deb files is accessible without dpkg. With a 
tar/cpio solution it is, but that may not always be the case. Doing
so would seriously restrict our ability to develop a packaging system 
that works and does what we want it to do. I'm not going to hinder
this system for the sake of other distributions. On the flip side, 
there's no reason why other distributions can't use dpkg and .deb files.
In fact, Patrick Volkerding has expressed interest in making the install 
tools for Slackware compatible with dpkg. 

mdw

From debian-devel@pixar.com Thu Jun  9 20:29:31 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA06287; Thu, 9 Jun 94 20:29:28 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qBvJ0-0007u0a; Thu, 9 Jun 94 18:22 PDT
Date: Thu, 9 Jun 94 18:22 PDT
Message-Id: <199406100120.VAA17262@nova.umd.edu>
Errors-To: bruce@pixar.com
Reply-To: rockwell@nova.umd.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Raul Deluth Miller <rockwell@nova.umd.edu>
To: debian-devel@pixar.com
Subject: Re: SUMMARY: *.DebianOld vs *.DIST
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White:
  Please make the example a good one, instead of extreme cases ("What if the
  IRA blew up the computer?") or opinions like "It's easier to rename a file".

Ok.

Old proposal also had a copy of the configuration file with a *.dist
suffix.  This was to hold the distributed configuration file.  The
result was that a typical re-install could recognize that the new
configuration file is the same as what the old configuration file was
before it was reconfigured.

In other words, the sysadmin would be alerted when the distributed
configuration file had changed.

Raul D. Miller
<rockwell@nova.umd.edu>

From debian-devel@pixar.com Fri Jun 10 03:35:52 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA11321; Fri, 10 Jun 94 03:35:47 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qC1xX-0007tIa; Fri, 10 Jun 94 01:29 PDT
Date: Fri, 10 Jun 94 01:29 PDT
Message-Id: <9406100828.AA06968@al-forno.MIT.EDU>
Errors-To: bruce@pixar.com
Reply-To: svalente@mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Salvatore Valente <svalente@mit.edu>
To: debian-devel@pixar.com
Subject: Re: SUMMARY: *.DebianOld vs *.DIST
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Raul D. Miller wrote:

> Old proposal also had a copy of the configuration file with a *.dist
> suffix.  This was to hold the distributed configuration file.

As a general rule, that is not correct.

That is, the first time a user ever installed Debian onto a clean
partition, only one copy of each config file would be made.  (For
example, the new, clean system would have /etc/mail.rc, but not
/etc/mail.rc.dist.)

Now, say a user runs "ed" to edit his /etc/mail.rc.  No copy of the
original, distributed mail.rc is left on the system anywhere.

When the user goes to install the new version of mailx, the
installation program will see an existing mail.rc, but have absolutely
no way of knowing whether it was edited by the user or not.

In the original proposal, the "*.dist" file would only be left laying
around after the _second_ mailx installation, at which point it's sort
of too late.

If you feel that the installation program should leave a copy of each
config file called "*.dist" during the _original_ installation, it can
be made to do that no matter how it figures out which files are the
config files.

In other words, this is a moot point.  Many points in this flamage
have been.  It truly amazes me that so much mail has been generated on
such a simple issue.

My sincere apologies to those who pay to receive email.
-Sal.

From debian-devel@pixar.com Fri Jun 10 06:20:09 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA11457; Fri, 10 Jun 94 06:20:06 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qC4WZ-0007uBa; Fri, 10 Jun 94 04:13 PDT
Date: Fri, 10 Jun 94 04:13 PDT
Message-Id: <199406102050.AA06017@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: DIST files and SysV packages
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Raul Deluth Miller wrote:
> First off, you never addressed the problem of "what happens if the
> installation process gets interrupted before it completes."  We want
> to minimize the exposure of the system to race conditions.

I did, actually. Dunno if you read it though. As there are later messages
that are still questioning *.DebianOld's ability to handle multiple
configuration files, I will respond to this exhaustively.

I'm dropping out of the thread after this message, to let things settle
down again. I will post clarifications if requested, but otherwise I'll
be limiting my responses to Email.

If you're not particuarly interested in this thread, feel free to skip the
following.

  Pre-installation:

    If *.DebianOld doesn't exist, cp * *.DebianOld

  Post-installation:

    If keeping new config: mv *.DebianOld *.old

    If keeping old config: mv * *.new; mv *.DebianOld *

This can handle being aborted at any time for any number of configuration
files. It works like this:

Before we run:

  /etc/blah1
  /etc/blah2
  /etc/blah3
  /etc/blah4
  /etc/blah5

We run it.

  /etc/blah1   /etc/blah1.DebianOld
  /etc/blah2   /etc/blah2.DebianOld
  /etc/blah3 *ABORTED*
  /etc/blah4
  /etc/blah5

We run it again:

  /etc/blah1   /etc/blah1.DebianOld  (already exists, don't copy)
  /etc/blah2   /etc/blah2.DebianOld  (already exists, don't copy)
  /etc/blah3   /etc/blah3.DebianOld
  /etc/blah4   /etc/blah4.DebianOld
  /etc/blah5   /etc/blah5.DebianOld

Tar archive now extracts. Halfway through, we abort. We run it again:

  /etc/blah1   /etc/blah1.DebianOld  (already exists, don't copy)
  /etc/blah2   /etc/blah2.DebianOld  (already exists, don't copy)
  /etc/blah3   /etc/blah3.DebianOld  (already exists, don't copy)
  /etc/blah4   /etc/blah4.DebianOld  (already exists, don't copy)
  /etc/blah5   /etc/blah5.DebianOld  (already exists, don't copy)

Note that it is irrelevant what /etc/blah[1-5] contain. *.DebianOld contains
the definitive backup and it hasn't been overwritten by anything.

Tar archive extracts fully. User starts being asked questions.

  /etc/blah1 [update?] [yes] mv /etc/blah1.DebianOld /etc/blah1.old

  /etc/blah2 [update?] [no]  mv /etc/blah2 /etc/blah2.new
                             mv /etc/blah2.DebianOld /etc/blah2

We abort again. Current file list is:

  /etc/blah1   /etc/blah1.old
  /etc/blah2   /etc/blah2.new
  /etc/blah3   /etc/blah3.DebianOld
  /etc/blah4   /etc/blah4.DebianOld
  /etc/blah5   /etc/blah5.DebianOld

We run the installation again.

  /etc/blah1   /etc/blah1.old   /etc/blah1.DebianOld
  /etc/blah2   /etc/blah2.new   /etc/blah2.DebianOld
  /etc/blah3   /etc/blah3.DebianOld  (already exists, don't copy)
  /etc/blah4   /etc/blah4.DebianOld  (already exists, don't copy)
  /etc/blah5   /etc/blah5.DebianOld  (already exists, don't copy)

We could abort it early again, but it will simply repeat what has happened
before. So we'll just let it install and start asking questions again.

  /etc/blah1 [update?] [yes] mv /etc/blah1.DebianOld /etc/blah1.old

  /etc/blah2 [update?] [no]  mv /etc/blah2 /etc/blah2.new
                             mv /etc/blah2.DebianOld /etc/blah2

[and so on for the rest of the installation]

Note that /etc/blah1 and /etc/blah2 are still the same after this second
round of moving and copying as after the first round of copying. /etc/blah1
is the new file, and /etc/blah2 is the original file. This is what has been
requested by the user.

However, since /etc/blah1 has been backed up to /etc/blah1.old twice, the
orginal /etc/blah1 file has been lost. However, *.DIST will show the same
weakness here.

A possible solution is to ask all the questions first, and then update all
the configuration files in one hit. It could be considered that the user
didn't really want the original /etc/blah1 anyway; it was only backed up as
a courtesy gesture.

Anyway, the main point is that *.DIST and *.DebianOld are functionally
identical as far as updating files is concerned.

> Second, the handling of *.DIST is in the front end, not in the package
> utility.

Acknowledged.

-- 
  steve@adam.com.au


From debian-devel@pixar.com Fri Jun 10 08:23:27 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA11806; Fri, 10 Jun 94 08:23:23 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qC6Rt-0007uLa; Fri, 10 Jun 94 06:16 PDT
Date: Fri, 10 Jun 94 06:16 PDT
Message-Id: <m0qC6Qa-00002aC@plato.simons-rock.edu>
Errors-To: bruce@pixar.com
Reply-To: jimr@simons-rock.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: "James A. Robinson" <jimr@simons-rock.edu>
To: debian-devel@pixar.com
Subject: Address check
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Hi,

Due to a HD crash I had lost my list, and though it is mostly
recovered I need people to look through the following and see if the
correct "maintainer email" is correct.  If your name is not on the
list, and is should be, get in contact with me fast! :) It means your
not in my database of package maintainers...

I'm sorry if this is going to be the second or third time you
have to tell me, but these darn things happen sometimes. :(

Bailey, Matthew <mbailey@gnu.ai.mit.edu>
Brady, Charlie <charlieb@tplrd.tpl.oz.au>
Deisher, Michael E. <deisher@enws125.eas.asu.edu>
Denovich, Mark <mark@clewis.ws.cc.cmu.edu>
Donald Harper <Donald=Harper%NA%Contractors@bangate.compaq.com>
Geyer, Helmut <geyer@kalliope.iwr.uni-heidelberg.de>
Hajek, Ted <tedhajek@boombox.micro.umn.edu>
Inman, David H. <INMANDMK@vms1.bham.ac.uk>
Jackson, Ian <iwj10@cus.cam.ac.uk>
Kluft, Ian <ikluft@thunder.sbay.org>
Mackinlay, Pat <pat@it.com.au>
McCloghrie, Ian <ian@ucsd.edu>
Mcgrew, Clark <mcgrew@skid.ps.uci.edu>
Mitchell, Bill <mitchell@mdd.comm.mot.com>
Murdock, Ian <imurdock@gnu.ai.mit.edu>
Porter, Matthew <porterm@camelot.eng.ohio-state.edu>
Quinlan, Daniel <quinlan@spectrum.cs.bucknell.edu>
Robinson, Jim <jimr@simons-rock.edu>
Rozes, Jonathan <jrozes@cs.tufts.edu>
Sanders, Robert <gt8134b@prism.gatech.edu>
Sangrey, Mike <mike@sojurn.lns.pa.us>
Silber, David H. <dhs@firefly.com>
Talvola, Erik <talvola@fennel.berkeley.edu>
Tobias, Peter <tobias@server.et-inf.fho-emden.de>
Valente, Sal <svalente@athena.mit.edu>
Welsh, Matt <mdw@sunsite.unc.edu>
White, Stephen  <stephen.white@adam.com.au>
--
Jim Robinson			Email:    jimr@plato.simons-rock.edu
84 Alford Road			Nextmail: jimr@abel.simons-rock.edu
Great Barrington, MA 01230	Phone:    (413) 528-7685, 528-0771

From debian-devel@pixar.com Fri Jun 10 14:30:48 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA15538; Fri, 10 Jun 94 14:30:44 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qCCBN-0007tea; Fri, 10 Jun 94 12:24 PDT
Date: Fri, 10 Jun 94 12:24 PDT
Message-Id: <m0qCCAv-0000YGC@debra>
Errors-To: bruce@pixar.com
Reply-To: imurdock@murdoc.pnet.msen.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@murdoc.pnet.msen.com (Ian Murdock)
To: debian-devel@pixar.com
Subject: dpkg snapshot uploaded
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I have just uploaded a snapshot of dpkg to sunsite.unc.edu in
/pub/Linux/distributions/debian/private/project.

There is an error in the Makefile, as it wants to install `dpkg.8',
which doesn't exist.  Ignore the error.

---

This is a snapshot of the dpkg package maintenance utility.  This
snapshop is made available for the sake of progress; everything I have
written thus far appears to work as it should, but there are still
unimplemented features, and what has been implemented is not fully
tested for the reasons below.  What is needed are more packages.  And,
as dpkg is only half of the Debian package maintenance system, current
work needs to be available to others writing a front-end for the
utility.

I have not had the opportunity to test dpkg very thoroughly, because
many of the problems that may arise will be caused by the way packages
are put together.  It is also difficult to realistically test dpkg,
because to do so many packages would be needed (dpkg will be used in
an environment with dozens or even hundreds of packages; I only have a
few at present).

This snapshot attempts to conform to the Debian GNU/Linux packaging
utilities specification but falls short in several noted areas:

	* Keywords are case-sensitive.  This is a minor problem and
	can be fixed later.

	* The keywords ``DEPENDS'', ``RECOMMENDED'', ``OPTIONAL'' and
	``CONFLICTS'' are ignored.  I'm not sure if dpkg is supposed
	to deal with these or if the front-end is, though ``DEPENDS''
	will be used by dpkg to determine package dependencies.

	* Support for package dependencies is missing (see above).

	* Operations on uninstalled packages are not yet supported.

	* Package upgrades are not yet supported.

	* The `--describe' option may not be reliable.  I don't like
	the way I've written it, and I should probably start over.

	* The `--extract' option only extracts /.DEBIAN; it does not
	move the files to an optionally-specified directory.

Features that I want to add not detailed in the specification:

	* Use `configure' to its potential; for now, it's just there
	to make it easier to do this in the future

	* Add package installation and removal logging

	* Sort the output of pkg_list()

Some of the above are noted in the code by a description of what needs
to be done followed by the word ``IMPLEMENT''.  Others are not.  And
there are several places in the code that I'm not sure about.  I may
have tried to do something that the front-end should be doing, or I
may have assumed that the front-end will do something that it won't.
These are indicated in the code by ``QUESTION''.

Other miscellaneous problems to expect:

	* Errors are not handled very well.  dpkg needs to deal with
	common installation-related errors such as a full filesystem,
	and it needs to deal with interrupts.

	* The errors that _are_ caught produce bizarre error messages,
	mostly because it makes it easier for me to track them down.
	Eventually, they will need to be made more descriptive.

	* There may be problems when many packages are installed; I
	don't know, as I've never had more than a few available and
	installed at the same time.

	* There is no documentation yet.

Existing documentation:

	# ./configure
	# make install

Yes, that's it.  Except as noted above, dpkg should behave as outlined
in the specification.  Read the source if you need more information.

Thanks to Mike Dickey, whose work was invaluable at the beginning, and
Matt Welsh, who put together the specification and is writing a front-
end.

From debian-devel@pixar.com Sat Jun 11 22:49:20 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24119; Sat, 11 Jun 94 22:49:17 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qCgRM-0007rja; Sat, 11 Jun 94 20:42 PDT
Date: Sat, 11 Jun 94 20:42 PDT
Message-Id: <199406121320.AA26064@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Faults in base system
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Well, I've tracked down the reason for tar returning broken pipes on some
archives. The "getty" program in the new base system is screwed up. When I
copy in the getty from the old base system, it starts working properly
again.

I'm still trying to track down why GAS won't compile. So far, I've
established that it isn't anything in /usr/bin or /lib or /usr/lib or the
kernel.

I should find the answer quickly now that I have the two machines NFS
mounted on each other so I can run comparisions between the two.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Sun Jun 12 15:51:41 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA29356; Sun, 12 Jun 94 15:51:38 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qCwOi-0006Zaa; Sun, 12 Jun 94 13:44 PDT
Date: Sun, 12 Jun 94 13:44 PDT
Message-Id: <199406122038.AA16958@SunSITE.Unc.EDU>
Errors-To: bruce@pixar.com
Reply-To: mdw@sunsite.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@sunsite.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: dpkg snapshot uploaded
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

imurdock@murdoc.pnet.msen.com (Ian Murdock) writes:
> 	* The keywords ``DEPENDS'', ``RECOMMENDED'', ``OPTIONAL'' and
> 	``CONFLICTS'' are ignored.  I'm not sure if dpkg is supposed
> 	to deal with these or if the front-end is, though ``DEPENDS''
> 	will be used by dpkg to determine package dependencies.
> 
> 	* Support for package dependencies is missing (see above).

Dpkg probably shouldn't deal with any of those things---the front-end
can handle it. That's up to you, but we should say that someone who
is using dpkg directly should be able to install a package without
regard for dependencies and conflicts.

Perhaps dpkg should merely exit (with an error message/return value
of course) if it detects a conflict or lack of prerequisite, unless
the -f/--force option is used. The front-end will be smart about
dependencies and prompt the user with more information, but dpkg
should, in general, not support any operations that require 
user interaction.

In the case of a missing prerequisite, dpkg could exit with an
error message such as
	dpkg: emacs-19: an't install package
	dpkg: emacs-19: Need prerequisite packages 'foo', 'bar', 'baz'

In the case of a conflict,
	dpkg: emacs-19: Can't install package
	dpkg: emacs-19: Conflicts with package 'bamf'

I'm starting work on a Perl-based front-end today.




From debian-devel@pixar.com Sun Jun 12 20:29:46 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA29929; Sun, 12 Jun 94 20:29:42 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qD0jo-0007rca; Sun, 12 Jun 94 18:22 PDT
Date: Sun, 12 Jun 94 18:22 PDT
Message-Id: <9406130122.AA26258@thokk.cs.cornell.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw@cs.cornell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@cs.cornell.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: New dpkg spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Here is a new version of the dpkg spec incorporating the gist of
Steven White's proposal for configuration file updating. 

If you have any comments please let me know ASAP, as I'm about
to implement the mechanism described herein. I'd especially
like to hear (directly) from anyone opposed to the mechanism,
with reasonable arguments as to why it's a bad idea. 

--
Debian GNU/Linux Binary Package and Installation Tools specification

Matt Welsh, <mdw@sunsite.unc.edu>
v0.4, 12 June 1994

-1. Changes in this version

The method used to update configuration files has been revamped.
Sections 1.2.2 and 2.2 contain the relevant changes.

0. Introduction

This specification describes the format of `.deb' binary packages
for the Debian GNU/Linux distribution. It also describes the various
installation tools that manipulate packages; this includes `dpkg' and
the dpkg front-end. 

All Debian package maintainers should follow the binary package
specification contained herein; given the description of dpkg and
related tools, you will know how binary packages will be installed,
upgraded, and configured. These subjects are intimately tied together,
which is why there is one specification for all of them.

Please see the Debian Source Package Guidelines for information concerning
the creation of Debian Source Packages (from which Binary Packages are
built).

Note: This is a PRELIMINARY specification. It has not been implemented yet.
Therefore, members of the Debian development group should make comments,
suggestions, and outright corrections to it before we begin to implement
dpkg and the install tools as described here. Critique should be mailed
to myself (mdw@sunsite.unc.edu) and Ian Murdock (imurdock@gnu.ai.mit.edu).

1. Binary Package Format 

A Debian Binary Package (hereafter refered to as a `package') consists
of two parts: A set of files which make up the software package in
question, and configuration/installation information. This configuration
information will consist of package-specific installation and configuration
scripts; information on the origin, version, and maintainer of the package;
information on package dependencies and conflicts, and so forth.

Much of the rationale for the following package format specification is
based on the installation tools, which are described in the next section.
If the reasoning behind a particular aspect of this format is not clear,
section 2, below, should clear up any confusion.

Debian packages will be stored as a single gzipped tar file. Canonically,
package filenames will end in the extension `.deb', although the installation
tools will not depend at all on the package filenames. 

1.1 Package contents

The package tar file should contain all files included in the software
package, archived from the root directory (`/'). The installation tools
will extract packages from the root directory of the system, so everything
should be in the right place within the package tar file. In addition, all
file permissions and ownership information of files in the package should 
be correct as they are archived. `tar' will be used to extract package 
files, which will set the permissions and ownership of the files as they
are extracted. 

The following guidelines should be followed for file layout and permissions
within the binary package:

	* The location of installed files must follow the Linux Filesystem
	  Standard. The latest version of this document can be found
	  alongside this Debian source package guidelines. Specific 
	  questions about following the filesystem standard can be 
	  addressed to Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>.

	* All directories should be mode 755, with the exception of 
	  special "system" directories that need to be another mode. The 
	  ownership of the directory should be consistent with its mode; 
	  if a directory is mode 775, then it should be owned by the group 
	  that needs write access to it. Use common sense in assigning 
	  permissions and ownerships to directories, and make sure that 
	  what is done is secure if it is not the standard configuration.
	
	* In general, normal binaries should be mode 755 and owned by
	  root.bin.  If there is a good reason to use a different mode 
	  or ownership, then feel free to do so, but do try to be as 
	  consistent as possible with the rest of the system.

	* Setuid/setgid binaries should be mode 4711/2711 and owned by 
	  the appropriate user/group.  For security reasons, please do 
	  not make setuid/setgid binaries mode 4755/2755.
	
	* Library files should generally be installed as mode 644 and 
	  owner root.root; however, if the package requires different 
	  permissions or ownerships to function correctly, then they 
	  should obviously be used instead.
	
	* Manual pages should be mode 644 and owned by root.root. The 
	  nroff source must be installed. Do not install a pre-formatted 
	  catman page.
	
	* Man pages should be edited to reflect the Debian package. For
	  example, references of /etc/utmp should be changed to 
	  /var/adm/utmp. Documentation really should be consistent with 
	  the system.

	* Info documents should be mode 644 and `gzipped' when installed.

	* Any other documentation that comes with the package should be
	  installed at the discretion of the package maintainer. Text
	  documentation should be mode 644, `gzipped' and installed to
	  /usr/doc.  If a subdirectory of /usr/doc is warranted, then 
	  please feel free to create one.

	* Any example files (for example, sample configuration files) 
  	  should be placed in /usr/doc/examples. If the file is normally 
	  a "hidden" file, such as `.emacs', then please call it 
	  `dot.emacs' to avoid confusion.

	* All symbolic links should be relative, not absolute. Absolute
	  links, in general, cause problems when a filesystem is not 
	  mounted where it ``normally'' resides (for example, when mounted 
	  via NFS). In certain cases, however, relative links may also 
	  cause similar problems (for example, if /usr is mounted on 
	  /foo/bar, and /foo/bar/spool is a link to ../spool it will not 
	  find it); in this case, feel free to use absolute links, but they 
	  should be used only when necessary. I have generally made links 
	  into /etc and /var absolute and all other links relative. There 
	  may be other cases in which absolute links are necessary.


1.2 Configuration information

In addition to the contents of the software package, packages will also
contain configuration information, stored in the directory `/.DEBIAN'
at the root of the tar file. Files within the .DEBIAN/ directory are:
	.DEBIAN/control		Master package configuration file
	.DEBIAN/conffiles	List of package configuration files
	.DEBIAN/preinst		Package pre-installation script
	.DEBIAN/postinst	Package post-installation script
	.DEBIAN/prerm		Package pre-removal script
	.DEBIAN/postrm		Package post-removal script

Of these, only .DEBIAN/control is required. The various installation
scripts, and the configuration files list, will only be used if they 
are present. 

1.2.1 Control file format

The .DEBIAN/control file contains a number of fields. Each field begins
with a tag, such as `PACKAGE' or `VERSION' (case insensitive), followed
by a colon, and the body of the field. Fields are delimited only by 
field tags. In other words, field text may be multiple lines in length,
but the installation tools will generally join lines when processing
the body of the field.

The required fields in the control file are the following:

	PACKAGE: <Short name of package>
	VERSION: <Version number>
	MAINTAINER: <Name and e-mail address of package maintainer>
	DESCRIPTION: <Description of package> 

There is but one restriction on the format of control file fields:
The value of `PACKAGE' will be used to generate filenames by the 
installation tools, and therefore should be a valid filename prefix
(i.e., no embedded slashes), and not contain any whitespace.

The optional fields in the control file are the following:

	DEPENDS: <Short names of prerequisite packages>
	RECOMMENDED: <Short names of related, recommended packages>
	OPTIONAL: <Short names of related, optional packages>
	CONFLICTS: <Short names of packages which conflict with this one>

An example of a .DEBIAN/control file would be:

	PACKAGE: emacs
	VERSION: 19.22
	MAINTAINER: Daniel Quinlan <quinlan@bucknell.edu>
	DESCRIPTION: The extensible, customizable, self-documenting, 
	             real-time display editor
	DEPENDS: emcsmisc, emcselc1, emcselc2
	RECOMMENDED: emcselz1, emcselz2, emcsinfo
	OPTIONAL: emcsetc
	CONFLICTS: emacs_nox

In this case, the `emacs' package will contain the binary with X support,
and `emacs_nox' contains the binary without X support. The control
file for `emacs_nox' would contain a `CONFLICTS: emacs' line accordingly.

1.2.2 Configuration file list format

The contents of .DEBIAN/conffiles is simply a list of files in the
package which should be updated by a ``foolproof'' upgrade mechanism when 
the package is installed. This mechanism will ensure that package-specific 
configuration files are not overwritten when a package is upgraded, unless 
the user wishes the installation tools to do so. 

Typically, files listed in .DEBIAN/conffiles are package-specific 
configuration files, which (according to the Linux Filesystem Standard) 
are stored in /etc. For example, the `sendmail' package may contain the 
file `/etc/sendmail.cf', which we do not wish to overwrite automatically
when the user upgrades the sendmail package. Only those files listed in
DEBIAN/conffiles will be updated intelligently when a package is upgraded; 
all other files in the package will be overwritten by the upgrade process.

The exact method for .DEBIAN/conffiles file update is covered in Section 2, 
below. 

1.2.3 Installation script format

The files `preinst', `postinst', `prerm', and `postrm' are optional 
(bash or perl) scripts contained within the .DEBIAN directory 
in the package. As the names imply, if these scripts exist they will 
be executed before installing the package, after installation, before 
package removal, and after removal, respectively. 

These scripts can be used to perform any site-specific package configuration.
Because the scripts will be exectued by the dpkg front-end, it is guaranteed 
that the scripts will be executed interactively. User input from the 
scripts should be read from standard input, not the user's terminal.
Similarly, output should be sent to standard output.

Note that `postinst' will be executed AFTER the files listed in
DEBIAN/conffiles have been updated. In this way the script can
do site-specific configuration for the package based on the actual
configuration files selected by the user; there is no guesswork
involved.

1.3 Creating a Debian Binary Package

Packages are merely gzipped tar files with the embedded .DEBIAN directory.
Therefore, the canonical way to create a binary package is to follow
these steps:
	1) Install the entire package in a clean directory tree on the
	   source system, (for example, /usr/src/root_dir), ensuring that 
	   file permissions and ownerships are correct;
	2) Create the `.DEBIAN' directory at the root of this tree;
	3) Within `.DEBIAN', create the files `control', as well as
	   (optionally) `conffiles', `preinst', `postinst', `prerm', 
	   and `postrm';
	4) Issue a command such as: 
		cd /usr/src/root_dir; tar cf - . | gzip -9c > ../foo.deb

	   To create the package `foo.deb' from the contents of the 
	   directory `root_dir'. 


2. Package Installation Tools

The Debian package installation tools will consist of two applications:
`dpkg', which is responsible for package installation, removal, and
sanity-checking; and a dpkg front-end, which is responsible for
locating and selecting packages to install, as well as package configuration.
Note that dpkg does nothing about package configuration; it is only
responsible for installing the package software on the system. The
front-end (which can be given a number of interfaces) will select packages,
invoke dpkg for each, and handle all package configuration issues. 

One of the reasons for this is that the front-end should handle all 
interactive use of the installation tools. In addition, the user may wish
to install many software packages at one time, but delay configuration
until the installation process has been completed. Making dpkg and the
front-end independent of one another is the best way to achieve this.

Note that dpkg will rarely be used alone; nearly all packages will
require some kind of configuration. For those who wish to do things
`by hand', one of the available front-ends for dpkg will be a script
that invokes dpkg to install a named package, and immediately configure
it. Of course, a number of smarter, more interface-laden front-ends
will be available as well, both for terminal and X-based environments.


2.1 dpkg

The format of the dpkg command is as follows:

	dpkg [ -i | --install ] <package>
	dpkg [ -r | --remove ] <package>
	dpkg [ -l | --list ]  
	dpkg [ -c | --contents ] [ -d | --describe ] [ -v | --version]  
	     <package>
	dpkg [ -s | --search ] <regexp> 
	dpkg [ -s | --extract ] <package> [ <directory> ]

Where <package> is the pathname of a Debian package file, and
<regexp> is a regular expression.

Invoking dpkg with the `-i' option will install the named <package> on 
the system. Essentially this consists of:
	1) Determining if another version of this package is already 
	   installed, and if so, remove it; 
	2) Unpacking the contents of the package from the system root
	   directory;
	3) Moving the contents of the /.DEBIAN directory (created by
	   unpacking the tar file) to the appropriate location (see
	   below).
	4) Generate a list of files installed from the package (see below).

Note that the directory /.DEBIAN will be created by the installation
procedure, and subsequently moved to another location. Therefore, 
dpkg will exit with an error message if .DEBIAN already exists (which
means that another dpkg process is running on this system, or a
previous dpkg crashed before making it to step (3)). 

dpkg will move the contents of /.DEBIAN to /var/adm/dpkg as follows:
	* /.DEBIAN/control will be moved to /var/adm/dpkg/<package>.control,
	  where <package> is the name of the package given in the control
	  file (not determined from the package filename).
	* The installation scripts, /.DEBIAN/{pre,post}{inst,rm}, will be 
	  moved to /var/adm/dpkg/<package>.{pre,post}{inst,rm}.
	* The configuration files list, /.DEBIAN/conffiles, will be
	  moved to /var/adm/dpkg/<package>.conffiles.

During the installation procedure, dpkg will generate a list of files
in the package, and store it in the file /var/adm/dpkg/<package>.list.

Invoking dpkg with the `-r' option will remove the named package, if it
has been installed on the system. Essentially this consists of deleting
all files on the system from the corresponding filelist in
/var/adm/dpkg/<package>.list. This will also delete all information
about the package in /var/adm/dpkg.

Invoking dpkg with the `-l' option will list all packages installed on
the system. It will print a short, one-line summary of each package, such as:

	Name		Version		Install date
	---------------	---------------	-------------
	groff		1.0.9		13 May 1994
	emacs 		18.59		23 Aug 1993

Installation dates can be gathered from the ctime of the corresponding
files in /var/adm/dpkg, or amended to the control file at installation
time.

The `-c', `-v', and `-d' options give information about packages
which match the given regular expression. The named packages may be 
either installed, in which case <package> specifies an installed 
package name, or uninstalled, in which case <package> is a pathname 
to a (not yet installed) package. 

`-c' prints the contents of the package, in ls -adl format. `-v' prints
version and maintainer information for the package. `-d' prints the
description of the package from the control file.

The `-s' option searches for the named file(s) (given by the regular
expression <regexp>) in all installed packages, and prints the names
of the package(s) in which it is found. For example, `dpkg -s "?dit*"' 
might print:
	groff
	xditview
The regular expression is matched against the installed-package filelists
in /var/adm/dpkg/*.list.

The `-e' option will extract the package control directory .DEBIAN from
the named <package>, and place it in the named <directory> (or 
`./.DEBIAN' if no <directory> is specified). For example,m
	dpkg -e foo.deb /tmp/foo-information
will copy `/.DEBIAN/*' from the package to `/tmp/foo-information'. 
The directory `.DEBIAN' will _not_ be created beneath the named
<directory>.


2.2 dpkg Front-end

There will be several front-ends to dpkg available; they will provide
a friendly user interface for finding and selecting packages to 
install/remove, as well as take care of package configuration. 
For example, when the user wishes to install a set of packages at
one time, dpkg will be invoked for each package, but the package-specific
installation scripts (.DEBIAN/preinst et. al.) will be executed in
one batch for all packages. 

When installing packages, the front-end will handle package configuration 
in the following way:

	1) Before the package has been installed (using dpkg), the
	   contents of the /.DEBIAN directory will be extracted from
	   the package, and saved in a temporary directory.

	2) If /.DEBIAN/preinst exists, it will be executed;

	3) For all files listed in /.DEBIAN/conffiles,
		3a) If <file>.dpkg-old exists, delete it.
		3b) If <file>.dpkg-new exists, delete it.
		3c) If <file>.dpkg-tmp does not exist,
		    copy <file> to <file>.dpkg-tmp.

	4) dpkg will be invoked to install the package;

	5) For all files listed in /.DEBIAN/confffiles,
		5a) If <file>.dpkg-tmp and <file> are identical,
		    delete <file>.dpkg-tmp.
		5b) Otherwise, give the user the following options:
		      1. "Use new configuration file." 
			 <file>.dpkg-tmp is renamed to <file>.dpkg-old.
			 Give user option to delete <file>.dpkg-old.
		      2. "Use old configuration file."
			 <file> is renamed to <file>.dpkg-new.
			 Give user option to delete <file>.dpkg-new.
			 <file>.dpkg-tmp is renamed to <file>.

	   The front-end will be able to select user defaults for
	   these actions.
	
	6) If /.DEBIAN/postinst exists, it will be executed;

	7) Remove the front-end's temporary copy of /.DEBIAN files.


The front end will handle package removal in the following way:

	1) Execute /var/adm/dpkg/<package>.prerm, if it exists;

	2) For all files in /var/adm/dpkg/<package>.conffiles,
		2a) If <file>.dpkg-new exists, delete it.
		2b) If <file>.dpkg-old exists, delete it.

	3) Save a copy of /var/adm/dpkg/<package>.postrm, if it
	   exists (as dpkg will delete all files from /var/adm/dpkg
	   corresponding to this package); 

	4) Invoke dpkg to remove the package (as well as
	   /var/adm/dpkg/<package>* files) from the system;

	5) Execute saved copy of /var/adm/dpkg/<package>.postrm, if
	   it exists.


3. Comments

Please send your comments on this specification to M. Welsh 
(mdw@sunsite.unc.edu) and Ian Murdock (imurdock@gnu.ai.mit.edu). 
This specification is necessarily vague, because many of the details
of implementation have not been determined yet. However, most of
the major issues should be presented here, and I welcome your 
suggestions and ideas.

Once this specification is complete we will be able to produce these
tools, and give package maintainers something solid to go by. I'd like
for this to be as long-term as possible, so that maintainers don't
have to modify their package distribution as the spec changes. Therefore,
if you can think of potential future extensions of this specification,
now is the time to bring them up.


From debian-devel@pixar.com Mon Jun 13 06:48:24 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04937; Mon, 13 Jun 94 06:48:22 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qDAOV-0007rja; Mon, 13 Jun 94 04:41 PDT
Date: Mon, 13 Jun 94 04:41 PDT
Message-Id: <199406132120.AA07881@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White <steve@adam.com.au>
To: debian-devel@pixar.com
Subject: GAS not compiling
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

OK, I found the problem. GAS was released 2 months ago, and my clock was set
back to 4 months ago. So the "make" program thought the newer files were
older than the rest of the files.

Took me 4 days to work that out.

Anyway. Two more programs that should be on the base system are "ifconfig"
and "route" so remote file systems can be mounted for installation over NFS.

-- 
  steve@adam.com.au

From debian-devel@pixar.com Mon Jun 13 07:24:04 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04992; Mon, 13 Jun 94 07:24:02 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qDAx1-0006hva; Mon, 13 Jun 94 05:17 PDT
Date: Mon, 13 Jun 94 05:17 PDT
Message-Id: <m0qD9gm-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Boggle.  I don't get around to reading the list for 4 days and it
explodes ...

Anyway, following Stephen's summary posting I'm a lot happier with his
*.DebianOld proposal; clearly I hadn't understood it correctly the
first time.  My apologies.  However, I would like to point out that I
only ever posted two messages about it, even if they were less than
charitable.

As I understand it, the resulting implementation at installation time
will be exactly the same, except that it will move * to *.DebianOld
first instead of having the new file called *.DIST, and of course
corresponding modifications to the actions done by the front-end after
post-install has been run.

I'm a little concerned that a couple of people, including Stephen
himself, have missed the point that in my scheme (and hence, by
implication, in Stephen's scheme?) the per config file prompt will
give *three* choices: install the new file, keep the old file and
never ask again, and allow the user to fix it (which amounts to
keeping the old file, but will ask the user again next time the same
package is installed).

Just to make sure everyone has the same idea of what is going on, I
attach the summary I posted about a month ago.  I have edited it to
reflect what I think is Stephen's proposal, the fact that this
functionality is no longer in dpkg but in the front-end, and the fact
that *.MSG has been removed.

Ian.


Firstly, from the point of view of dpkg+frontend, for each package:

1. It runs the pre-installation script.

2. It renames the configuration files listed in the control file or
list of config files from * to *.DebianOld.  Files that do not exist
as * or that already exist as *.DebianOld are ignored.

3. It extracts the files - over the top of any existing installation
(care will have to be taken with things like the libc, obviously).
The new configuration files are named * at this point.

4. It runs the post-installation script.

5. It looks at the listed configuration files.  For each such file,
one of the following things happens:
  a. the *.DebianOld file no longer exists.  It does nothing.
  b. * is identical to *.dist, or to *.DebianOld if *.dist doesn't
     exist.  It renames *.DebianOld to *.
  c. * is NOT identical to *.dist or *.DebianOld.  dpkg prompts the user:
 There is a new version of configuration file /etc/foo.conf.
  [y] Use the new file - I'll back up the old one as /etc/foo.conf.old.
  [o] Leave the old file and don't flag it at the next installation -
      I'll put the new file in /etc/foo.conf.dist.
  [n] Fix it yourself - I'll put the new file in /etc/foo.conf.dist.new.
 Enter option y, o, n or ! to escape to a shell to examine the situation.
 What would you like to do ?  _
  If the user selects y it renames *.DebianOld to *.old and deletes
   any *.dist.
  If the user selects o it renames * to *.dist and *.DebianOld to *.
  If the user selects n it renames * to *.dist.new and *.DebianOld to *.
The default would be y.

6. It deletes any files in any old installed version of the package
which don't appear in the new version.  Perhaps the post-install
script should do this on a package-by-package basis, but this is
imposing a burden on package maintainers to remember to delete
obsolete files.

Stages 1, 2 and 3 should be run first for all packages, so that the
lengthy main installation phase is noninteractive.  Stages 4, 5 and 6
should be run together for each package in turn.


Secondly, from the point of view of the package maintainer:

Most packages need not take any special action.  Just mention all the
config files in the appropriate control file dpkg and the front-end do
the rest.  The pre- and post-install scripts are empty.

If a package needs to do something special it can decide at run-time
(when running the post-install script) whether it is capable of
handling the situation itself.  It may interact with the user at this
point.  On entry *.DebianOld is the system's old config file, * is the
new one from the distribution, and conventionally *.dist if it exists
is the distribution config file from the version for which *.DebianOld
was the user's config file.

If it can handle it, it should do so, and should delete *.DebianOld.
if it can't, it leaves *.DebianOld there, which will cause the
front-end to ask the user what to do.

In general if a package presents the user with a question like the one
that dpkg asks by default it should then always delete the *.DebianOld
file to avoid asking the installer the same question twice.


Thirdly, from the point of view of the sysadmin:

Most of the time they need do nothing, because the configuration files
won't change.

When they do, for most packages they'll get a dialogue like the one
above, and when they hit return it will install the new version.

If they have edited the file themselves they may choose to select o,
which will silence any further complaints from future upgrades, or n,
if they think something like an incompatibility needs their attention.

For complicated packages something more complicated will happen,
possibly involving an interactive configuration dialogue, or scripts
to check or update configuration files.

--
Ian Jackson, at home  <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
PGP2 public key available on server.  Urgent email: <iwj@cam-orl.co.uk>
2 Lexington Close, Cambridge, CB4 3LS, England;  phone: +44 223 575512

From debian-devel@pixar.com Mon Jun 13 09:42:20 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA05856; Mon, 13 Jun 94 09:42:17 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qDD6o-0007rma; Mon, 13 Jun 94 07:35 PDT
Date: Mon, 13 Jun 94 07:35 PDT
Message-Id: <9406131434.AA02275@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: source package install targets (was: Re: New dpkg spec)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

The latest dpkg spec from Matt Welsh, <mdw@sunsite.unc.edu> says:

> [...]
> 1.3 Creating a Debian Binary Package
> 
> Packages are merely gzipped tar files with the embedded .DEBIAN directory.
> The dpkg spec from mdw@cs.cornell.edu (Matt Welsh) says:
> 
> Therefore, the canonical way to create a binary package is to follow
> these steps:
> 	1) Install the entire package in a clean directory tree on the
> 	   source system, (for example, /usr/src/root_dir), ensuring that 
> 	   file permissions and ownerships are correct;
> 	2) Create the `.DEBIAN' directory at the root of this tree;
> 	3) Within `.DEBIAN', create the files `control', as well as
> 	   (optionally) `conffiles', `preinst', `postinst', `prerm', 
> 	   and `postrm';
> 	4) Issue a command such as: 
> 		cd /usr/src/root_dir; tar cf - . | gzip -9c > ../foo.deb
> 
> 	   To create the package `foo.deb' from the contents of the 
> 	   directory `root_dir'. 

I'd like to again suggest that the source package packaging guidelines be
changed so that a "make install" for a source package produces an
installation suitable for putting together a binary package.  That is,
"make install" not install directly to /usr/bin, /usr/man/man1, etc.; but
rather to something along the lines of /usr/local/debian/usr/bin, etc.; 
or /usr/src/root_dir/usr/bin, etc.

EIther that, or a "make dpkg" makefile target in the source package for
$PACKAGF would produce $PACKAGE.deb.

From debian-devel@pixar.com Mon Jun 13 11:05:32 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA07235; Mon, 13 Jun 94 11:05:29 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qDEPL-0007rMa; Mon, 13 Jun 94 08:58 PDT
Date: Mon, 13 Jun 94 08:58 PDT
Message-Id: <m0qDF1d-0000TDC@firefly.firefly.com>
Errors-To: bruce@pixar.com
Reply-To: dhs%firefly@uu5.psi.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: dhs%firefly@uu5.psi.com (David H. Silber)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> From: iwj10@cus.cam.ac.uk (Ian Jackson)

> 6. It deletes any files in any old installed version of the package
> which don't appear in the new version.  Perhaps the post-install
> script should do this on a package-by-package basis, but this is
> imposing a burden on package maintainers to remember to delete
> obsolete files.

If dpkg+frontend will delete obsolete files, the old list of files needs
to be kept until after this step.  Also, for any file which we are about
to remove, we should check the file lists for other installed packages in
case this file should be kept after all.  (Perhaps more than one package
supplied this file or the file was moved from one package to another.)
If we are installing multiple packages together, we should also consult
the file lists of the other new packagaes.

-- 
                             ---------------------
    ---------------------    |  Firefly Project  |    ---------------------
    |  David H. Silber  |    ---------------------    |  dhs@firefly.com  |
    ---------------------                             ---------------------
                        -------------------------------
                        |  I was subtle once ...      |
                        |        but nobody noticed.  |
                        -------------------------------                    


From debian-devel@pixar.com Mon Jun 13 11:39:32 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA07596; Mon, 13 Jun 94 11:39:28 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0qDEwE-0007rka; Mon, 13 Jun 94 09:32 PDT
Date: Mon, 13 Jun 94 09:32 PDT
Message-Id: <m0qDEus-000030C@plato.simons-rock.edu>
Errors-To: bruce@pixar.com
Reply-To: jimr@simons-rock.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: "James A. Robinson" <jimr@simons-rock.edu>
To: debian-devel@pixar.com
Subject: config files.
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Mon, 13 Jun 94 08:58 PDT  David H. Silber wrote:
   
   If dpkg+frontend will delete obsolete files, the old list of files needs
   to be kept until after this step.  Also, for any file which we are about
   to remove, we should check the file lists for other installed packages in
   case this file should be kept after all.  (Perhaps more than one package
   supplied this file or the file was moved from one package to another.)
   If we are installing multiple packages together, we should also consult
   the file lists of the other new packagaes.

An important note here is that maintainers should try and work out who
gets what config files if they are shared, for instance I send all
ispell.el files to the Emacs maintainer, because otherwise there would
be conflict.  It would be very bad if configs were not coordinated.

Jim
P.S. David, I can't get mail to you through dhs%firefly@uu5.psi.com,
it bounces saying "Host unknown"  Is is MXed?
--
Jim Robinson			Email:    jimr@plato.simons-rock.edu
84 Alford Road			Nextmail: jimr@abel.simons-rock.edu
Great Barrington, MA 01230	Phone:    (413) 528-7685, 528-0771

