Karl Goetz wrote: > > Another tangential point: Debian does not support source uploads, > > Pardon? Debian does support source uploads, but also allows binary only > uploads.
You are wrong here. Dak will reject any upload if it has no .debs. This means that an Arch:all package you upload is what will go in the archive, the mirrors, and all people's machines, and the same holds for an Arch:any package for the architecture where you built it. Anything else gets auto-built on the buildds with dpkg-buildpackage -B. > Packages should always be tested before upload, wether they be > binary or source only. Right, but because the Ubuntu build framework does not enforce this, people often make a change to the source, run dpkg-buildpackage -S and upload. Sometimes (seldom) this leads to a FTBFS, sometimes to a binary package that is not entirely functional. The point was that this stuff is in many cases untested by the person who does the upload. > > Not sure what you mean by "site specific"? > > By site specific I meant "Have these been customised to the way > me/a friend/the boss does their work". Not as far as I'm aware of. Everyone can check the patches and all modifications. Personally, I would never upload something with such bizarre changes. > Then again, I'm not entirely sure what your 'not something > unmanageable, especially nowadays.' refers to exactly. Having every package produce a -dbg companion with detached debugging symbols comes with certain costs, e.g. far more CPU cycles for britney (the testing migration script in Debian) and more space/load in the archive and the mirror framework. I said that nowadays this should not be a big concern. Of course, it is for users (including me on some ancient hosts), so the user must have the option not to install such packages, if he wishes so for whatever reason. But by default, they should be there, just like they are for things I build manually (unless I explicitly say I do not want them). > I dislike needing to read a manual on how to read help. You only have to do it once. What I like about Info is that a manual is usable as a whole -- when you learn a program you can read it cover to cover and this is great. It is structured well usually, which makes navigation easy. Later you can use it as reference quickly and efficiently, if the author of the document cared to add the appropriate indexing commands. And I can print it easily and explore romantic m4 macros while working in my grapes yard (I actually do this). Try to format the autoconf manual or even the far smaller m4 manual in a man page to see what I mean. It will become uncomprehensible, unreadable and unusable mess. The existing m4 and autoconf manpages are not a replacement for the excellent documentation these packages have. _______________________________________________ gnu-linux-libre mailing list gnu-linux-libre@nongnu.org http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre