> If we want to prepare for this possibility, the one issue that the d-i > folks pointed out is that we'd probably want to refactor our meta > packages such that we could have both metapackages for the latest > 2.6.N and additional packages for the latest 2.6.N+, so users can > track whichever they prefer. One suggestion was to use > linux-image-etch-foo for tracking 2.6.N and something like > linux-image-etch+-foo for tracking the 2.6.N+ update.
Notice that this issue rejoins the discussion about metapackages we had concerning the 2.6.16-only etch branch, where i proposed already a similar scheme (altough having the normal linux-image-foo for etch, and another set of metapackages for the latest sid version not aimed at etch). Could you also please discuss with the d-i people the oportunity of, not including the .udeb generation into the main linux-2.6 packages, but integrating them again in a single source linux-2.6-udebs or whatever package, which would hold all arches, over the current situation ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
