On Fri, 2008-01-11 at 01:24:33 +0100, Frans Pop wrote: > On Friday 11 January 2008, you wrote: > > Joey, I don't think that that the Package-Type field ending up in the > > binary package can be qualified as bloat given that except the filename > > and the origin of the file, udeb can't be identified as such. > > I'm sorry, but I agree with Joey. > There is absolutely no reason why we need the package type in the control > file for udebs. They are already 100% identifyable by both section and > extention.
Well then there's also the argument that there's no point in having it in the source control either, it could be inferred from the section. But those seem quite weak and specific ways to do so. Anyway, I don't think that'd be clean, and we might want to use that field for other package types in the future (translation debs, or debugging debs come to mind). > The way this was implemented basically just ignores the only current > official user of the package type field, I mentioned I'd implement it that way one year ago (or so) on #d-b, and no one seemed to oppose, and I requested comments on the patch implementing this again on #d-b few days before committing. That does not mean that decision could not be changed, but I don't see a good reason to do so, the current implementation seems cleaner anyway. > and is thus not policy compliant. The initial udeb support seems to have been implemented and deployed in an ad-hoc way, overriding[0] dpkg, which is perfectly fine, as that's how a lot of things are implemented and deployed in Debian. But I'd not go as far as calling that policy. regards, guillem [0] I'm not sure this strictly expresses the meaning I've in mind, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
