re: finishing up the /usr/share/doc transition

2001-01-09 Thread Steve S
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 somebody wants to (a) give me a
fairly explicit set of instructions and (b) assign me
some packages to work on, so I'm hopefully not
duplicating other work.  

Any interest?

cc: me on replies as I am not a subscriber.

Thanks,
Steve Stancliff

>send patch, wait some period of time (maybe a week?)
then warn of NMU, then NMU.


__
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/




Re: finishing up the /usr/share/doc transition

2001-01-07 Thread Adrian Bunk
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 transition is complete.
>...

I thought a maintainer is responsible for keeping his packages up to date?
Policy version 3.0.0 is out since 1,5 years now and if we decide to send
RC bugs on all packages with a lower Standards-Version and wait 2 months
that's a good chance to find packages whose maintainer is AWOL - all other
packages should have been updated until then.

cu,
Adrian

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi




Re: finishing up the /usr/share/doc transition

2001-01-02 Thread Adrian Bridgett
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 /usr/doc and
>/usr/share/doc, merge them. (And probably whine about it, since
>that's a bug.)
> 3. Move any remaining directories and symlinks that are in /usr/doc to
>/usr/share/doc
> 4. Move any files in /usr/doc to /usr/share/doc (shouldn't be necessary,
>but just in case). 
> 5. Remove /usr/doc
> 6. Link /usr/doc to /usr/share/doc

1,3,5,6 need doing (for instance dh_installdocs will install symlinks in
/usr/doc if  /usr/doc exists if /usr/doc/ doesn't exist).  However do
we really need the rest?  It'd be nice I guess, but why not just fix the
packages? 

Adrian

Email: [EMAIL PROTECTED]
Windows NT - Unix in beta-testing. GPG/PGP keys available on public key servers
Debian GNU/Linux  -*-  By professionals for professionals  -*-  www.debian.org




Re: finishing up the /usr/share/doc transition

2001-01-02 Thread Ingo Saitz
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 documentation are examples,
they go to /usr/lib//examples, as suggested by policy.

Ingo
-- 
"Disclosed Source" programs mean software for which the source code is
available without confidential or trade secret restrictions and for which 
the source code and object code are available for distribution without
license charges.




Re: finishing up the /usr/share/doc transition

2001-01-02 Thread Hamish Moffatt
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 was.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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 symlinks right now would completly
ignore the entire point of the technical committee's decision. You would
have some documentation only in /usr/doc and some only in
/usr/share/doc. I'm sorry, but that is unacceptable.

> what do they think about this single-script idea which
> is clearly against what the T.C. decided? (I guess they are on vacation).

Since the situation has changed since their decision, a new method
which takes advantage of the change in the situation should be ok, I
think.

> I do not follow your argument, anyway: If 6 people fix one package a
> day until woody is frozen, everything will be (physically) in
> /usr/share/doc at release time.

Indeed yes. Are you volenteering to be one of the six? I didn't get any
volenteers last time.

> You can be done today if you want (just use your script in *your*
> system, at your *own* risk), but this does not necessarily mean we
> have to risk hundreds of thousand of systems out there which do not have
> a real need to be converted in a single step.

I'd like to see your source of numbers that hundreds of thousands of
people track unstable.

I don't understand why you are assuming that any bugs that turn up in
the script won't be fixable anyway. It's not as if a temporary problem
with /usr/doc is going to cripple a debian system.

-- 
see shy jo




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Santiago Vila
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 almost finished and we want an empty /usr/doc
> > we have just to *stop* requiring symlinks in maintainer scripts (which
> > is something that we would do sooner or later). Once we stop making
> > symlinks in /usr/doc, this directory will be emptied by itself,
> > cleanly, and without risking the integrity of the system by complex
> > scripts.
>
> 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 transition is complete.

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, what do they think about this single-script idea which
is clearly against what the T.C. decided? (I guess they are on vacation).

I do not follow your argument, anyway: If 6 people fix one package a
day until woody is frozen, everything will be (physically) in
/usr/share/doc at release time. In such case it should be extremely
easy to remove /usr/doc by hand *if one wants to*. Why do you need a
complex script then? I think it is much better to leave this to the user's
discretion.

> On the other hand, if we use a script now, we can be done tomorrow.

You can be done today if you want (just use your script in *your*
system, at your *own* risk), but this does not necessarily mean we
have to risk hundreds of thousand of systems out there which do not have
a real need to be converted in a single step.

> As for risking the integrity of the system with complex scripts, take a
> look at the tremendous number of ways that people have managed to screw
> this up doing it one package at a time (I just discovered a package that
> puts files in /usr/doc/foo with a symlink /usr/share/doc/foo to it;
> completly backwards from what policy requires.).

Yes, I *always* thought these symlinks were a really bad idea, but
the solution is to stop requiring them, not writing yet another script.

> Perhaps a single script is actually likely to be better?

Perhaps no script at all and stop requiring symlinks is even better
than a complex script.




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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 (broken) dir merging code in the stanza just above should
deal with recovering from this case if the script is run again after a
larger partition becomes available.

I guess what you're doing is ok though. Although it may use 2x as much
space temporarily..

-- 
see shy jo




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Ben Collins
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 in $NEWDOC too; should never happen" >&2
>   exit 1
>   fi
>   mv -f $OLDDOC/$item $NEWDOC
> done
> 

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.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Ben Collins
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

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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 big enough to contain all of
   /usr/doc. One of the mv or cp's will fail, and the script will die.
   Is this sufficient?
2. If /usr/doc/foo is a link to ../share/doc/bar, and /usr/share/doc/foo
   does not exist, it ends up with /usr/share/doc/foo being a link to
   ../share/doc/bar, which will not work. I could add some complex code
   to deal with this, but it seems unlikely and a bug in any package
   that did that anyway.
3. Relative links from /usr/doc/foo/bar to elsewhere will break. I just
   thought of this one, and it probably needs to be fixed.

-- 
see shy jo
NEWDOC=/usr/share/doc
OLDDOC=/usr/doc

set -e

# Remove all symlinks in OLDDOC that correspond to
# symlinks or directories with the same names in NEWDOC
for link in `find $OLDDOC -maxdepth 1 -type l -printf '%P\n'`; do
if [ "$link" -a -e "$NEWDOC/$link" ]; then
rm -f "$OLDDOC/$link"
fi
done

# Remove all symlinks in NEWDOC that correspond to directories with the
# same name in OLDDOC. No, this should not happen. Yes, it does. Sigh.
for link in `find $NEWDOC -maxdepth 1 -type l -printf '%P\n'`; do
if [ "$link" -a -e "$OLDDOC/$link" ]; then
rm -f "$NEWDOC/$link"
fi
done

# If there are any directories with the same names in OLDDOC and  
# NEWDOC, merge them. (And whine about it, since that's a bug.)
for dir in `find $OLDDOC -maxdepth 1 -type d -printf '%P\n'`; do
if [ "$dir" -a -d "$NEWDOC/$dir" ]; then
echo "Both /usr/doc/$dir and /usr/share/doc/$dir exist; 
merging." >&2
cp -a $OLDDOC/$dir $NEWDOC/$dir
rm -rf $OLDDOC/$dir
fi
done

# 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 in $NEWDOC too; should never happen" >&2
exit 1
fi
mv -f $OLDDOC/$item $NEWDOC
done

# If there are any files left in OLDDOC, move those too if we can.
# This will probably only happen if the admin (or something broken)
# put them there.
for file in `find $OLDDOC -maxdepth 1 -type f -printf '%P\n'`; do
if [ -e "$NEWDOC/$file" ]; then
# TODO: deal with this somehow instead of bailing?
# It is a fairly unlikely edge case though.
echo "$item exists in $NEWDOC too. Please delete one of them." 
>&2
exit 1
fi
mv -f $OLDDOC/$file $NEWDOC
done

# Try to delete OLDDOC now; it should be empty.
rmdir $OLDDOC || ( echo "rmdir $OLDDOC failed" >&2 && exit 1)

# Now make the symlink. 
ln -sf share/doc $OLDDOC


Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Goswin Brederlow
> " " == 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
 > /usr/share/doc.

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?

/debian/dists/woody% zgrep "usr/doc" Contents-i386.gz \
  | while read FILE PACKAGE; do echo $PACKAGE; done | sort -u | wc
748 748   12849

Seems to be a lot of packages still using /usr/doc.

>> 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 bring it up on the policy list and ask for a location to
 > put it.

I don't have any and I don't think anyone can make a good point for
any. What reason could there be that I can't read some i386 specific
dokumentation on an alpha and use that e.g. in plex or bochs?
Only exception would be documentation in an executable form, which is
a) evil and b) should be in /usr/bin.

