Re: Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
On Tue, 8 Nov 2005 16:19:40 +0100, Sven Luther <sven.luther@wanadoo.fr> said:
> On Tue, Nov 08, 2005 at 09:01:24AM -0600, Manoj Srivastava wrote:
>> On Tue, 8 Nov 2005 14:26:17 +0100, Sven Luther
>> <sven.luther@wanadoo.fr> said:
>>
>> > On Tue, Nov 08, 2005 at 08:30:53PM +0900, Horms wrote:
>> >> On Tue, Nov 08, 2005 at 11:36:13AM +0100, Sven Luther wrote:
>> >> > On Tue, Nov 08, 2005 at 11:19:36AM +0100, Jonas Smedegaard wrote:
>> >> > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> >> > >
>> >> > > On Tue, 8 Nov 2005 11:31:10 +0900
>> >> > > Horms <horms@debian.org> wrote:
>> >> > >
>> >> > > > Waldi, can you coment on how to add a recommends to images
>> >> > > > on a per-flavour basis?
>> >> > >
>> >> > > Isn't per-flavour control hints one of the new features of
>> >> > > the soon-to-be-in-sid kernel-package?
>> >> > >
>> >> > > If so, I suggest using that instead of bloating linux-2.6
>> >> > > packaging unnecessarily.
>> >> >
>> >> > linux-2.6 packaging already has quite nice per-flavour
>> >> > dependency handling, thank you.
>>
>> Would it not be nice to push it down into the underlying tool, so
>> that even endusers get a nicely hinted per flavour images, as
>> appropriate? I mean, we cater to all users, not just those that use
>> official Debian kernels.
> Well, maybe, but we first need to see what happens with the
> intensive k-p changes you want, and i wasunder the impression that
> Horms wanted to use the feature ASAP. Anyway, it is implemented now,
> was a 5 line trivial change in gencontrol.py. Maybe you want to look
> at it and see if you can reuse some ?
>> Additionally, I would have thought that pushing code down to
>> underlying tools and reducing the maintenance burden would be a
>> good thing.
> Pushing things into k-p reduces the maintenance burden only for you,
> but worsen it for the rest of us :).
Well, no, since I don't really care about how my users use my
package -- and if there is a bug, I do not have to do anything, if it
is not in k-p. If it were in k-p, I would be responsible.
>> >> Either way, is it possible to add recommends on a per-flavour
>> >> basis, and if so, how?
>>
>> > Not sure, i know we can add dependencies though, so the same
>> > mechanism can probably quite easily be used for recomends.
>>
>> The Control file is a template that comes stuff that can be
>> substituted out -- like this Suggests: =L fdutils, =ST-doc-=V=SA |
>> =ST-source-=V On install, the -L and =ST etc are filled in with the
>> relevant values. The idea would be to add a Recommends: =RE filed
>> to the control file, and then the per flavour snippets can set
>> $(recommends) variable, and the targets/image.mk substitute in the
>> value.
> Yeah, and more often than not, those templates where strangely
> filled or not filled, probably due to miscomprehension of their
> mechanism.
Umm, when make-kpkg runs, the templates are filled -- or else
you shall not get any packages generated by make-kpkg. Now, if some
other entity not in k-p is trying to fill these templates, then I
have no comment on that. But the template filling code is on the same
path as the package generation path, and we abort on error.
> But you are missing the point, the above recomend go into the
> linux-2.6 debian/control file, which is uploaded as source, and it
> is against policy i hear to modify it at build time, so i doubt that
> the approach you use is compatible with our needs. Please have a
> look at debian/templates, debian/bin/gencontrol.py and the
> debian/control target in debian/rules.
I see nothing really earthshaking in there; it still seems
like a bunch of templates, with substitutions, concatenated together
to form a control file. There is no reason why most of that still
can't be used: make can call scripts as well, you know, to generate
files that are then read in/parsed by make. I see no technical
reasons why this can't be done in k-p, optionally.
What are the technical obstacles that you see?
manoj
--
Whereof one cannot speak, thereof one must be silent. Wittgenstein
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: