Re: Bug#40706: usr/share/doc vs. /usr/doc

[Steve Greenland]

On 01-Aug-99, 16:31 (CDT), Nicolás Lichtmaier <[EMAIL PROTECTED]> wrote: 
> > 75%. http://kitenet.net/programs/debhelper/stats/
> > (A little out of date, hasn't been updated in a month, but it will soon..)
> 
>  It should be higher... the more packages uses debstd/debhelper, the less
> lines of code that need maintenaince...

Maybe, maybe not. Debhelper is great if the package fits into the GNU
mold. On others, it's not a lot of help. Given the times I have had to
go in and figure out what dh_ was doing, and either fix it or
adjust my thinking, the overall balance can shift against debhelper.

(I'm *not* slamming debhelper, it's a great tool and all of my packages
use it. But there are complicated or weird packages where it may not be
the best choice.)

Steve

Re: Bug#40706: usr/share/doc vs. /usr/doc

[Steve Greenland]

On 02-Aug-99, 11:22 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote: 
> 
> Yes, I agree helper packages would help, but those who chose not to use a
> helper package should not be "punished" for that.

Please describe how they are being "punished". If I choose not to use
a tool (and there are many legitimate reasons not to use debhelper or
debstd), then I can hardly complain that I don't get the benefits of
using that tool. I certainly can't call myself punished.

(On the other hand, don't bother. A few more minutes thought convinces
me my mind is closed on this topic; I can't think of any argument that
justifies the term "punished".)

Steve "who is against symlinks in packages, anyway" G.

Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

[Roman Hodek]

> I´d prefer a syntax in the style of /etc/exports, e.g.
> 
> Build-Depends: package1, package2(CPU1), package3(!CPU1), 
>  package4(SYSTEM2-CPU2, SYSTEM3-*), package5 | package6(CPU1),
>  package7(CPU1, >= 2.0), package7(!CPU1, >= 2.1)
> 
> It looks a bit easier to read (and create) to me than the prefix
> syntax as there is already a colon after "Build-Depends". If there
> is a system-cpu specification, it must be before the version
> specification, so a parser for this would not be too difficult.

Hmm... but the parser still has to decide if the thing in parens is an
arch spec or a version spec, which isn't really trivial, as the
version number can be an arbitrary string. I think I'm against this
just because it's too hard to parse.

> About the conflict headers: I don´t think they are necessary, so I
> vote for removing them from the proposal (as Richard suggested).

No, they're really necessary. An example is bash: If you have
termcap-compat installed during the build, configure will detect
libtermcap before libncurses and link everything with the obsolete
libtermcap. Therefore bash needs a Build-Conflict: termcap-compat.

Roman

Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

[Roman Hodek]

> Are the -Conflicts headers really necessary? So far I have not been
> able to think of a use for them, and they complicate the task of the
> build daemons ("install everything needed to build this package")
> unnecessarily.

That's not really true. The parsing is nearly the same, and it's no
trouble in sbuild to deinstall packages as that's needed anyway after
the build. I guess the negative deps (as I have called them in sbuild)
make about 5 lines of code.

> We've already seen with binary dependencies that the Conflicts
> relationships create the most difficult problems.

But it's something different here... It's really trivial to
temporatily uninstall a package and reinstall it later.

>   - Problem: There are two conflicting development environments (let's
> call them tk40-dev and tk41-dev :-), and foo needs the right one.
> Solution: foo declares a Build-Depends on tk41-dev, and tk41-dev
> conflicts with tk40-dev.

Yep, it's already done this way without problems and without the need
for build-conflicts.

>   - Problem: Package foo needs debassistant >= 0.8 to build, but
> will not work with debassistant version 0.93 which has a horrible bug.

Yep :-)

> Solution: foo declares
>   Build-Depends: debassistant (>= 0.8),
>  debassistant (<< 0.93) | 
> debassistant (>> 0.93)

Ok (though a bit complicated, but doesn't matter, it should be rarely
necessary.)

> If package foo has Build-Conflicts: bar, it means that the *presence*
> of bar will prevent foo from building correctly.  I consider that a
> bug!  Adding support for this would condone such bugs.

Hmm... Let's see where such conflicts are used currently:

a2ps => !lprng, lpr, gs, psutils, bzip2, gv, ghostview, gettext, flex

  Hmm... don't remember exactly anymore, but I guess lpr is needed and
  doesn't like lprng in parallel.

abuse => !svgalib-dummyg1
gnuplot => !svgalib-dummyg1, gnuplot

  Some packages would configure for svgalib if svgalib-dummy is installed.

bash => !termcap-compat

  If termcap-compat is installed, configure will detect libtermcap
  before libncurses and link with the former.

emacs20 => !emacs20

  AFAICR emacs used the installed lisp files instead of the ones in
  the build dir, but this has been fixed some time ago.

liece => emacs20, !libsocks-dev

  Can't remember... :-(

plplot => g77, !f2c, itcl3.0-dev, python-numeric

  f2c doesn't conflict with g77, but is preferred by the config.

rpm => !bzip2, m4, gettext, autoconf, automake, tetex-bin

  If bzip2 is installed, librpm.so will be linked with libbz2.so,
  which is unwanted.

ruby => bison, !ruby

  And installed ruby can provoke version conflicts of the installed
  lib and the built lib.

I think at least the cases of bash, plplot, and rpm are no bugs.

Roman

Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

[Roman Hodek]

> Can we use a format that is more inline with the rest of the depends
> stuff? Perhaps:
>
>   pkg (>= 2.1 i386)
> 
> With the 'i386' being whatever specification you want to dream up.
> (optional of course)

At least better to parse than "package7(CPU1, >= 2.0)", as the version
can't contain spaces and anything following it must be an arch spec.

Roman

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Kristoffer . Rose]

I proposed:

>> 1. REQUIRE that /usr/doc is a symlink to the FHS directory /usr/share/doc.

Joseph Carter replied:

> Breaks dpkg.  Propose it all you want, but it's not going to happen if you
> don't provide the patch for dpkg to follow symlinks.  Either that or all
> packages must be upgraded and Pre-depends: base-files (>= someversion).

 Interesting.  I have
been using symlinks at the directory level in this way for some years now,
with dpkg, and nothing is broken yet.  Can you explain how dpkg breaks
since I didn't notice? 

(Note that I am explicitly avoiding actually installing or deinstalling an
actual symlink which dpkg thinks is a directory ... with my proposal this
can, in fact, happen, but only if users deinstall all packages that refer
to the /usr/doc directory which is rather unlikely.)

> Your script also has a cow if /usr/doc isn't -> share/doc, which is bad
> because it may be necessary to use some symlink magic at some point.  Not
> that it isn't a moot point unless you fix dpkg first.

This was intentional ... and in fact the script will merely warn you if
this is the case.  I was merely trying to KISS since this is a rather
critical script.