MfG
Goswin




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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
 `/usr/lib//examples', and files in
 `/usr/share/doc//examples' symlink to files in it.  Or the
 latter directory may be a symlink to the former.

And I suppose if there is actually some arch-specific non-example file, by
analogy it can be put in /usr/lib too with a similar symlink.

-- 
see shy jo




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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 /usr/doc
> we have just to *stop* requiring symlinks in maintainer scripts (which
> is something that we would do sooner or later). Once we stop making
> symlinks in /usr/doc, this directory will be emptied by itself,
> cleanly, and without risking the integrity of the system by complex
> scripts.

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 transition is complete.

On the other hand, if we use a script now, we can be done tomorrow.

As for risking the integrity of the system with complex scripts, take a
look at the tremendous number of ways that people have managed to screw
this up doing it one package at a time (I just discovered a package that
puts files in /usr/doc/foo with a symlink /usr/share/doc/foo to it;
completly backwards from what policy requires.). Perhaps a single script is
actually likely to be better?

-- 
see shy jo




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Ben Collins
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 bring it up on the 
> policy list and ask for a location to put it.
> 

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.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Santiago Vila
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 transition on a per package basis. If we
consider the transition almost finished and we want an empty /usr/doc
we have just to *stop* requiring symlinks in maintainer scripts (which
is something that we would do sooner or later). Once we stop making
symlinks in /usr/doc, this directory will be emptied by itself,
cleanly, and without risking the integrity of the system by complex
scripts.




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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 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 bring it up on the 
policy list and ask for a location to put it.

