[GNU-linux-libre] Re: any Free BSD variant?

[Yavor Doganov]

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.