On Wed, 21 May 2008 21:35:09 -0300 Alexandre Oliva <aoliva@xxxxxxxxxx> wrote: > On May 21, 2008, Josh Boyer <jwboyer@xxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
