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 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
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 your documentation are examples, they go to /usr/lib/package/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 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/pkg 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
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 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
== 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
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
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: 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
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
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
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/package/examples', and files in `/usr/share/doc/package/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
== 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
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
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
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
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
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
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
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 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 Zoid I still think you guys are nuts merging Q and QW. :P knghtbrd Of course we're nuts. Even John said so. = taniwha Zoid: we're nuts, but we're productive nuts:)
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!
finishing up the /usr/share/doc transition
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? -- see shy jo [1] http://lists.debian.org/debian-ctte-9908/msg00038.html [2] web/weblint mail/signify web/faqomatic doc/debian-guide x11/sfm oldlibs/libstdc++2.8 x11/libcqcam-dev x11/icewm-themes otherosfs/pilot-manager devel/lib-sax-java math/plotmtv net/asp devel/pydb base/libgdbmg1 non-free/x11/xtoolplaces devel/et non-free/news/trn devel/tk8.0-ja-dev text/ibrazilian text/ppd-gs utils/quickppp math/dome oldlibs/libg++27 non-free/sound/mp3asm devel/librx1g-dbg graphics/qvplay web/htget non-free/web/netscape-java-408 non-free/web/communicator-spellchk-408 sound/timidity-patches oldlibs/libc5-altdbg oldlibs/ncurses3.0 libs/libtime-modules-perl non-free/admin/idled oldlibs/ncurses3.4 non-free/graphics/xwpick libs/libggi-target-vcsa text/abc2ps utils/lsof-2.0.36 libs/libggi2 devel/libstringlist-dev interpreters/bwbasic devel/cflow x11/xpaste non-free/devel/scheme-to-c devel/curves net/lambdamoo-docs math/g2 non-free/web/chimera sound/awe-drv misc/dbf2mysql devel/libliteclue-dev net/rinetd non-free/web/netscape-dmotif-408 libs/aalib1-dev mail/xlbiff libs/umich-libldap math/tela math/dstool libs/libggi-target-aa games/g5 x11/xinput mail/splitdigest math/seesat5 editors/emacs20 editors/jed-sl-ja doc/tochnog-doc x11/xserver-ggi x11/iceconf libs/ftplib-dev games/netmaze non-free/misc/xacc-smotif interpreters/perl-debug libs/libawe0.4 text/wfrench devel/libgdbmg1-dev games/xvier misc/titrax net/sirc devel/rscheme-modules libs/libsrp-dev devel/librecode-dev libs/libliteclue oldlibs/librx1-altdev oldlibs/xaw95 graphics/cdlabelgen web/gtml utils/cracklib2 devel/sup base/update text/brazilian-conjugate libs/libggidemos interpreters/libfile-tail-perl doc/stl-manual x11/swisswatch utils/afbackup non-free/x11/xarchie x11/xfntmizi-ko devel/librx1g-dev editors/gnuserv interpreters/perl-suid admin/dialdcost oldlibs/libc5-altdev x11/fvwmconf non-free/web/communicator-dmotif-408 utils/libxdelta2 contrib/devel/cup editors/xcoral net/tinyirc graphics/vstream utils/cpbk otherosfs/hfsutils games/crossfire-client-gtk interpreters/bigloo non-free/graphics/picon-domains web/swish-e doc/installmanual-de devel/perl-byacc net/ftp-upload admin/lexmark7000linux non-free/net/archie x11/xmanpages-ja base/dpkg-multicd comm/seyon non-free/x11/xsnow devel/sml-nj contrib/x11/metro-motif-man otherosfs/pilot-template libs/libggi-target-svgalib non-free/x11/x3270 devel/libcdaudio0-dev misc/dtaus oldlibs/libgdbm1 oldlibs/libc5 games/mgt non-free/devel/gbdk-dev non-free/graphics/picon-news web/python-bobopos devel/libdnd1-dev net/sendfile libs/libggi-target-fbdev utils/authbind devel/fhist admin/mingetty text/sgml-base devel/kernel-patch-2.0.37-raid devel/kernel-source-2.0.36 games/xchain sound/mikmod libs/libgii0 non-free/web/navigator-dmotif-408 net/dhcp-dns devel/stalin net/rlinetd devel/binutils-m68k-linux net/zone-file-check doc/libgtk-doc sound/xmp non-free/games/ines comm/minicom devel/libawe0.4-dev utils/kbackup non-free/graphics/picon-misc games/empire-hub non-free/graphics/giflib3g-dev mail/bulkmail net/omirr non-free/math/gap4-tdat utils/kbackup-doc utils/tleds libs/libggi-samples interpreters/libtime-period-perl x11/logout-button doc/tkinfo x11/fsviewer utils/konfont text/psutils utils/lzop admin/timeoutd admin/printop devel/xxgdb misc/puzzle mail/tkmail non-free/misc/phylip utils/sformat non-free/x11/freefont devel/m2c graphics/libjpeg-progs non-free/web/netscape-smotif-408 non-free/graphics/picon-usenix contrib/web/netscape3 contrib/web/netscape4 text/par admin/bpowerd games/xbat sound/cdcd net/jail misc/readseq x11/rt doc/manpages-de-dev utils/synaptics devel/bock hamradio/ax25-tools devel/kernel-patch-2.2.10-netwinder non-free/utils/glimpse games/spider tex/bibview non-free/games/gsn-curses doc/ldp-ligs non-free/mail/rblsmtpd-src interpreters/gcl doc/r5rs-doc text/gsfonts math/meschach doc/guile1.3-doc interpreters/libprpc-perl graphics/phototk non-free/devel/ocamltk oldlibs/ncurses3.0-altdev
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.
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
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
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: base/update I uploaded a NMU for this already. Roland -- Roland Bauerschmidt [EMAIL PROTECTED]