More reactions welcome !

Best,
Kristoffer
-- 
Kristoffer Høgsbro Rose, phd, prof.associé  
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080   <[EMAIL PROTECTED]>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0   <[EMAIL PROTECTED],tug}.org>

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Joseph Carter]

On Tue, Aug 03, 1999 at 10:56:22AM +0200, [EMAIL PROTECTED] wrote:
> I proposed:
> 
> >> 1. REQUIRE that /usr/doc is a symlink to the FHS directory /usr/share/doc.
> 
> Joseph Carter replied:
> 
> > Breaks dpkg.  Propose it all you want, but it's not going to happen if you
> > don't provide the patch for dpkg to follow symlinks.  Either that or all
> > packages must be upgraded and Pre-depends: base-files (>= someversion).
> 
>  Interesting.  I have
> been using symlinks at the directory level in this way for some years now,
> with dpkg, and nothing is broken yet.  Can you explain how dpkg breaks
> since I didn't notice? 

All right dammit, here we go...  built a package crap 1.0-1, here is the
listing:

/.
/usr
/usr/bin
/usr/sbin
/usr/lib
/usr/lib/crap
/usr/lib/crap/olddir
/usr/lib/crap/olddir/file
/usr/doc
/usr/doc/crap
/usr/doc/crap/changelog.Debian.gz

Now from /usr/lib/crap:

drwxr-xr-x   2 root root 1024 Aug  3 02:15 olddir/
-rwxr-xr-x   1 root root  633 Aug  3 02:14 olddir/file*

And then after I symlink it:

drwxr-xr-x   2 root root 1024 Aug  3 02:15 newdir/
-rwxr-xr-x   1 root root  633 Aug  3 02:14 newdir/file*
lrwxrwxrwx   1 root root7 Aug  3 02:19 olddir -> newdir//


Install crap 1.0-2 ...

/.
/usr
/usr/bin
/usr/sbin
/usr/lib
/usr/lib/crap
/usr/lib/crap/newdir
/usr/lib/crap/newdir/file
/usr/doc
/usr/doc/crap
/usr/doc/crap/changelog.Debian.gz

[EMAIL PROTECTED]:/usr/lib/crap# ls -lR
.:
total 1
drwxr-xr-x   2 root root 1024 Aug  3 02:21 newdir/

newdir:
total 0


Do you believe us yet?  What more proof do you possibly need?


> (Note that I am explicitly avoiding actually installing or deinstalling an
> actual symlink which dpkg thinks is a directory ... with my proposal this
> can, in fact, happen, but only if users deinstall all packages that refer
> to the /usr/doc directory which is rather unlikely.)

Does not matter.  dpkg breaks.  It has been now demonstrated and proven.


> > Your script also has a cow if /usr/doc isn't -> share/doc, which is bad
> > because it may be necessary to use some symlink magic at some point.  Not
> > that it isn't a moot point unless you fix dpkg first.
> 
> This was intentional ... and in fact the script will merely warn you if
> this is the case.  I was merely trying to KISS since this is a rather
> critical script.
> 
> More reactions welcome !

It exits with 1, that's an error condition.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
 if macOS is for the computer illiterate, then windoze is for the
  computer masochists



pgp98J1yGep2U.pgp
Description: PGP signature

Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

[Richard Braakman]

Roman Hodek wrote:
> But it's something different here... It's really trivial to
> temporatily uninstall a package and reinstall it later.

What if you can only uninstall the package by deconfiguring another one
that you need?  Take this situation:

foo-source has
  Build-Depends: gnu1 | gnu2
  Build-Conflicts: bar

gnu1 has
  Depends: bar

Currently bar and gnu1 are installed.  Will your five lines of code be
able to uninstall bar, uninstall gnu1, and install gnu2?

> Hmm... Let's see where such conflicts are used currently:
> 
> a2ps => !lprng, lpr, gs, psutils, bzip2, gv, ghostview, gettext, flex
> 
>   Hmm... don't remember exactly anymore, but I guess lpr is needed and
>   doesn't like lprng in parallel.

Hmm, lprng Provides lpr (and Conflicts with it).  I guess this
expresses that lprng won't do.

> abuse => !svgalib-dummyg1
> gnuplot => !svgalib-dummyg1, gnuplot
> 
>   Some packages would configure for svgalib if svgalib-dummy is installed.

They should be configured not to use svgalib, via options in debian/rules.
This should not depend on the build environment.  (If it does, it's
far too easy to silently build without it, even on a platform that
does need it).

> bash => !termcap-compat
> 
>   If termcap-compat is installed, configure will detect libtermcap
>   before libncurses and link with the former.

Also a packaging bug.  Bash should be told to use libncurses, regardless
of the build environment.

> plplot => g77, !f2c, itcl3.0-dev, python-numeric
> 
>   f2c doesn't conflict with g77, but is preferred by the config.
>
> rpm => !bzip2, m4, gettext, autoconf, automake, tetex-bin
> 
>   If bzip2 is installed, librpm.so will be linked with libbz2.so,
>   which is unwanted.

(and so forth)... these should all be told to configure the right way,
regardless of build environment.  Build-time configuration is nice, but
not if you want the binary package to be easily reproducible.  I've
already seen far too many bugs in NMUs caused by packages silently built
with the wrong configuration.  Also, the normal course for a user who
is faced with a core dump is to try to get a backtrace by compiling the
program with debugging symbols.

> ruby => bison, !ruby
> 
>   And installed ruby can provoke version conflicts of the installed
>   lib and the built lib.

Definitely a bug in ruby's build environment... imagine these :-)

gcc => binutils, !gcc
perl => !perl

> I think at least the cases of bash, plplot, and rpm are no bugs.

I think they are, for the reasons I've given above.

Richard Braakman

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Kristoffer . Rose]

Dear Joseph Carter,

I'm sorry to shout but please read what I write.

> All right dammit, here we go...  built a package crap 1.0-1, here is the
> listing:
>... 
> /usr/lib/crap/olddir
>...
> Do you believe us yet?  What more proof do you possibly need?

I am happy to tell you that we agree completely on the behaviour of dpkg on 
your example.  But you are ignoring a very important aspect of my proposal: 
THIS ONLY HAPPENS FOR DIRECTORIES INTERNAL TO PACKAGES.  It happens because 
olddir is actually REMOVED by the deinstallation.

For directories that are not removed there is NO PROBLEM.  Fortunately
/usr/doc is not removed unless everything is removed.  This is a crucial
property of the proposal.  Now back to the regular (constructive)
discussion...our goal is to find a solution, after all :)

What other problems could there be with my proposal.

Enjoy,
Kristoffer
-- 
Kristoffer Høgsbro Rose, phd, prof.associé  
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080   <[EMAIL PROTECTED]>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0   <[EMAIL PROTECTED],tug}.org>

Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

[Roman Hodek]

> What if you can only uninstall the package by deconfiguring another one
> that you need?  Take this situation:
> 
> foo-source has
>   Build-Depends: gnu1 | gnu2
>   Build-Conflicts: bar
> 
> gnu1 has
>   Depends: bar
> 
> Currently bar and gnu1 are installed.  Will your five lines of code be
> able to uninstall bar, uninstall gnu1, and install gnu2?

First: The ~ 5 lines were for additional support of negative
dependencies.

Second: sbuild currently doesn't support alternatives yet :-(

Third: Dependency calculations et al. are passed on to apt-get, so
they make up no code :-)

> Hmm, lprng Provides lpr (and Conflicts with it). I guess this
> expresses that lprng won't do.

Ah, that sounds like an explanation, yes. Isn't this a good reason for
Build-Conflicts:? A simple Build-Depends: lpr could be satisfied by
lprng as well, but it's wrong since a2ps needs real lpr, not lprng.

> They should be configured not to use svgalib, via options in debian/rules.
> This should not depend on the build environment.  (If it does, it's
> far too easy to silently build without it, even on a platform that
> does need it).

This is the case for many, really many libs :-( It was one of the
reason we've "invented" source dependencies. You simply can't hardwire
all lib dependencies as options to configure.

> Also a packaging bug. Bash should be told to use libncurses,
> regardless of the build environment.

Also if you have to patch a really correct upstream configure? (I
assume there's no option for disabling libtermcap.)

> (and so forth)... these should all be told to configure the right
> way, regardless of build environment. Build-time configuration is
> nice, but not if you want the binary package to be easily
> reproducible.

...but often configure scripts aren't flexible enough so that you can
select all options from the command line :-(

> I've already seen far too many bugs in NMUs caused by packages
> silently built with the wrong configuration.

And this hopefully will come to an end with source dependencies!

Roman

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Anthony Towns]

On Tue, Aug 03, 1999 at 12:05:39PM +0200, [EMAIL PROTECTED] wrote:
> I am happy to tell you that we agree completely on the behaviour of dpkg on 
> your example.  But you are ignoring a very important aspect of my proposal: 
> THIS ONLY HAPPENS FOR DIRECTORIES INTERNAL TO PACKAGES.  It happens because 
> olddir is actually REMOVED by the deinstallation.

This doesn't seem to be the case.

* Create three packages:
test1 version 1.0 mimicing your average /usr/doc-using package
test1 version 2.0 mimicing your average /usr/share/doc-using package
test3 version 1.0 mimicing base-files

test1 1.0 has a file /my_usr/doc/test1/copyright,
  and depends on test3

test1 2.0 has a file /my_usr/share/doc/test1/copyright,
  and depends on test3

test3 1.0 has a file /my_usr/doc/copyright/GPL,
  and a file /my_usr/share/doc/test3/copyright

* dpkg --install test3_1.0_all.deb

* mv /my_usr/doc/copyright /my_usr/share/doc/
* rmdir /my_usr/doc
* ln -s /my_usr/share/doc /my_usr/doc

* dpkg --install test1_1.0_all.deb
* dpkg --install test1_2.0_all.deb

* ls -l /my_usr/doc/test1 -> empty
* ls -l /my_usr/share/doc/test1 -> empty
* dpkg -L test1 | grep my_usr/share/doc -> not empty

The packages are available as:

http://www.debian.org/~ajt/test1_1.0_all.deb
http://www.debian.org/~ajt/test1_2.0_all.deb
http://www.debian.org/~ajt/test3_1.0_all.deb

Possibly I'm just misunderstanding what you're suggesting should be done
though. Can you give a sequence of commands that does whatever you're
suggesting, and still has those three packages survive unscathed?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgp96GMp6BSA0.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Michael Stone]

On Tue, Aug 03, 1999 at 12:05:39PM +0200, [EMAIL PROTECTED] wrote:
> What other problems could there be with my proposal.

Well, the real reason is that you're trying to rearrange 110M that might
be located on a filesystem other than the destination filesystem. If
someone's doing careful space management, that could cause problems;
also, that move wouldn't be atomic and you'd have to worry about failure
detection and clean-up. I see two valid approaches: first, we could do
the move only if the source and destination are on the same fs, in which
case the move is atomic and there are no potential difficulties. If
they're on different fs's, we leave /usr/doc alone and put in the
opposite symlink (/usr/share/doc->/usr/doc). second, we could come up
with some kind of complicated copy-and-check-the-result script that will
catch all of the possible error conditions (out of disk space,
interrupted operation, etc.) I'm inclined to go with the first approach.
I propose rules like this: if there is a /usr/doc directory and there is not a
/usr/share/doc, and /usr/share is on the same partition as /usr/doc,
move /usr/doc to /usr/share/doc. If there is /usr/doc, create a
/usr/share/doc symlink pointing to it. And, for the next few releases,
if there is a /usr/share/doc, create a /usr/doc symlink pointing to it.

Mike Stone

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Michael Stone]

On Tue, Aug 03, 1999 at 09:21:05PM +1000, Anthony Towns wrote:
> Possibly I'm just misunderstanding what you're suggesting should be done
> though. Can you give a sequence of commands that does whatever you're
> suggesting, and still has those three packages survive unscathed?

That's simple enough. This all only works if there is no /usr/share/doc
and you can move /usr/doc in an atomic operation. IMHO, packages that
started using /usr/share/doc were premature in that usage and shouldn't
get special accomodation. For now, packages should be built to install
into /usr/doc without concern for whether that's a symlink or not. We
can worry about whether we want to deal with the symlink at a later
date.

Mike Stone




pgpeRyDN9BNDI.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Antti-Juhani Kaijanaho]

On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> IMHO, packages that
> started using /usr/share/doc were premature in that usage 

Your opinion is wrong.

Those packages follow current policy.  Not using /usr/share/doc in a
standards-version >= 3.0.0 package is a policy violation.

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   "... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Anthony Towns]

On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> On Tue, Aug 03, 1999 at 09:21:05PM +1000, Anthony Towns wrote:
> > Possibly I'm just misunderstanding what you're suggesting should be done
> > though. Can you give a sequence of commands that does whatever you're
> > suggesting, and still has those three packages survive unscathed?
> That's simple enough.

Then please give a concrete example, with actual .debs and actual shell
commands.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds

Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

[Santiago Vila]

On Tue, 27 Jul 1999, Joseph Carter wrote:

> [...]
> To do this I suggest we ammend policy first by replacing all existing
> instances of /var/spool/mail with /var/mail and then changing the second
> paragraph of section 5.6 which currently reads
> 
>The mail spool is /var/spool/mail and the interface to send a mail
>message is /usr/sbin/sendmail (as per the FHS). The mail spool is part
>of the base system and not part of the MTA package.
> 
> to the following:
> 
>The mail spool is /var/mail and the interface to send a mail message is
>/usr/sbin/sendmail (as per the FHS).  The mail spool is part of the
>base system and any package requiring use øf /var/mail must declare
>dependency on base-files (>= #BASEFILESVER#).
> 
> 
> Also, a new section should be inserted after section 3.1.2 containing the
> following:
> 
>   3.1.3 The system mail spool
> 
>While the FHS mandates the mail spool be accessable as /var/mail, it is
>important to retain compatibility with older packages and locally
>compiled programs.  Packages using the mail spool should use /var/mail
>and declare dependency on base-files (>= #BASEFILESVER#).

I second this proposal, but please change the word "dependency"
by "Pre-Dependency" (otherwise I would formally object ;-).

Rationale: base-files (>=whatever) must be unpacked and *configured*
before *any* package using /var/mail is *unpacked*, because the symlink
/var/mail -> /var/spool/mail will be handled in base-files' postinst.

[ Try to think what happens if an important program start to access
  /var/mail without /var/mail being there yet ].

BTW: The footnote pointed out by Antti-Juhani should be reworded also.
(Yes, this is the footnote saying we should still follow /var/spool/mail
regardless of what FHS says).

Thanks.

-- 
 "9646ee6e65c45b4fb4034ce347d9e7f0" (a truly random sig)

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Michael Stone]

On Tue, Aug 03, 1999 at 03:14:56PM +0300, Antti-Juhani Kaijanaho wrote:
> On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> > IMHO, packages that
> > started using /usr/share/doc were premature in that usage 
> 
> Your opinion is wrong.
> 
> Those packages follow current policy.  Not using /usr/share/doc in a
> standards-version >= 3.0.0 package is a policy violation.

Sure it's legal, but was it a good idea? Do you want to argue that the
current state of the distibution is a Good Thing?

Mike Stone

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Kristoffer . Rose]

Michael Stone on my proposal (available from
http://www.ens-lyon.fr/~krisrose/ftp/Debian/usr-doc-proposal.txt>):

> Well, the real reason is that you're trying to rearrange 110M that might
> be located on a filesystem other than the destination filesystem. [...]

You are right.  At the moment the script will just bail out (and undo what
it did) in case there is a space overflow (and in case /usr/doc is a
separate file system).  Since it uses cp -a it essentially requires twice
the space of /usr/doc so that is, indeed, suboptimal.

A nicer solution would be to make sure that /usr/share/doc is on the same
filesystem as /usr/doc *before* moving (this is realistic as /usr/share/doc 
is, at the moment, quite small).  Then the rearrangement can be made
safely.

The important point is that the possible combinations can be enumerated.

I do believe, however, that we *must* make /usr/doc a symlink to a *real*
usr/share/doc because that way the *stable* way to do things is to migrate
to /usr/share/doc.  We want as few problems as possible with old packages
but we *definitely* want no problems at all with migrated packages.

Anthony Towns writes:

> * Create three packages:
>   test1 version 1.0 mimicing your average /usr/doc-using package
>   test1 version 2.0 mimicing your average /usr/share/doc-using package
>   test3 version 1.0 mimicing base-files
> 
> test1 1.0 has a file /my_usr/doc/test1/copyright,
>   and depends on test3
> 
> test1 2.0 has a file /my_usr/share/doc/test1/copyright,
>   and depends on test3
> 
> test3 1.0 has a file /my_usr/doc/copyright/GPL,
>   and a file /my_usr/share/doc/test3/copyright

You are right which is why test3 would have a critical bug filed against it
since it creates both /usr/doc/P and /usr/share/doc/P (these are the
"critical" requrements of point 2 in the proposal).  test3 (mimicking
te fixed base-files) should *only* have /usr/share/doc files.  (In the
proposal it is furthermore responsible for the /usr/doc symlink even if it
declares it as a directory, sic, thats the only slack needed.)

So indeed those three packages will not be handled correctly.

Best,
Kristoffer
-- 
Kristoffer Høgsbro Rose, phd, prof.associé  
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080   <[EMAIL PROTECTED]>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0   <[EMAIL PROTECTED],tug}.org>

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Anthony Towns]

> Anthony Towns writes:
> > * Create three packages:
> > test1 version 1.0 mimicing your average /usr/doc-using package
> > test1 version 2.0 mimicing your average /usr/share/doc-using package
> > test3 version 1.0 mimicing base-files
> > 
> > test1 1.0 has a file /my_usr/doc/test1/copyright,
> >   and depends on test3
> > 
> > test1 2.0 has a file /my_usr/share/doc/test1/copyright,
> >   and depends on test3
> > 
> > test3 1.0 has a file /my_usr/doc/copyright/GPL,
> >   and a file /my_usr/share/doc/test3/copyright
> You are right which is why test3 would have a critical bug filed against it
> since it creates both /usr/doc/P and /usr/share/doc/P (these are the
> "critical" requrements of point 2 in the proposal).  test3 (mimicking
> te fixed base-files) should *only* have /usr/share/doc files.  (In the
> proposal it is furthermore responsible for the /usr/doc symlink even if it
> declares it as a directory, sic, thats the only slack needed.)
>
> So indeed those three packages will not be handled correctly.

Then please provide a test3 .deb that *does* work. Simply getting rid of
all the /my_usr/doc references in test3 is *not* enough.

* install test3_2.0_all.deb
* note that /my_usr contains /my_usr/share but not /my_usr/doc
* ln -s share/doc /my_usr/doc
* dpkg -i test1_1.0_all.deb
* dpkg -i test1_2.0_all.deb
* Notice dpkg complains and that /my_usr/share/doc/test1 is now empty,
  while dpkg -L test1 says it shouldn't be.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpLK9VwTb7rA.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Antti-Juhani Kaijanaho]

On Tue, Aug 03, 1999 at 09:22:27AM -0400, Michael Stone wrote:
> Sure it's legal, but was it a good idea?

You could ask the same question from a different perspective: was it a
good idea to change policy to use /usr/share/doc before the transition
was hashed out?  And is it a good idea to leave it that way?

Perhaps the change should be reverted until we have a solution.

> Do you want to argue that the
> current state of the distibution is a Good Thing?

Well, I don't see any grave problems in having docs in two different
places.  No essential part of the system breaks by that, it just causes
some minor inconvenience.

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   "... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Joseph Carter]

On Tue, Aug 03, 1999 at 12:05:39PM +0200, [EMAIL PROTECTED] wrote:
> Dear Joseph Carter,
> 
> I'm sorry to shout but please read what I write.
> 
> > All right dammit, here we go...  built a package crap 1.0-1, here is the
> > listing:
> >... 
> > /usr/lib/crap/olddir
> >...
> > Do you believe us yet?  What more proof do you possibly need?
> 
> I am happy to tell you that we agree completely on the behaviour of dpkg on 
> your example.  But you are ignoring a very important aspect of my proposal: 
> THIS ONLY HAPPENS FOR DIRECTORIES INTERNAL TO PACKAGES.  It happens because 
> olddir is actually REMOVED by the deinstallation.
> 
> For directories that are not removed there is NO PROBLEM.  Fortunately
> /usr/doc is not removed unless everything is removed.  This is a crucial
> property of the proposal.  Now back to the regular (constructive)
> discussion...our goal is to find a solution, after all :)

But you see, the file was removed from NEWDIR too!  Totally gone.
Deleted.  if it were not deleted, olddir would not have been deleted
(non-empty)...  The dpkg bug STILL applies and I can demonstrate that too
if you like.


> What other problems could there be with my proposal.

Just dpkg.  If someone fixes the damned package manager we can just move
the damned /usr/doc directory and replace it with a damned symlink that
could be pointing to another damned filesystem for all anyone cares right
now because the damned package manager would check the damned real paths
before I does a damned thing..  (waits for someone to catch the blatant
reference contained in this paragraph ...)

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
 netgod: My calculator has more registers than the x86, and
 -thats- sad



pgpirhfeQxZKt.pgp
Description: PGP signature

Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

[Joseph Carter]

On Tue, Aug 03, 1999 at 02:39:37PM +0200, Santiago Vila wrote:
> >While the FHS mandates the mail spool be accessable as /var/mail, it is
> >important to retain compatibility with older packages and locally
> >compiled programs.  Packages using the mail spool should use /var/mail
> >and declare dependency on base-files (>= #BASEFILESVER#).
> 
> I second this proposal, but please change the word "dependency"
> by "Pre-Dependency" (otherwise I would formally object ;-).
> 
> Rationale: base-files (>=whatever) must be unpacked and *configured*
> before *any* package using /var/mail is *unpacked*, because the symlink
> /var/mail -> /var/spool/mail will be handled in base-files' postinst.

Obviously and I support this addition.


> [ Try to think what happens if an important program start to access
>   /var/mail without /var/mail being there yet ].
> 
> BTW: The footnote pointed out by Antti-Juhani should be reworded also.
> (Yes, this is the footnote saying we should still follow /var/spool/mail
> regardless of what FHS says).

I oppose the footnote.  There is no reason why packages cannot and should
not use /var/mail right now (pending postinst of a working base-files that
will create it)


The argument that some of the dselect methods do not properly handle
package ordering is IMO a bad reason not to do something.  If anything,
they should be fixed.  Same goes for dpkg and symlinks.

In any event unlike the symlinks issue, there is no harm that is not
already clearly documented in using /var/mail.  You might have to run a
few extra installs or configures but if your dselect method is that broken
you're going to have to do that anyway---and already have been doing it
anyway.  New users will never see these broken things.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
 hmm, is there a --now-dammit option for exim?



pgpBgJXBxGqbl.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[robbie]

Hi

Here is my idea for dealing with the /usr/share/doc problem. Have a
symlink in /usr/doc for each package which has moved to /usr/share/doc.
The symlinks could be created by the postinst of each package (imho not a
good idea), or dpkg could be modified to run scripts in
/etc/post-dpkg-install.d after installing or upgrading packages. A
/usr/doc compatability package would contain a script to create the
symlinks. This would also work if dpkg was not upgraded, except the script
would have to be run manually or from a cron job.


 -- 
Rob Murray

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Michael Stone]

On Tue, Aug 03, 1999 at 06:07:55PM +0300, Antti-Juhani Kaijanaho wrote:
> On Tue, Aug 03, 1999 at 09:22:27AM -0400, Michael Stone wrote:
> > Sure it's legal, but was it a good idea?
> 
> You could ask the same question from a different perspective: was it a
> good idea to change policy to use /usr/share/doc before the transition
> was hashed out?  And is it a good idea to leave it that way?
> 
> Perhaps the change should be reverted until we have a solution.

That's my #1 goal. 

> > Do you want to argue that the
> > current state of the distibution is a Good Thing?
> 
> Well, I don't see any grave problems in having docs in two different
> places.  No essential part of the system breaks by that, it just causes
> some minor inconvenience.

Well, there are the *weeks* we've spent arguing over this with no end in
sight. And since the the distribution is in an inconsistent state (not
all /usr/doc or /usr/share/doc, but a mixture of both) the problem is
more difficult because there are more cases to deal with. If people
would have some patience to wait for a consensus, we could do this with
less argument, IMHO.

Mike Stone

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Antti-Juhani Kaijanaho]

On Tue, Aug 03, 1999 at 12:11:21PM -0400, Michael Stone wrote:
> If people
> would have some patience to wait for a consensus, we could do this with
> less argument, IMHO.

It should be possible for a developer to trust the policy documents.
If they don't reflect the consensus, the policy document should be
changed.

I'm not reverting my packages as long as policy dictates /usr/share/doc.
The issue is not that critical.

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   "... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Joseph Carter]

On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> On Tue, Aug 03, 1999 at 09:21:05PM +1000, Anthony Towns wrote:
> > Possibly I'm just misunderstanding what you're suggesting should be done
> > though. Can you give a sequence of commands that does whatever you're
> > suggesting, and still has those three packages survive unscathed?
> 
> That's simple enough. This all only works if there is no /usr/share/doc
> and you can move /usr/doc in an atomic operation.

Your assessment is flawed---it assumes facts like /usr/share and /usr/doc
being on the same partition.  You cannot have an atomic move in this case.


> IMHO, packages that
> started using /usr/share/doc were premature in that usage and shouldn't
> get special accomodation. For now, packages should be built to install
> into /usr/doc without concern for whether that's a symlink or not. We
> can worry about whether we want to deal with the symlink at a later
> date.

Ignore the problem and it'll go away?  feh.


We put off the archive restructure discussion until hamm was released, but
it never got addressed until we were gearing up for slink release and was
put off again.  Now it's come up still again in time for it to be put
aside until potato's release.

I figure by the end of time (1Q2038) we'll have figured out what to do
with /usr/doc and have the archive restructure happen.  At this rate it'll
take that long for the decision to decide whether or not we should decide
to do these things or not will be made.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
 Gruuk: UFies are above and beyond the human race :)



pgpoCxWAndEhA.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Joseph Carter]

On Tue, Aug 03, 1999 at 06:07:55PM +0300, Antti-Juhani Kaijanaho wrote:
> > Sure it's legal, but was it a good idea?
> 
> You could ask the same question from a different perspective: was it a
> good idea to change policy to use /usr/share/doc before the transition
> was hashed out?  And is it a good idea to leave it that way?
> 
> Perhaps the change should be reverted until we have a solution.

NO dammit!  We made our decision.  If we start second guessing every
implemented proposal the second it's implemented because it won't be easy
we will NEVER GET ANYTHING DONE!