-- 
see shy jo




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Goswin Brederlow
> " " == 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 /usr/share/doc, merge them. (And probably whine about it,
 >since that's a bug.)
 > 3. Move any remaining directories and symlinks that are in
 >/usr/doc to /usr/share/doc
 > 4. Move any files in /usr/doc to /usr/share/doc (shouldn't be
 >necessary, but just in case).
 > 5. Remove /usr/doc
 > 6. Link /usr/doc to /usr/share/doc

What is the reason for linking /usr/doc to /usr/hare/doc (or
share/doc)?

Maybe I have architecure dependent documentation that should not be in
share.

This got probably answered a thousand times, but please, just once
more for me.

MfG
Goswin

PS: and don't say so that users looking in /usr/doc find the docs in
/usr/share/doc, users should adapt. :)




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Ben Collins
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, merge them. (And probably whine about it, since
>that's a bug.)
> 3. Move any remaining directories and symlinks that are in /usr/doc to
>/usr/share/doc
> 4. Move any files in /usr/doc to /usr/share/doc (shouldn't be necessary,
>but just in case). 
> 5. Remove /usr/doc
> 6. Link /usr/doc to /usr/share/doc
> 

Exactly, except '6' should be "Link /usr/doc to share/doc", so chrooted
systems can be more easily maintained.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'




Re: finishing up the /usr/share/doc transition

2001-01-01 Thread Joey Hess
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 dpkg would have caused doc
> files to go missing if /usr/doc was a symlink to share/doc, once a package
> was upgraded from the latter to the former (docs in /usr/share/doc).
> 
> That is no longer the case, so I would hope that our efforts would be
> better spent writing a transition script to handle the move (moving things
> from /usr/doc to /usr/share/doc, if needed, and removing symlinks).

Well I guess that would be ok; it would certianly be easier.

> We just need a script/program that sanely does this transition, then
> creates the /usr/doc -> share/doc symlink.

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, merge them. (And probably whine about it, since
   that's a bug.)
3. Move any remaining directories and symlinks that are in /usr/doc to
   /usr/share/doc
4. Move any files in /usr/doc to /usr/share/doc (shouldn't be necessary,
   but just in case). 
5. Remove /usr/doc
6. Link /usr/doc to /usr/share/doc

-- 
see shy jo




Re: finishing up the /usr/share/doc transition

2000-12-23 Thread Andreas Fuchs
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!




Re: finishing up the /usr/share/doc transition

2000-12-23 Thread Joseph Carter
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 and ALSA at the moment..  When I
track it down I'll fix this too.


> libs/libmikmod1

This should be removed from the archive as no longer used.  I believe the
bug is already filed.


> graphics/qiv

I'm willing to NMU this if necessary.  I think the package has likely been
abandoned upstream but am not sure.  I don't want to take the package for
that reason (I think eog could become a better replacement for it in time.)

-- 
Joseph Carter <[EMAIL PROTECTED]>   GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/)   44F9 8FF7 D7A3 DCF9 DAB3

 I still think you guys are nuts merging Q and QW. :P
 Of course we're nuts.  Even John said so.  =>
 Zoid: we're nuts, but we're productive nuts:)




