re: finishing up the /usr/share/doc transition
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
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
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
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
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
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
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
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
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
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
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
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
> " " == 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
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
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
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
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
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
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
> " " == 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
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
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
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
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
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
> > 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
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
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
> > 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.