Plan for tomorrows (20080522) FESCO meeting

[Josh Boyer]

On Wed, 21 May 2008 21:35:09 -0300
Alexandre Oliva <aoliva at redhat.com> wrote:

> On May 21, 2008, Josh Boyer <jwboyer at gmail.com> wrote:
> 
> > So work with upstream to get them removed or pushed to separate
> > firmware packages.
> 
> It's been tried before.  I gather upstream is not interested in
> achieving a 100% Free Software kernel tarball.  It's in conflict with
> our stated mission.  Where do we go from that point, when upstream is
> not cooperative and there is a drop-in alternative.

Tough spot.  I don't have an answer for you.

> > Given your preference to not work in a manner which would be compatible
> > with Fedora Engineering practices,
> 
> This is a very unfair assumption.  I just have had access to facts
> that you apparently didn't.  Either that or you're being intentionally
> obnoxious in sending me down this wild goose chase.

I wouldn't send you on a goose chase.  Can you point me to where you've
approached the upstream kernel maintainers about this?

> > I'm not sure there is a way out.  However perhaps you can enlist
> > some help from someone that would be willing to do that.
> 
> Finding someone else to do it might enable more patches to be posted,
> but it wouldn't make it possible to achieve the goal.

Because?  If those patches get integrated, then wouldn't the parts you
find objectionable be gone?

> >> One of us is missing something.  How would a comps group prevent the
> >> accidental installation of say non-Free kernel or firmware packages
> >> brought in through unintended dependencies, for a user who wants to
> >> make sure no such software is installed, for example?
> 
> > Fine, a fair point.  Create a Free spin via a kickstart file.
> 
> Still no use, unless the spin comes with its own separate repository,
> never contaminated by non-Free Software.  At which point users might
> as well switch to BLAG.

I don't understand that at all.  You're suggesting that Fedora would
have to split up the actual repositories in order to accomplish your
goal?

> > Having that virtual package is more pain to maintain than a ks file
> 
> Err...  The only person I know who has volunteered to maintain this
> package disagrees with this assessment, especially because the ks file
> does not even begin to address the longer-term goal of enabling a user
> to avoid the installation of non-Free Software on his system (install
> time and updates over time), rather than a short-term goal of avoiding
> the inclusion of non-Free Software in one particular spin.

So you propose to have this virtual package updated constantly to
account for new dependencies on what _should_ be mostly firmware
packages as they show up?  That seems tedious and error prone, but if
that's what you want you can certainly attempt it.

> >> And largely misunderstood while at that.  Not by everyone who objected
> >> to it, for sure.
> 
> > I don't think there's been a large misunderstanding.  Simply two
> > differing opinions on the matter.
> 
> Like, a number of people vehemently objected to the idea of replacing
> the current kernel with linux-libre.  I hadn't proposed anything even
> close to it.  That's a large misunderstanding to me.

I certainly didn't think you intended to _replace_ the main kernel
package.  But I don't agree with even providing a completely different
alternative "kernel-libre" package.  If it can't be built as a flavor
of the existing kernel package, then I don't see it being approved for
inclusion.

josh