Hi all,
I just read the thread on finishing the move to
/usr/share/doc. I've been a Debian user for a couple
of years now and would like to find small ways to
help... This sounds like something I can do in my
spare time.
I'd be interested in performing the necessary work on
some packages if
On Mon, 1 Jan 2001, Joey Hess wrote:
...
Take another look at where we are now. If 6 people fix one package a
day until woody is frozen, we might just manage to convert all packages
that do not yet use /usr/share/doc. If that is done, we only have to wait 2
more releases of debian until the
On Mon, Jan 01, 2001 at 02:32:18PM -0800, Joey Hess wrote:
On the other hand, if we use a script now, we can be done tomorrow.
When will the script be run, and which package will it belong to?
Obviously it cannot be something which must be run manually,
as the update script for Debian 1.3 to 2.0
MoiN
On Mon, Jan 01, 2001 at 11:21:42PM +0100, Goswin Brederlow wrote:
Maybe I have architecure dependent documentation that should not be in
share.
Architecture dependent files go to /usr/lib, so I'd put them into
/usr/lib/package/doc. You can symlink them from
/usr/share/doc/package, too. If
On Mon, Jan 1, 2001 at 12:20:32 -0800 (+), Joey Hess wrote:
Ben Collins wrote:
[snip]
So it will need to:
1. Remove all symlinks in /usr/doc that correspond to
symlinks or directories with the same names in /usr/share/doc
2. If there are any directories with the same names in
Ben Collins wrote:
I think we need to reevaluate this decision based on the fact that the bug
in dpkg that forced this implementation (as opposed to a clean /usr/doc
symlink to share/doc) has been gone for awhile now (the potato dpkg is
fixed).
For those that do not remember, the bug in
On Mon, Jan 01, 2001 at 12:20:32PM -0800, Joey Hess wrote:
So it will need to:
1. Remove all symlinks in /usr/doc that correspond to
symlinks or directories with the same names in /usr/share/doc
2. If there are any directories with the same names in /usr/doc and
/usr/share/doc,
== Joey Hess [EMAIL PROTECTED] writes:
So it will need to:
1. Remove all symlinks in /usr/doc that correspond to symlinks
or directories with the same names in /usr/share/doc
2. If there are any directories with the same names in /usr/doc
and
Ben Collins wrote:
Exactly, except '6' should be Link /usr/doc to share/doc, so chrooted
systems can be more easily maintained.
Yes of course.
I should have a fairly robust script in anouther half hour or so.
--
see shy jo
Goswin Brederlow wrote:
What is the reason for linking /usr/doc to /usr/hare/doc (or
share/doc)?
So that packages that are not policy complient and contain files only in
/usr/doc still end up installing them in /usr/share/doc.
Maybe I have architecure dependent documentation that should not
Ben Collins wrote:
We just need a script/program that sanely does this transition, then
creates the /usr/doc - share/doc symlink.
No, we don't *need* any script to do this. One thing is that dpkg
allows this to be done and another different one is that we *have* to
do it. We agreed to make the
On Mon, Jan 01, 2001 at 02:25:24PM -0800, Joey Hess wrote:
Goswin Brederlow wrote:
Maybe I have architecure dependent documentation that should not be in
share.
Er. Well policy does not allow for this at all. If you do actually have
such a thing (it seems unlikely), perhaps you should
Santiago Vila wrote:
No, we don't *need* any script to do this. One thing is that dpkg
allows this to be done and another different one is that we *have* to
do it. We agreed to make the transition on a per package basis. If we
consider the transition almost finished and we want an empty
Ben Collins wrote:
How can anything that's a document only work on a particular arch? If
you are talking about pre-compiled examples, well uh, don't precompile
them.
Actually, policy does allow for that:
Architecture-specific example files should be installed in a directory
== Joey Hess [EMAIL PROTECTED] writes:
Goswin Brederlow wrote:
What is the reason for linking /usr/doc to /usr/hare/doc (or
share/doc)?
So that packages that are not policy complient and contain
files only in /usr/doc still end up installing them in
Attached is my conversion script. It's parameterized at the top, so you
can make copies of /usr/doc and /usr/share doc and point it at them
instead. I have done that in my testing and it seems to work perfectly.
It should handle all the edge cases except:
1. /usr/share mounted elsewhere and not
On Mon, Jan 01, 2001 at 11:58:07PM +0100, Goswin Brederlow wrote:
So bugs won't be noticed. Maybe a simple grep in the Contents files
would be enough to find all such packages.
Does lintian check for /usr/[share/]doc?
Yes, lintian does complain about /usr/doc and /usr/man
--
On Mon, Jan 01, 2001 at 03:05:14PM -0800, Joey Hess wrote:
# Move any remaining directories and symlinks from OLDDOC to NEWDOC.
for item in `find $OLDDOC -maxdepth 1 \( -type d -or -type l \) -printf
'%P\n'`; do
if [ $item -a -e $NEWDOC/$item ]; then
echo $item exists
Joey Hess wrote:
It should handle all the edge cases except:
Well it also has a bug in the subdirectory merging code. Merging
/usr/doc/HOWTO and /usr/share/doc/HOWTO is difficult. cp alone doesn't
cut it.
--
see shy jo
Ben Collins wrote:
Maybe this should be something like:
if cp -a $OLDDOC/$item $NEWDOC; then
rm -rf $OLDDOC/$item
else
rm -rf $NEWDOC/$item
exit 1
fi
That should handle filesystem full errors a bit better.
Of course the
On Mon, 1 Jan 2001, Joey Hess wrote:
Santiago Vila wrote:
No, we don't *need* any script to do this. One thing is that dpkg
allows this to be done and another different one is that we *have* to
do it. We agreed to make the transition on a per package basis. If we
consider the transition
Santiago Vila wrote:
First, there is no hurry for this. Second, it would probably take only
one more release if we stop using symlinks right now. I already made a
policy proposal to stop using symlinks, but there were objections from
Manoj and Raul
I'm sure they objected since dropping
On Fri, Dec 22, 2000 at 01:04:26PM -0800, Joey Hess wrote:
I'm looking forward to a day with a lot less postinst and postrm scripts
myself, so I want to make sure we don't miss the traget of full
conversion by woody's release.
Hear hear.
sound/mikmod
There appears to be a bug with libmikmod
On 2000-12-22, Joey Hess [EMAIL PROTECTED] wrote:
web/weblint
net/zenirc
Fixes for these two are in the BTS, in bug numbers #79747 and #79750,
respectively.
HTH,
--
Andreas Fuchs, [EMAIL PROTECTED], [EMAIL PROTECTED], antifuchs
Hail RMS! Hail Cthulhu! Hail Eris! All hail Discordia!
It has been more than 1 year since the technical committee decided how
the /usr/share/doc transition would be accomplished[1], and in that time
most packages have implementede the transition. The decision stated that
Thus, potato+1 (woody) ships with a full /usr/share/doc, and a
/usr/doc full of
There are a total of 645 packages that have not been converted[2]. There
are 16 weeks between December 31st and Aj's projected freeze date for woody.
If 40 people could do one package a week, we would be done. Or 20 people
doing two a week, or just 6 people doing one a day. In other words,
Joey Hess wrote:
There are a total of 645 packages that have not been converted[2]. There
are 16 weeks between December 31st and Aj's projected freeze date for woody.
If 40 people could do one package a week, we would be done. Or 20 people
doing two a week, or just 6 people doing one a day. In
On Fri, Dec 22, 2000 at 01:04:26PM -0800, Joey Hess wrote:
It has been more than 1 year since the technical committee decided how
the /usr/share/doc transition would be accomplished[1], and in that time
most packages have implementede the transition. The decision stated that
Thus, potato+1
I'd be glad to help. How should we proceed? Should we send patches to
the appropiate maintainers or directly upload the NMUs? Honestly, they
had enough time to tranist to /usr/share/doc.
send patch, wait some period of time (maybe a week?) then warn of NMU, then NMU.
On Fri, Dec 22, 2000 at 01:04:26PM -0800, Joey Hess wrote:
base/update
I uploaded a NMU for this already.
Roland
--
Roland Bauerschmidt [EMAIL PROTECTED]
30 matches
Mail list logo
