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 ?
Pkg-lustre-maintainers mailing list