Re: finishing up the /usr/share/doc transition

2000-12-22 Thread Roland Bauerschmidt
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]>




Re: finishing up the /usr/share/doc transition

2000-12-22 Thread Sean 'Shaleh' Perry
> 
> 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.




Re: finishing up the /usr/share/doc transition

2000-12-22 Thread Ben Collins
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 (woody) ships with a full /usr/share/doc, and a
> /usr/doc full of symlinks." and went on to detail how woody+1 (sarge?)
> will begin to phase out the symlinks and how woody+2 will finally be
> free of this mess. 
> 
> 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.
> 
> 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, it
> seems acheivable, especially if we file bugs now on the undone packages,
> which would probably wake a fair number of maintainers up..
> 
> What do you think?

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 dpkg would have caused doc
files to go missing if /usr/doc was a symlink to share/doc, once a package
was upgraded from the latter to the former (docs in /usr/share/doc).

That is no longer the case, so I would hope that our efforts would be
better spent writing a transition script to handle the move (moving things
from /usr/doc to /usr/share/doc, if needed, and removing symlinks). Note
that I have a /usr/doc -> share/doc symlink on all my systems right now
(note, auric is also setup this way, running potato, without any errors or
missing files).

Can we do this and avoid further hacking around with this? Moving to
/usr/share/doc in woody is possible. The tools handle it, packages
that support the symlink in postinst/prerm already magically work (IOW,
any policy abiding app supports it), packages that use the old /usr/doc
work with it, and new packages that only use /usr/share/doc will work with
it.

We just need a script/program that sanely does this transition, then
creates the /usr/doc -> share/doc symlink.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'




Re: finishing up the /usr/share/doc transition

2000-12-22 Thread Roland Bauerschmidt
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 other words, it
> seems acheivable, especially if we file bugs now on the undone packages,
> which would probably wake a fair number of maintainers up..

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.

Roland

-- 
Roland Bauerschmidt <[EMAIL PROTECTED]>




RE: finishing up the /usr/share/doc transition

2000-12-22 Thread Sean 'Shaleh' Perry
> 
> 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, it
> seems acheivable, especially if we file bugs now on the undone packages,
> which would probably wake a fair number of maintainers up..
> 
> What do you think?
> 

other than perl packages and debconf packages, lintian tests are getting quite
close to showing policy complience.  Perhaps we should start pinging people
whose packages fail in lintian.

Either way, yes, it would be nice to kill many many postinsts.