I will say once again that I believe fully I was right before in
suggesting that joeyh and manoj simply decide how to handle the /usr/doc
mess and be done with it.  I suspect by no other method will we see an end
to this.


> > Do you want to argue that the
> > current state of the distibution is a Good Thing?
> 
> Well, I don't see any grave problems in having docs in two different
> places.  No essential part of the system breaks by that, it just causes
> some minor inconvenience.

inconvenience yes, minor no.  It's damned annoying.  But I'd live with it
if this issue is settled faster for it.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
 has /usr/bin/emacs been put into /etc/shells yet?  :P



pgpF7WLgTB4h5.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Joseph Carter]

On Tue, Aug 03, 1999 at 07:29:43PM +0300, Antti-Juhani Kaijanaho wrote:
> > If people
> > would have some patience to wait for a consensus, we could do this with
> > less argument, IMHO.
> 
> It should be possible for a developer to trust the policy documents.
> If they don't reflect the consensus, the policy document should be
> changed.
> 
> I'm not reverting my packages as long as policy dictates /usr/share/doc.
> The issue is not that critical.

We had a consensus.  Those people now wanting to undo the change had
plenty of opportunity to cause the change to never happen in the first
place.

Arguably we did realize after we agreed to do it that it wouldn't be so
easily done.  For that reason, we started to turn our attention to how's.

This discussion should be about how to make /usr/share/doc work right now
as it began---not a small group deciding that they want to second guess
everyone else.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
Most of us feel that marketing types are like a dangerous weapon - keep
'em unloaded and locked up in a cupboard, and only bring them out when
you need them to do a job.
-- Craig Sanders



pgpb8WQPTCLTg.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Michael Stone]

On Tue, Aug 03, 1999 at 09:35:52AM -0700, Joseph Carter wrote:
> On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> > That's simple enough. This all only works if there is no /usr/share/doc
> > and you can move /usr/doc in an atomic operation.
> 
> Your assessment is flawed---it assumes facts like /usr/share and /usr/doc
> being on the same partition.  You cannot have an atomic move in this case.

In which case you leave things in /usr/doc and put the symlink from
/usr/share/doc and let the admin handle it if he sees fit. Having
/usr/doc or /usr/share on a separate partition is a site-specific
decision, and I think it's reasonable to have the appropriate admin
decide what to do in this case.

> > IMHO, packages that
> > started using /usr/share/doc were premature in that usage and shouldn't
> > get special accomodation. For now, packages should be built to install
> > into /usr/doc without concern for whether that's a symlink or not. We
> > can worry about whether we want to deal with the symlink at a later
> > date.
> 
> Ignore the problem and it'll go away?  feh.

Is it the end of the world if there's a symlink from /usr/doc to
/usr/share/doc? Will the sky fall, or will there be other similarly
important reasons for dealing with it immediately? I think what we've
really learned here is that we need some flexibility in dealing with
this sort of thing. If we want to get rid of that symlink, we need a way
to create an appropriate dependency. Some people have suggested putting
a depends: base-files-whatever in _every_ debian package for the rest of
time. I'm not sure that's a clean approach. (I think it would be nicer
to abstract this more: packages already have to indicate what
policy-version they comply with, why not use that information to set the
appropriate dependency?) Until we have a clean way of dealing with this
problem, I don't see what harm there is in not jumping the gun. You can
spit juvenile responses like "feh" at me all you want, but that doesn't
help resolve this mess.

> We put off the archive restructure discussion until hamm was released, but
> it never got addressed until we were gearing up for slink release and was
> put off again.  Now it's come up still again in time for it to be put
> aside until potato's release.

So what? (I'm quite serious here: I'm still trying to understand what
the problem is.) Are we trying to shove things out, or are we trying to
get things right? If you come up with a clean solution, you might get
things closer to a resolution. Complaining that people aren't working
fast enough for you won't speed things up.

Mike Stone

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Joseph Carter]

On Tue, Aug 03, 1999 at 05:00:21PM +0100, [EMAIL PROTECTED] wrote:
> Here is my idea for dealing with the /usr/share/doc problem. Have a
> symlink in /usr/doc for each package which has moved to /usr/share/doc.

We wanted to do this---a few people don't like symlinks and effectively
killed off the proposal.  Unless the technical committee decides otherwise
or it goes up for general resolution vote, this will not happen.

Isn't red tape wonderful?  I'm seriously pleased at this point that
wichert won the election, I sure wouldn't want to deal with all of this
crap.  =p


> The symlinks could be created by the postinst of each package (imho not a
> good idea), or dpkg could be modified to run scripts in
> /etc/post-dpkg-install.d after installing or upgrading packages. A
> /usr/doc compatability package would contain a script to create the
> symlinks. This would also work if dpkg was not upgraded, except the script
> would have to be run manually or from a cron job.

If you're going to modify dpkg, do it right and fix the problem dpkg has
with symlinks and that it doesn't bother to follow them.  Then you'll have
the ability to just symlink /usr/doc to /usr/share/doc after a move.  It's
been noted that this move would not be atomic, but it could be done
safely.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
We all know Linux is great... it does infinite loops in 5 seconds.
-- Linus Torvalds



pgp8Og5yECLNS.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Michael Stone]

On Tue, Aug 03, 1999 at 09:45:25AM -0700, Joseph Carter wrote:
> On Tue, Aug 03, 1999 at 06:07:55PM +0300, Antti-Juhani Kaijanaho wrote:
> > > Sure it's legal, but was it a good idea?
> > 
> > You could ask the same question from a different perspective: was it a
> > good idea to change policy to use /usr/share/doc before the transition
> > was hashed out?  And is it a good idea to leave it that way?
> > 
> > Perhaps the change should be reverted until we have a solution.
> 
> NO dammit!  

grow up.

> We made our decision.  If we start second guessing every
> implemented proposal the second it's implemented because it won't be easy
> we will NEVER GET ANYTHING DONE!

Maybe in the future we should hold off making drastic changes like this
until there's a plan of action. There were comments at the time this
proposal was made that the transition would be a problem. The response
then was that things would get worked out after the policy was changed.
That was wishful thinking, and we're seeing the results of that mistake.

Mike Stone

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Joseph Carter]

On Tue, Aug 03, 1999 at 12:56:41PM -0400, Michael Stone wrote:
> > Ignore the problem and it'll go away?  feh.
> 
> Is it the end of the world if there's a symlink from /usr/doc to
> /usr/share/doc? Will the sky fall, or will there be other similarly
> important reasons for dealing with it immediately? I think what we've
> really learned here is that we need some flexibility in dealing with
> this sort of thing.

As a matter of fact, I just posted a message this morning demonstrating
that should a package move to /usr/share/doc at any point after its files
get moved in this fashion, it WILL in fact cause dpkg to erase the
documentation, something that it will happily do quietly and will require
reinstallation of the package in order to get the docs back.


