Ballot Re: Moving to the FHS: not right now!
This ballot is going to be a bit crude. The current circumstances are
frustratingly non-optimal, and I've already taken too long preparing
this ballot.
Note that *none* of these proposals were ever actually delivered to
the debian-ctte list. Instead, they were bounced to the moderators
[who happen to be the debian-ctte members.]
As a separate action, someone [me?] needs to go back and approve a number
of messages. For this ballot, however, I'm quoting the messages in
their entirety [possibly with cosmetic edits -- not changing any words
but occasionally altering appearance].
I'm sorry this message is so long, but I must ask each of you to study
it carefully.
Ballot summary:
0 further discussion
1 forest of symlinks
2 leave things as they are
3 revert fsstnd->fhs directory changes, with advice
4 alternate amended reversion
You can skip between proposals by searching for a line which begins
with "==", or which begins with "ballot item #".
Please pgp sign votes, and send them to the list [not as bounces].
Details:
======================================================================
[NOT ON THE BALLOT -- BACKGROUND ONLY.]
5 August -- Message from leader@debian.org. This states problem but
does not provide a proposal for dealing with it.
----------------------------------------------------------------------
Date: Thu, 5 Aug 1999 15:09:51 +0200
From: Wichert Akkerman - Debian Project Leader <leader@debian.org>
To: debian-devel-announce@lists.debian.org, debian-ctte@lists.debian.org
Subject: Moving to the FHS: not right now!
Message-Id: <[🔎] 19990805150951.B13011@soil.nl>
X-Diagnostic: Unapproved submission to debian-ctte
As everyone has probably noticed by now the new policy states that
packages should follow the FHS instead of the FSSTD. This means some
big changes have to be made, such as moving /usr/doc to /usr/share/doc.
How this move has to be made has not been decided yet. Simply moving
will break things, as can be seen by the dhelp package that suddenly
refused to handle 99% of the documentation since it no longer supported
/usr/doc. A strategy will have to be made for moving to the FHS without
breaking anything.
Possible strategies have been discussed on debian-policy for a while now,
but due to conflicting opinions no consensus has been reached. In the
meantime however some packages have begun to follow the FHS and thereby
causing some problems.
Luckily the constitution provides us with a way to solve this: the
Technical Committee can be asked to decide on a strategy which people
will have to follow. I hereby ask them to study this and come up with a
strategy for moving to the FHS.
Until that decision has been made I request all developers to NOT move
to the FHS right now.
Wichert.
======================================================================
6 August
ballot item #1 FOREST OF SYMLINKS
----------------------------------------------------------------------
To: Wichert Akkerman - Debian Project Leader <leader@debian.org>
Cc: debian-ctte@lists.debian.org
Subject: Re: Moving to the FHS: not right now!
From: Manoj Srivastava <srivasta@debian.org>
Date: 06 Aug 1999 11:20:49 -0500
Message-Id: <[🔎] 87lnbokhi6.fsf@glaurung.green-gryphon.com>
X-Diagnostic: Unapproved submission to debian-ctte
Hi,
>>"Wichert" == Wichert Akkerman <- Debian Project Leader <leader@debian.org>> writes:
Wichert> Luckily the constitution provides us with a way to solve this:
Wichert> the Technical Committee can be asked to decide on a strategy
Wichert> which people will have to follow. I hereby ask them to study
Wichert> this and come up with a strategy for moving to the FHS.
A draft proposal follows.
Problem statement:
The FSSTND location for package documentation, /usr/doc, has moved to
the location /usr/share/doc in the FHS. Now that we have formally
decided to adopt the FHS, we need to ensure the transition is as
smooth as we can make it.
Some of the constraints are:
* The transition may take a long time, going by previous
transitions, and not all packages are upgraded anywhere near
simultaneously.
I think that expecting _*all*_ packages to have moved before we
release potato is futile, unless we do not plan on releasing
potato for 18 months or so. We *_cannot_* expect to get FHS
compliance in place by potato.
* We should not break backwards compatibility during the transition
period. This is a quality of implementation issue
During the transition, we need to provide backwards
compatibility, firstly for programs like `dwww', and `dhelp', and
also for our users who have gotten used to looking under a single
dir (`/usr/doc/') for docs (`/usr/doc/`package''). During the
transition, the documentation could be in in two places, and that
is not good.
* There is no elegant way to piece wise move a directory
spanning multiple packages with dpkg. Basically any attempt
to provide 'legacy' symlinks that make /usr/doc/foo ==
/usr/share/doc/foo will either break upgrading, downgrading
or both, unless special care is taken
dpkg has no ability to resolve multiple paths to the same files in
it's database, so it sees /usr/share/doc/pkg/bar and
/usr/doc/pkg/bar as -different non overwriting- files and will end
up doing the wrong thing when it comes time to erase the old
versions files. Basically it will do:
create /usr/share/doc/pkg/bar
rm /usr/doc/pkg/bar
Which is perfectly sensible -IF- they did not happen to be the same
directory!!
What makes this directory move different from the other changes
mandated by the FHS is the human element: humans are used to
looking for documentation under one directory, namely,
/usr/doc/<package>, and having the documentation in two directories
is breaking that expectation.
What follows is an updated solution to this issue (the so called
symlink solution).
Several other solutions have also been proposed to address this
situation. I shall present a (hopefully unbiased) selection of
solutions, with arguments for and against each solution.
Proposed solution
--------------------
I propose that there be a symlink from /usr/doc/package =>
/usr/share/doc/package, managed by the package itself. Since there is
some concern that the packaging system does not deal well with
replacing a directory with a symbolic link, it is suggested that the
link be manipulated in the maintainer scripts postinst and postrm.
We create the postinst, prerm now, installing the symlink, Once
the move is over, we just have a prerm script removing the
symlink. another release, (potato+2), we stop bothering, since we
would have handled the most common case (and provide an base-files
postinst script removing the symlinks for upgrades at that point).
Yes, this is a long period, but not forever (which was one of
the major objections to this proposal)
So potato packages should have: (effectively)
postinst install upgrade:
if [ -d /usr/doc ]; then
if [ ! -e /usr/doc/$package -a -d /usr/share/doc/$package ]; then
ln -s /usr/share/doc/$package /usr/doc/$package
fi
fi
prerm remove upgrade:
if [ -d /usr/doc ]; then
if [ -L /usr/doc/$package ]; then
rm -f /usr/doc/$package
fi
fi
The prerm removes the symlink, and the postinst reinstates
it as necessary. The only problem is redundant symlinks when you're
doing partial upgrades to woody+1 (or later), which no longer need
any symlinks, from potato/woody. But they still all point at the
correct places. This is handled by a base-files postinst removing the
junk symlinks (details below).
This is how it works:
1. Policy 3.X mandates that packages that move the docs to
/usr/share/doc must provide a compatibility symlink in /usr/doc.
This shall allow packages to incrementally move to policy 3.X,
while providing compatibility with older systems.
(/usr/doc/package symlink is handled by package)
Thus, potato ships with a full /usr/doc/ (some of which is symlinks),
and a partial /usr/share/doc.
2. Post potato, we continue the transition, with the symlinks in
place. Before freeze, we file important bugs against any
package that has not been moved over (in one and a half
release periods, we may be actually able to accomplish this),
with NMU-fests to bring over the others.
Thus, potato+1 (woody) ships with a full /usr/share/doc, and a
/usr/doc full of symlinks.
3. At a later date, another policy (say, 4.X) shall ask for
packages to no longer provide the link (and possibly remove
links from /usr/doc). We can also provide a script (possibly
in base-files postinst) that rm's symlinks from within
/usr/doc. woody+1 may ship with such a script. (there was a
proposal as well that potato+2 (woody+1) ships with just the
prerms, and not the base file script, and potato+3 ships
with the base-file script, but I am not sure this long a
reversion period is required).
No dependency on this base-files shall be required, since they shall
work with or without a symlink in /usr/doc (and /usr/share/doc shall
be fully populated by then).
Thus, partial upgrades to potato and woody have a complete /usr/doc,
and full upgrades to woody have a complete /usr/share, and symlinks
throughout /usr/doc. Partial upgrades to anything beyond woody might
have old files left in /usr/doc, but they'll get moved when whoever
finally gets around to run an apt-get dist-upgrade.
I understand that the forest of symlinks is ugly, but it is
technically sound, it maintains backwards compatibility, it allows
incremental compliance to FHS, and caters to a hybrid system. I submit
that aesthetics takes a back seat to functionality.
I fail to see what the big problem with fairly obvious symlinks
existing on a system that's halfway between two significantly
different file system standards. I also can't see admins being
particularly bothered by the existence of such symlinks on such
systems.
OTOH, it *is* inconvenient to have documentation scattered
inconsistently between /usr/doc and /usr/share/doc. We've even had
user complaints on this list about it.
To the objection that it shall cause package to be modified twice, I
say that
* This is a complex transition, and may require this to meet the
constraints of the situation
* One modification of the packages is required anyway for compliance
with the FHS.
* The second modification, namely, the removal of the symbolic
link, shall be well into the future, and added to a future policy
change. It is conceivable that the packages may need to change
for policy updates in any case.
The symlink proposal is far from perfect --- adding postinst's and
prerm's to every package with the same half dozen lines of code is
really pretty lame. The *proper*, forward thinking solution would be
to add a feature to dpkg to run specific items of code before and
after each dpkg run.
But modifying dpkg is infeasible, and we've agreed to, among other
things, keep the needs of our users at the forefront of our
minds. And from a user's perspective, something that keeps the
system tidy in the normal case, and works *now*, is much better than
idealistic fantasies like a working dpkg.
Overview of other solutions proposed.
----------------------------------------------------------------------
* do nothing special
- means the admin, and all automated tools have to look in both places
or miss documentation
This essentially ignores the issues with the split locations
for the documentation. I think we can live with the problem, but as a
quality of implementation issue, it would be nice if we had a smoother
transition.
----------------------------------------------------------------------
* making a script that works out which of /usr/doc /usr/share/doc to use
- doesn't work for browsing by hand
- needs to be written/accessible from lots of different languages
- is significantly different to any other system on the planet
+ makes it easy to "support" /usr/local/doc or similar ("support"
in scare-quotes because I'm not really sure of the value of
such support in this case. YMMV)
[See Appendix A on details and commentary]
----------------------------------------------------------------------
* symlinks managed by postinst/prerm
- requires lots of packages to add postinsts/prerms for potato
and woody, and then to get rid of them for woody+1
- may leave crufty symlinks about on systems where (a) the admin
doesn't fix it (b) hasn't had the base packages upgraded to woody+1
+ allows incremental upgrades
+ allows for downgrades
+ does not involves a global change day
+ works with dpkg failings ;-)
[This was proposed and shot down because 4 people objected;]
[See Appendix B for details].
I think the symlinks proposal is the best one so far ---
it addresses the issue correctly, and it's drawbacks are both aesthetic
(crufty symlinks that don't damage the system; and extra postinsts)
and temporal (upgrading to woody+1 gets rid of both the symlinks and
the extra postinsts).
----------------------------------------------------------------------
* cronjob that adds/removes symlinks in cron.daily
- downgrading a package that uses /usr/share/doc to a prior version
that uses /usr/doc will cause dpkg to move files from
/usr/share/doc/foo to /usr/share/doc/foo via a symlink, which is
believed to be dangerous. (*)[proof in appendix C]
- may leave dangling symlinks / may not have symlinks for up to 24 hours
A cronjob is a bad idea because the links will persist for dpkg
operations and basically cause upgrades/downgrades to fail. This is
not a working solution.
----------------------------------------------------------------------
* mv /usr/doc/* /usr/share/doc
* Modify dpkg's internal databases (mainly the .list files in the
directory /var/lib/dpkg/info) so that they are in sync with the
previous changes.
+ would make the system to be /usr/share/doc-compliant.
+ would avoid to touch every maintainer script in every package.
+ would support upgrades and downgrades.
- fiddles with dpkg internals, against all warnings in the docs
- pointless unless the package is changed, or the next upgrade
creates the /usr/doc dir all over again
This isn't trivial, because you cannot be sure that /usr/doc and
/usr/share/doc are located at the same file system.
And don't miss the (few) packages which already moved to
/usr/share/doc (where some of them left back a .dhelp file in
/usr/doc/<package>). Also, doing it the way mv(1) does means
failures halfway through leave you with files in /usr/doc/foo and
/usr/share/doc/foo, which could be hard to deal with correctly.
If one uses tar/cpio to do the move, one should realize that if you
*do* have /usr and /usr/share on the same partition, you need to have
as much free space as /usr/doc takes up. Unless you do the move on
a directory by directory basis.
Also, fiddling with the dpkg database - bugs in the script can cause
catastrophic system failure by messing up the dpkg database (*) - must
be done by the admin by hand, rather than automatically as part of the
upgrade to potato/woody - script is difficult to get right on common
configurations
Messing with dpkg's database is *not* something to be done lightly.
Getting knowledgeable comment from the author's seems the *least* thing
that should be done.
This is not a working solution.
----------------------------------------------------------------------
* add support to dpkg for pre and post processing on a global basis
- requires dpkg modifications (*)
+ allows update-menus and similar programs to be implemented much more
cleanly.
This is not a working solution, given the timetable.
----------------------------------------------------------------------
* Stick with /usr/doc until potato is released, then begin a massive
migration, which may or may not involve symlinks.
- some people have already moved and may not want to move back.
- would need a policy amendment partially backing out of the FHS
move.
- requires all changes to be made in a single release cycle*
(or we're back in the same position we're in at the moment)
- delays the move to FHS compliance.
+ gives us a little more time to decide if we want crufty
symlinks, and if so, what's the best way to handle it.
+ no surprises to the user.
+ no changes to most packages till after potato's release.
----------------------------------------------------------------------
I consider the points marked with a (*) to be completely unacceptable.
By "completely unacceptable", I mean that it's unacceptable to just say
"we should do this". If you *can* do it (ie, write the program/make the
modifications), and then can show why the original fears were unfounded
(look, iwj even says this is okay!), then, naturally, there's no problem.
======================================================================
Appendix A
docdir() {
dirname $(grep "/doc/$1/copyright\$" /var/lib/dpkg/info/$1.list")
cddoc() {
cd $(docdir $1)
Now we're back to a single probe. We're just probing the
database, not the filesystem.
[This has to be in every environment, and needs to cater to all kinds
of shells, and shell scripts, and perl scripts, and ...]
> So we make it a script.
It doesn't just have to be in every user's environment, it has to be (or
at least, ought to be) easily available for arbitrary scripts/programs
to be able to access documentation. It thus needs to work conveniently
with csh, rc, perl, python and C.
It also adds another learning curve to Debian for, what appears to me
to be, very little benefit. Instead of just cd'ing to /usr/src/linux
and running make, we're meant to use kernel-package. Well, that's fine
--- kernel-package makes it a lot easier to deal with upgrading from
one kernel version to another keeping modules in sync and not leaving
cruft lying about on your disk. Instead of just cd'ing to /usr/doc and
poking around with your favourite utilities, you now have to either know
the name of the program in advance and use some special functions which
you've likely never heard of before.
Still does not answer less /usr/doc/<package>[TAB]
> Very true. There are always tradeoffs -- in this case, we gain
> flexibility.
To what end? Is /usr/local/doc particularly common anyway? We certainly
don't have any intention of keeping /usr/doc around, so having more than
one doc directory doesn't seem to help us.
Needless flexibility breeds bugs.
======================================================================
Appendix B
Details of dpkg lossage with symlinks.
----------------------------------------------------------------------
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 root 7 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
root@icarus2:/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.
> 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?
----------------------------------------------------------------------
On Tue, Aug 03, 1999 at 09:02:53PM -0400, Michael Stone wrote:
> (And thus useless to me.) I don't argue that dpkg has some problems with
> symlinks if a package changes the path by which it references one of its
> files. It does not have problems (as far as I have found) if a package
> consistently uses the same path when referencing the file, whether or
> not that path passes through a symlink. That's the case I'm interested
> in and which I've been testing.
*OH*. No, that's completely correct.
> No, what I wrote works fine. The examples were irrelavent. You
> apparantly ignored the part where I said that all packages should put
> their stuff into /usr/doc without regard for whether it's a symlink or
> anything else.
This means packages will have to use /usr/doc instead of /usr/share/doc
until dpkg is fixed. "until dpkg is fixed" could be forever.
This seems like it might also require pre-dependencies on base-files for
every package (so that they don't accidently create /usr/doc as an
actual directory instead of as a symlink).
Hmmm. This also seems like it might require pre-dependencies from every
package against the new version of dpkg that handles following symlinks
correctly.
> 1. use both /usr/doc and /usr/share/doc; this upsets the partial
> upgrade people, and worries the UI people.
"upsets" and "worries" aren't really very precise. It results in a
"needlessly" inconsistent user interface for accessing documentation
for potato and partial upgrades from <=potato to >potato.
> 2. use both /usr/doc and /usr/share/doc but provide symlinks from
> each package in one to each package in the other by means of
> preinst/rm scripts; this upsets the anti-bloat people and horrifies
> the elegance people :)
It creates postinst and prerms where there never used to be any, but lets
them go away after woody.
> 3. use both /usr/doc and /usr/share/doc but provide symlinks from
> each package in one to each package in the other by means of a cron
> job or somesuch; this upsets the partial upgrade people, horrifies
> the elegance people, and terrifies the people who don't want cron
> jobs automatically deleting things on their systems.
It means documentation can be lost when doing a downgrade from a
/usr/share-using package to a prior, /usr/doc-using, version of that
package.
It means dangling symlinks could exist for up to 24 hours (or however
often the job runs). It means symlinks might not exist for the same
amount of time.
> 4. use both /usr/doc and /usr/share/doc but provide symlinks from
> each package in one to each package in the other by means of an
> optional script run manually by the admin; this upsets the partial
> upgrade people, worries the UI people, and horrifies the elegance
> people.
Same problems as the cron job, and not automatic.
> Don't explicitly use /usr/share/doc yet, and we can rig up a symlink
> to effectively use /usr/share/doc until we come up with a better
> solution; this upsets the policy-says-I-can-therefor-I-must people
> and dismays the people who have already converted their packages
Requires changes to dpkg, which don't have a particular history of being
made. Possibly requires lots of pre-dependencies that will last for ever.
----------------------------------------------------------------------
----------------------------------------------------------------------
Appendix C
Has no one seriously considered the mess that will happen if you
try to follow this path (namely, making each package manage the
transition by itself)? Think about all the typos (like "[-L foo]")
that people are going to make, the number of link-handling scripts
that bomb out or do the wrong thing, the number of unwanted symlinks
that will be lying around once the dust settles, and the crap that
will live in the maintainer scripts forever (well, a long time). Think
about how few maintainers test their scripts exhaustively (for
idempotency etc.) (when doing upgrade, new install, failed-upgrade,
configure, remove, purge, etc.).
I will oppose the proposal unless it contains code fragments that a)
have been thoroughly tested, b) have been shown to be the only real
solution, and c) will be mandated.
One question, does the FHS permit "/usr/share/doc -> ../doc" ? If so,
there is a very simple solution (forbid the use of /usr/share/doc and
have base-files contain this symlink; this does not address mount and
partition issues).
A better solution (than the proposed one) would be one that has all
the code in only one place and the opportunity to fail at only one
time. Alas, I do not have such a thing.
Unfortunately, various people have pre-empted the policy discussion
and have started using /usr/share/doc already.
======================================================================
--
A fool's brain digests philosophy into folly, science into
superstition, and art into pedantry. Hence University
education. Shaw
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
======================================================================
14 August
ballot item #2 leave things as they are
----------------------------------------------------------------------
Date: Sun, 15 Aug 1999 09:14:48 -0400 (EDT)
From: Dale Scheetz <dwarf@polaris.net>
To: debian-ctte@lists.debian.org
Subject: Alternative to the symlink proposal.
Message-Id: <[🔎] Pine.LNX.3.96.990815090620.195D-100000@dwarf.polaris.net>
X-Diagnostic: Unapproved submission to debian-ctte
I'm not sure why Joey Hess felt unwilling to deliver this directly
(possibly because my request was done in private mail), but he has
delivered this alternate proposal for the move to /usr/share. (see
forwarded message below)
It is a bit more inclusive than the symlink proposal, which only deals
with the /usr/doc to /usr/share/doc transition, and includes the complete
transition of /usr to /usr/share (those components that will move, at
least).
With this proposal, we now have an alternative proposal, and can choose
between the two, rather than just deciding whether or not to accept the
symlink proposal.
While there are things to like in Joey's proposal, I'm not sure that it
addresses the "least suprise" conditions that Manoj's proposal tries to
resolve. We may still be looking at apples and oranges.
Anyone have thoughts on this?
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
---------- Forwarded message ----------
Date: Sat, 14 Aug 1999 19:22:48 -0700
From: Joey Hess <joey@kitenet.net>
To: Dale Scheetz <dwarf@polaris.net>
Subject: Re: I'd like to coordinate a major update of stable
Dale Scheetz wrote:
> Your comments about the /usr/share/doc transition has prompted this
> e-mail.
>
> I am very likely to get stuck with the Chair of the Technical Committee,
> and the current proposal (from Manoj) before the committee has no
> alternative proposal to judge against. I would very much appreciate your
> making a proposal to the committee as well, so we have at least two
> choices, rather than the single option currently being discussed.
>
> Can you do that?
Certianly. Please pass this on to the committe:
The proposal is that nothing be done to ease the transition to
/usr/share/doc, except a major update to stable be made before unstable is
released. This update will include updated versions of man, dwww, info, and
any other packages that use /usr/share/doc, /usr/share/man, or
/usr/share/info. The release notes for potato will reccommend that anyone
using a package from unstable first upgrade to the updated stable.
This is intended to be a compromise that can be acceptable to all parties,
not a technically perfect solution. The update to stable already appears to
be going to happen, with everyone in favor of it.
--
see shy jo
======================================================================
20 August
ballet item #3 revert fsstnd->fhs directory changes, with advice
----------------------------------------------------------------------
From: Ian Jackson <ian@davenant.greenend.org.uk>
Message-Id: <[🔎] 14269.55627.900414.390241@davenant.relativity.greenend.org.uk>
Date: Fri, 20 Aug 1999 23:40:11 +0100 (BST)
To: debian-ctte@lists.debian.org
Subject: Revised proposed interim FHS resolution
X-Diagnostic: Unapproved submission to debian-ctte
It seems to me that Manoj has got the impression I'm trying to make
the `old' FSSTND status quo permanent with my resolution. That's not
the case. I'm just trying to fix the immediate problem to produce
some calm and time for us to consider the transition.
Manoj: you must agree that there is need for us to discuss this,
because there is disagreement and we haven't come to consensus yet.
So, is it not right for us to mandate that the status quo be
preserved, as Wichert requested in his mail ?
Having looked at my propsed resolution it didn't make it clear that
it's an interim solution. So I've added a bit on the end saying what
the committee will do after this resolution - ie, look at the complex
issues surrounding symlinks, dpkg, existing packages, finding
documents, etc.
I propose the resolution below, in place of my previous one. Manoj,
if you don't agree with this as a status-quo-preserving resolution,
please propose amendments, or a counter-resolution.
I will call for a vote shortly.
Proposed resolution of the Technical Committee
`Interim decision to preserve status quo wrt fhs transition'
Given that:
* Wichert has made an announcement saying we should preserve the
status quo pending a decision;
* it will obviously take a little while to make a decision,
particularly given that the technical committee's internal mechanisms
haven't been debugged yet because they've not previously been used;
* packages already using /usr/share/doc may make whatever decision we
come up with hard to implemement;
* people on debian-policy have tried getting the policy reverted to
preserve the status quo as requested by Wichert, with no avail;
* no analysis of the changes between FSSTND and FHS seems to have
been made to determine whether to make the change and if so how best
to do it;
The Technical Committee mandates that, firstly:
* Until a the a list of the differences between FSSTND and FHS, with
a decision whether to change and if applicable a transition plan for
each, has been prepared, Debian should continue to use the FHS.
And in particular:
* Until a decision on transition to FHS directories has been made by
the Committee, /usr/share/doc, /var/state and /var/mail should not
yet be used to by Debian packages. Instead, packages should continue
to place files in and refer to /usr/doc, /var/lib and
/var/spool/mail.
Therefore:
* The policy manual should immediately be amended accordingly
immediately, to change the reference to the FHS back to the FSSTND,
and to add a comment saying that /usr/share/doc, /var/state and
/var/mail are not yet to be used or referred to.
* If the policy editors or policy group feel it necessary to ratify
this change to the policy manual with the formal policy process this
should be done after the policy has been changed; the policy editors
should change the policy manual and issue an updated version
immediately.
* Lintian and any other package checking software which has already
made the change to FHS should be changed back immediately.
Finally, the Technical Committee resolves that it will:
* Enquire with the debian-policy group, maintainers of packaging
tools, and other relevant Developers, to make clear in the minds of
the members of the Committee what the issues and options are with
respect to FHS transition;
* Discuss and agree a proposal for moving /usr/doc to /usr/share/doc,
including a transition plan;
* Discuss and agree policy on other aspects of FHS transition, or
agree to refer this matter back to the debian-policy group, possibly
with some specific advice.
Ian.
======================================================================
23 August
ballot item #4 alternate amended reversion
----------------------------------------------------------------------
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: debian-ctte@lists.debian.org
Subject: Re: Revised proposed interim FHS resolution
From: Manoj Srivastava <srivasta@debian.org>
Date: 23 Aug 1999 11:36:27 -0500
Message-Id: <[🔎] 877lmmbgj8.fsf@glaurung.green-gryphon.com>
X-Diagnostic: Unapproved submission to debian-ctte
Hi,
I would like to strike the following paragraphs from this
proposal:
----------------------------------------------------------------------
* Until a the a list of the differences between FSSTND and FHS, with
a decision whether to change and if applicable a transition plan for
each, has been prepared, Debian should continue to use the FHS.
----------------------------------------------------------------------
This had been discussed in the policy group for a while, and
people on either side of the heated discussions are not arguing the
desirability of the switch. For the most part, the move is
incremental, and mostly transparent, and far more packages have moved
towards the FHS than those whose docs have appeared in
/usr/share/doc/ with no fuss.
----------------------------------------------------------------------
* The policy manual should immediately be amended accordingly
immediately, to change the reference to the FHS back to the FSSTND,
and to add a comment saying that /usr/share/doc, /var/state and
/var/mail are not yet to be used or referred to.
----------------------------------------------------------------------
The former is overkill, the latter [apart from the /usr/doc/]
already is in the policy document (perhaps one should read the latest
policy document?) I think we should clarify the policy document about
the exceptions, addin /usr/doc to it, rather than rolling back the
parts of the move that have been accomplished succesfully.
======================================================================
The location of all installed files and directories must comply (with
some exceptions [1] ) with the Linux File system Hierarchy Standard
(FHS). The latest version of this document can be found alongside this
manual or on tsx-11.mit.edu in
/pub/linux/docs/linux-standards/fsstnd/. Specific questions about
following the standard may be asked on `debian-devel', or referred to
Daniel Quinlan, the FHS coordinator, at <quinlan@pathname.com>.
[1] In an as yet unreleased version of the standard, the location of
the mail spool and state information directories has changed; and
we propose to follow the latter, since that would mean that we do
not have to move things around again when the new version of the
FHS comes around). The changes are, amongst others,
s%/var/mail%/var/spool/mail% and s%/var/state%/var/lib%
======================================================================
----------------------------------------------------------------------
* Discuss and agree policy on other aspects of FHS transition, or
agree to refer this matter back to the debian-policy group, possibly
with some specific advice.
----------------------------------------------------------------------
What is the rationale for this item? Hasve we been asked to
adjudicate any other aspect of the FHS transition? Are there known
problems that can not be dealt with by the policy group? If this ctte
is a resource of the last resort, should we not have reasonable
grounds for expanding our efforts?
manoj
--
Life is to you a dashing and bold adventure.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
======================================================================
Since I've elected to call this vote without approving any of
the relevant discussion for debian-ctte [sorry -- time constraints],
please be aware that klee has made his personal debian-ctte folder
available for study on master.debian.org (~klee/debian-ctte.mbox.gz).
Finally, be aware that if anyone has any important issues to raise, we
can continue to discuss the matter during the voting process (or, at
least, until we have four votes). If you think we're missing something
important, please do let us know.
--
Raul
Reply to: