On Sun, Mar 21, 2010 at 11:57:01AM +0100, Yann Dirson wrote: > On Sat, Mar 20, 2010 at 05:39:00PM +0100, Jonas Smedegaard wrote: > > On Sat, Mar 20, 2010 at 05:28:33PM +0100, Yann Dirson wrote: > > >On Sun, Mar 21, 2010 at 12:17:22AM +0900, Hideki Yamane wrote: > > >>On Sat, 20 Mar 2010 15:14:59 +0100 > > >>Yann Dirson <ydir...@free.fr> wrote: > > >>> So the question is, is it time to request removal of those > > > >>packages, or is there any remaining reason not to do so that I > > > >>missed ? > > >> > > >> As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged > > >>with mainline, but it's not fully featured one yet. At least, I > > >>want to provide it with squeeze. > > >> > > >> and hope kernel-package would enable patch support again... ;) > > > > > >I won't speak for Manoj here, but I feel we should think about > > >other ways to provide those patches. > > > > > >One way could be simply to provide ensure those patches in some > > >git tree, that users can easily fetch and merge before running > > >make-kpkg. > > > > Lots of possibilities arise if we do not constrain ourselves to the > > Debian ideal of a fully self-contained distribution usable while > > offline. > > > > I happen to like that ideal, also for kernel patches. > > I don't think there is a contradiction - eg. it could make sense to > ship a kernel repository in a package, and similarly for kernel > patches referencing the former as a (local) remote.
Let's maybe stay focussed on the initial problem: we *had* a way to handle kernel patches as part of a self-contained distribution, but there is no support for this any more. Moreover that support we had was not 100% satisfactory (eg. bad handling of conflicting patches needing manual merge - although that was something I wanted to address in the never-finished dh-kpatches 0.100). My idea is to rethink the whole thing using today's tools - namely, git. Anyway, to get back to the initial problem of the current linux-patch packages, we currently still have patches in the distro, which were packaged for a mechanism that is not to be shipped in squeeze (and referencing that obsolete mechanism in their /usr/share/doc/), and this in itself is a problem of quality of the overal distro, right ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323223705.ga11...@nan92-1-81-57-214-146.fbx.proxad.net