> If we want to get rid of that symlink, we need a way
> to create an appropriate dependency. Some people have suggested putting
> a depends: base-files-whatever in _every_ debian package for the rest of
> time. I'm not sure that's a clean approach. (I think it would be nicer
> to abstract this more: packages already have to indicate what
> policy-version they comply with, why not use that information to set the
> appropriate dependency?) Until we have a clean way of dealing with this
> problem, I don't see what harm there is in not jumping the gun. You can
> spit juvenile responses like "feh" at me all you want, but that doesn't
> help resolve this mess.

This will be my last message to you until you take the time to read the
rest of the discussion.  Think and say what you will about me, I frankly
don't care.  But at least I'm working on solutions to problems, rather
than trying to take the cop-out approach of putting it off until later.


> > We put off the archive restructure discussion until hamm was released, but
> > it never got addressed until we were gearing up for slink release and was
> > put off again.  Now it's come up still again in time for it to be put
> > aside until potato's release.
> 
> So what? (I'm quite serious here: I'm still trying to understand what
> the problem is.) Are we trying to shove things out, or are we trying to
> get things right? If you come up with a clean solution, you might get
> things closer to a resolution. Complaining that people aren't working
> fast enough for you won't speed things up.

I really suggest you go back and read the two dozen or more messages in
which people who should be regarded as much more authoritive on the
subject than I have said that dpkg will do bad things if symlinks are
used.

The thought of moving /usr/doc is one I have supported, however in every
message I've written supporting it I've said up front that dpkg ABSOLUTELY
MUST BE FIXED prior to this happening.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
* bma is a yank
* Knghtbrd is a Knghtbrd
* dhd is also a yank
* Espy is evil
* Knghtbrd believes Espy



pgpLv3w6yUuSj.pgp
Description: PGP signature

Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

[Kai Henningsen]

[EMAIL PROTECTED] (Santiago Vila)  wrote on 29.07.99 in <[EMAIL PROTECTED]>:

> * Every package install files in /usr/doc/.

Well, every package *should* do that.

MfG Kai

Bug#40766: Rewrite of "configuration files" section

[Kai Henningsen]

[EMAIL PROTECTED] (Steve Greenland)  wrote on 17.07.99 in <[EMAIL PROTECTED]>:

> BTW, both this proposal (#40766) and the general clean-up proposal
> (#40767) are currently stalled with only one official seconder (Joey
> Hess). I'd guess that Hamish generally approves...but unless I get at
> least one more second, I'm going to have to let these drop.

I second this. BTW, where are the policy changing rules written down? I  
just looked and couldn't find them.

MfG Kai

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Antti-Juhani Kaijanaho]

On Tue, Aug 03, 1999 at 09:53:24AM -0700, Joseph Carter wrote:
> Those people now wanting to undo the change had
> plenty of opportunity to cause the change to never happen in the first
> place.

Are you saying I should be actively violating Policy?

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   "... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)

Bug#40767: PROPOSED] wording cleanup w.r.t. conffile/configuration

[Kai Henningsen]

[EMAIL PROTECTED] (Julian Gilbey)  wrote on 18.07.99 in <[EMAIL PROTECTED]>:

> Seconded.

Seconded.


MfG Kai

Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on b

[Kai Henningsen]

[EMAIL PROTECTED] (Richard Braakman)  wrote on 02.08.99 in <[EMAIL PROTECTED]>:

> Is there any case where one would want a Build-Conflicts?  Allowing
> them will complicate all the code that deals with build dependencies,
> whether they are used or not.

The only one I can think of is configure picking up unwanted stuff, and  
there should be better ways to deal with that problem.

MfG Kai

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Antti-Juhani Kaijanaho]

On Tue, Aug 03, 1999 at 08:56:10PM +0300, Antti-Juhani Kaijanaho wrote:
> Are you saying I should be actively violating Policy?

Oops, I think I misread Joseph.  Sorry.

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   "... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Antti-Juhani Kaijanaho]

On Tue, Aug 03, 1999 at 09:53:24AM -0700, Joseph Carter wrote:
> We had a consensus.  Those people now wanting to undo the change had
> plenty of opportunity to cause the change to never happen in the first
> place.

ITYM "Those people now wanting to have a decent transition method
had plenty of opportunity to devise one before the change had made."
Now, if people feel that the decision which was made (move /usr/doc
to /usr/share/doc with no particular planned transition) is incorrect,
it should be either corrected or reverted.

> Arguably we did realize after we agreed to do it that it wouldn't be so
> easily done.  For that reason, we started to turn our attention to how's.

And while we argue, it would be useful to revert the change from the
policy documents for now.

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   "... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)

Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on b

[Jason Gunthorpe]

On 3 Aug 1999, Kai Henningsen wrote:

> [EMAIL PROTECTED] (Richard Braakman)  wrote on 02.08.99 in <[EMAIL 
> PROTECTED]>:
> 
> > Is there any case where one would want a Build-Conflicts?  Allowing
> > them will complicate all the code that deals with build dependencies,
> > whether they are used or not.
> 
> The only one I can think of is configure picking up unwanted stuff, and  
> there should be better ways to deal with that problem.

I Agree, it is bad enough that we have to deal with the uncertanty
autoconf introduces, we certainly should not be condoning this!

Packages that have optional things should have those things forced on
either by using configure options or by editing the configure script to
give such options.

For example, a wack of the recent SSH uploads on various archs didn't have
PAM because configure silently disabled it!

Jason

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Joseph Carter]

On Tue, Aug 03, 1999 at 08:56:10PM +0300, Antti-Juhani Kaijanaho wrote:
> > Those people now wanting to undo the change had
> > plenty of opportunity to cause the change to never happen in the first
> > place.
> 
> Are you saying I should be actively violating Policy?

I'm saying our effort should be spent making /usr/share/doc work, not
debating whether or not we should be making it work or just going back go
/usr/doc...  We're past that point already.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
 dhd:  R you part of the secret debian overstructure?
 no. there is no secret debian overstructure.
 although, now that somebody brought it up, let's start one
:-)
 CosmicRay - why not, sounds like a fun way to spend the
   afternoon =D



pgpdfBCKNRFCV.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Michael Stone]

On Tue, Aug 03, 1999 at 10:14:17PM +1000, Anthony Towns wrote:
> On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> > On Tue, Aug 03, 1999 at 09:21:05PM +1000, Anthony Towns wrote:
> > > Possibly I'm just misunderstanding what you're suggesting should be done
> > > though. Can you give a sequence of commands that does whatever you're
> > > suggesting, and still has those three packages survive unscathed?
> > That's simple enough.
> 
> Then please give a concrete example, with actual .debs and actual shell
> commands.

I'm not going to do debs at this point. (It won't work anyway, because
of /usr/share/doc) I also don't know how to do it as a shell script,
because gnu mv is horribly broken. Here's a C snippit:

main() {
rename("/usr/doc","/usr/share/doc");
symlink("/usr/share/doc","/usr/doc");
symlink("/usr/doc","/usr/share/doc");
}

Mike Stone

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Michael Stone]

On Wed, Aug 04, 1999 at 12:46:34AM +1000, Anthony Towns wrote:
> Then please provide a test3 .deb that *does* work. Simply getting rid of
> all the /my_usr/doc references in test3 is *not* enough.
> 
> * install test3_2.0_all.deb
> * note that /my_usr contains /my_usr/share but not /my_usr/doc
> * ln -s share/doc /my_usr/doc
> * dpkg -i test1_1.0_all.deb
> * dpkg -i test1_2.0_all.deb
> * Notice dpkg complains and that /my_usr/share/doc/test1 is now empty,
>   while dpkg -L test1 says it shouldn't be.

I've completely lost track of what you're doing at this point. I'll
submit this, though: I moved /usr/share/doc out of the way and did the
move-doc-to-share/doc-and-symlink-usr/doc thing. I installed some
packages and removed some packages. Everything seems to be fine. What
_is_ the failure case here?

Mike Stone



pgpFZAkofEJut.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Anthony Towns]

On Tue, Aug 03, 1999 at 05:44:40PM -0400, Michael Stone wrote:
> On Wed, Aug 04, 1999 at 12:46:34AM +1000, Anthony Towns wrote:
> > Then please provide a test3 .deb that *does* work. Simply getting rid of
> > all the /my_usr/doc references in test3 is *not* enough.
> > * install test3_2.0_all.deb
> > * note that /my_usr contains /my_usr/share but not /my_usr/doc
> > * ln -s share/doc /my_usr/doc
> > * dpkg -i test1_1.0_all.deb
> > * dpkg -i test1_2.0_all.deb
> > * Notice dpkg complains and that /my_usr/share/doc/test1 is now empty,
> >   while dpkg -L test1 says it shouldn't be.
> I've completely lost track of what you're doing at this point.

"test1 v1.0" uses /my_usr/doc.
"test1 v2.0" uses /my_usr/share/doc.

If there's a symlink from /my_usr/doc to /my_usr/share/doc, upgrading from
test1 v1.0 to v2.0 causes test1's documentation to be lost.

Simple as that.

Kristoffer has made a couple of suggestions that he claims fixes things.
As far as I can tell they *don't*.

> I'll
> submit this, though: I moved /usr/share/doc out of the way and did the
> move-doc-to-share/doc-and-symlink-usr/doc thing. I installed some
> packages and removed some packages. Everything seems to be fine. What
> _is_ the failure case here?

I made the debs available for a reason. Install them. Type the commands.
See what happens. Stop talking about what you *think*'s right, and start
actually *testing* it. This isn't a debating exercise: there *are* right
and wrong answers.

AFAICT, this is one of the latter.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpiEIPGq7xfM.pgp
Description: PGP signature

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

[Anthony Towns]

On Tue, Aug 03, 1999 at 05:32:33PM -0400, Michael Stone wrote:
> > > > Possibly I'm just misunderstanding what you're suggesting should be done
> > > > though. Can you give a sequence of commands that does whatever you're
> > > > suggesting, and still has those three packages survive unscathed?
> > > That's simple enough.
> > Then please give a concrete example, with actual .debs and actual shell
> > commands.
> I'm not going to do debs at this point. (It won't work anyway, because
> of /usr/share/doc)

So make some fake debs that use /my_usr/share/doc and show that upgrading
and everything actually works. Heck, I've already given you some sample
debs that do this.

> I also don't know how to do it as a shell script,
> because gnu mv is horribly broken. Here's a C snippit:
> main() {
> rename("/usr/doc","/usr/share/doc");
> symlink("/usr/share/doc","/usr/doc");
> symlink("/usr/doc","/usr/share/doc");
> }

This is broken and doesn't work. You've already had three concrete
demonstrations of this.

Sheesh.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpsmgQrCpzoJ.pgp
Description: PGP signature

Let's just convert debhelper and do NMUs

[Julian Gilbey]

On the /usr/share/doc vs. /usr/doc issue

Given that:

 - we're going in circles at present
 - dpkg is unlikely to be fixed in the near future, and relying on the
   user having a working dpkg is a dangerous assumption
 - most packages use either debhelper or debstd

why don't we follow the Perl team's lead by modifying debhelper
appropriately (I believe debstd has already been done) and giving a
month's notice to all developers about rebuilding their packages with
the new /usr/share/doc location using the new debhelper/debstd if they
use those tools.  Any packages which have not been so modified in that
period can be auto-rebuilt if they use deb{helper,std}, leaving a
relatively small number of packages using /usr/doc which will need
manual NMUs.  And all that would be necessary in the short term for
those packages would be
 mkdir debian/tmp/usr/share; mv debian/tmp/usr/doc debian/tmp/usr/share
or similar in the appropriate place in the debian/rules file.

I think that with a change as large as this, people must expect
inconsistencies if they perform partial upgrades/downgrades.  And the
longer we don't do anything, the closer we will be to release and the
harder it will become.

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg

Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

[Anthony Towns]

On Tue, Aug 03, 1999 at 08:32:57AM -0700, Joseph Carter wrote:
> > I second this proposal, but please change the word "dependency"
> > by "Pre-Dependency" (otherwise I would formally object ;-).
> > Rationale: base-files (>=whatever) must be unpacked and *configured*
> > before *any* package using /var/mail is *unpacked*, because the symlink
> > /var/mail -> /var/spool/mail will be handled in base-files' postinst.
> Obviously and I support this addition.

I'm confused. No packages install things into /var/spool/mail or /var/mail
directly, do they? Nor can I see why they'd want to use this as part of
their preinst or even postinst. Neither exim nor mutt include /var/anything
in their dpkg -L output.

Why does /var/mail have to exist before those packages are unpacked?

Before they're actually *executed*, I could believe, but that only
requires an ordinary dependency, no?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpYAiuJ5VfEn.pgp
Description: PGP signature

RE: Let's just convert debhelper and do NMUs

[Sean 'Shaleh' Perry]

Joeyh has *NOT* modified debhelper. This is a conscious decision, not slacking. 
He states that he will change it when policy has decided what the right thing
is.  Until then debhelper stands as is.

Re: Let's just convert debhelper and do NMUs

[Joey Hess]

Sean 'Shaleh' Perry wrote:
> Joeyh has *NOT* modified debhelper. This is a conscious decision, not 
> slacking.
> He states that he will change it when policy has decided what the right thing
> is.  Until then debhelper stands as is.

Sean knows exactly where I stand on this issue. I just want to add that if
people decide this idea is the way to go, I will modify debhelper for it.

Personally, I am opposed to the idea because it ignores the entire partial
upgrades question. But I can be overridden.

-- 
see shy jo, getting tired of saying this stuff and glad to let Sean do it
for once.