Re: license requirements for a book to be in free section
On Tue, Jan 29, 2002 at 12:15:39PM -0600, Colin Watson wrote:
> On Tue, Jan 29, 2002 at 02:39:28PM +0100, Marcus Brinkmann wrote:
> > For example, we thought that some LDP documents are troublesome.
> > Incidentially, the licenses of all LDP documents have been sorted out
> > recently (Colin Watson was active at that), so this item seems to be
> > resolved.
> Not quite, following a discussion with the release manager - but it
> certainly will be in the green and promised land after woody.
Well, that counts fully in my book ;)
> > It turns out that building such a distribution is not easy. For example, I
> > had the idea of a repository in the FSF network which contains the
> > necessary changes to the Debian repository, and otherwise just references to
> > the Debian mirrors. But removing packages reliably seems to be impossible
> > this way. If somebody has ideas about this, let me know.
> I'd say that the FSF ought to be building its own Packages file, which
> shouldn't be *too* difficult, provided that some care is taken to avoid
> packages suddenly losing dependencies. Perhaps it might be worth talking
> to people like Progeny who have maintained slightly-forked versions of
> Debian in the past.
That was my very first idea. For the packages it would override,
it would create a Packages file. For the packages that are in Debian,
I don't see how you can make it work considering that filename entries
in the packaging file are relative to the packages file location.
So GNU would have to mirror the whole lot of Debian, which seems to be
overkill. Or am I overlooking something? Extending it to absolute urls
would probably work, but has the serious problem that you can only point to
one mirror, and not let the user choose, so I don't like that at all.
OTOH, having the exclusion list on the users system has also disadvantages,
having it on the GNU server should be preferred.
> It feels like most of the problems should be soluble using a Debian
> mirror with exclusions (could be implemented with reverse-depends logic
> from libapt-pkg feeding into the exclude list of a mirroring tool) plus
> an FSF autobuilder that helps to maintain the necessary forked versions.
> I confess that I've never personally done anything like this, though.
Well, yes. That is basically the worst case, but I hope for a solution with
less overhead. I am not worried about the autobuilding of a few overrides,
but mirroring the whole of Debian is expensive, and sounds a bit
like overkill just to exclude one or two packages out of thousands. It
might be the only way to do it properly, but I don't know if it is feasible
for the FSF resource wise.
I am still looking for a solution that has all the advantages of a seperate
mirror but not its disadvantages. I have no good suggestion to make how to
achieve this, though, at this stage.
`Rhubarb is no Egyptian god.' Debian http://www.debian.org firstname.lastname@example.org
Marcus Brinkmann GNU http://www.gnu.org email@example.com