On Wed, 21 May 2008 21:35:09 -0300
Alexandre Oliva <aoliva(a)redhat.com> wrote:
On May 21, 2008, Josh Boyer <jwboyer(a)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