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 som
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 t
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 /
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//doc. You can symlink them from
/usr/share/doc/package, too. If your
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
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 sym
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 tra
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
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
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 "$ite
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
--
---
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 b
> " " == 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
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
`/us
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 /us
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
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 th
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:
> 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
> " " == 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 /
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
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 i
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!
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 libmik
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]>
>
> 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:
> 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
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.
>
> 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 word
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 s
30 matches
Mail list logo
