[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: custom vs. derivative (Re: packages.gz corrupt, missing packages and other issues)



Hi,

For those joining in on debian-edu@l.d.o, this thread started on 
debian-custom@l.d.o and I'm crossposting this now, as I think it's relevant 
for Debian Edu development.

Phillip and Luk, _you_ can skip the first quote+reply pair after this intro 
and just read the second :-) (There are three in total, the last is very 
short.) 

And as you all probably would have figured out yourself at some time, when I 
use "our" in the paragraphs below, I mean "Debian Edu" :-)

On Friday 04 April 2008 15:21, Otavio Salvador wrote:
> Holger Levsen <holger@layer-acht.org> writes:
> > To throw in another thought I had last night, after our discussion:
> > Debian Edu is not 99,867% Debian as I wrote yesterday, but 100%. It's an
> > official Debian subproject, so it is Debian. It only takes 99,867% from
> > stable and stable-updates, and the rest is from our archive, which is an
> > official archive of an official Debian subproject. There are other
> > official archives too: volatile comes to mind, and hopefully backports
> > will soon be official too.
> I'm sorry but Debian-Edu archive aren't part of Debian archive fully.

Please read again and imagine I had written "and the rest is from our archive, 
which is an archive of an official Debian subproject"... :)

Hmm, still, guess I can just claim Debian Edu is part of Debian. And unlike 
volatile and ftp.debian.org we dont differate between main, contrib and 
non-free, we only have a "local" section. 

In our http://wiki.debian.org/DebianEdu/ArchivePolicy we demand that uploaders 
have to comply to the DFSG, and usually we follow the Debian ftpmasters 
reject FAQ, but we might make exceptions. (See #1, #4 and #12 of the policy.)

Currently we only have packages in local which are fine for Debian main, but 
flashplugin-nonfree-extrasound is waiting in etch-test (our equivalent to 
stable-proposed-updates in Debian) to be moved to etch. ATM this is stalled 
on the question if we should accept a package which is waiting in Debians NEW 
queue since two months. In Debian it's clear the package will go to contrib 
(as it depends on flashplugin-nonfree), it's "only" stalled because of 
maintainance/packaging questions.

But for me a new question has popped up: do we want to "polute" Debian Edu 
etch with a contrib package? It's not installed by default, but still, it's 
ugly ;-) I guess we still want to do this, as our priorities are free 
software and our users :-) 

ftpmaster@skolelinux, how/when will we decide on the 
flashplugin-nonfree-extrasound package? Do we want it in etch, even though 
there might be no upgrade path? I now think so: either the upgrade path will 
be free flash or we will need to find a way to have a upgrade path to 
flashplugin-nonfree-extrasound or whatever the package name will be. 
Comments? (It has been tested and works, too tired to provide URLs for this.)

For Lenny I suggest to rename our "local" to "main" and to create contrib and 
non-free when we need them. (Rationale for the 2nd part: we are aiming for a 
free flash in Lenny, don't we? ;)

> > Also there is the issue that Debian Edu might release within Lenny, but
> > then produce independent pointreleases of it afterwards. (Then we will
> > again have less than 100% of our packages from main, security updatdes
> > and volatile.) And then we might also use packages during development,
> > which are not yet in Debian (cause they are stuck in NEW in Debian or
> > whatever.)
> The point releases might need to be coordinated with SRM team and get
> the changes on Debian and then build from it. That's the way I see it.

For etch we have done point releases indepentenly (and will continue to do 
so, "btw" we should talk about a etchandahalf based pointrelease and new 
installation medias..), and IMHO quite good. So technically we are captable 
of doing this.

Of course it would be great (as we would avoid duplication of work and thus 
could get more work done :) if we could get the changes we need into Debian 
pointreleases for Lenny, which are fixes for important or trivial bugs in the 
Debian Edu configuration mostly, plus usally some bugfixes for broken 
packages used on the desktop or in our services, which would also fit Debian 
pointreleases nicely, for examples see 
http://wiki.debian.org/DebianEdu/Status/Etch (*)

Though of course, for this to happen, we first need to manage to release 
Debian Edu Lenny with(in) Debian Lenny.(!) Currently 4 out of 9 packages in 
our "main labeled section" on 
http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org are not 
in Lenny with the version in unstable, which is (for all 9 packages there) 
irrelevant for the Debian Lenny release, but we can't release without those 9 
packages well in shape. So we will need to work on this :-)

That said, and if we manage to do this, what would the SRMs think about a 
laxer pointrelease policy for "Debian Edu packages as in the main section on 
our QA page"? We would like to be able to fix trivial, wishlist, minor and 
normal bugs too :-)

Of course, in the end this is true for any package. But I believe there are 
some packages for Debian in which (even small) bugfixes in pointreleases have 
a much higher impact on the user experience. To those I consider the Debian 
Edu group of packages, other CDD meta packages, documentation packages, fai 
(a non-interactive system to install a Debian infrastructures...). 

(*) I shall cleanup the known bugs section in the Edu etch status page 
tomorrow (or rather, mention when that part was last edited...) Everything 
above that section is up2date.

> > And there might be nonfree blends.
> Pure Non-Free Debian Blend looks... c r a z y ;-)

I dont think anybody suggest those / this category - certainly not me :-)


regards,
	Holger

Attachment: pgpYJLU1pgqzm.pgp
Description: PGP signature


Reply to: