On 11/01/16 at 10:49 +0100, Stefano Zacchiroli wrote: > On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote: > > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote: > > > So you don't want another component, but something that looks like a > > > component in some places only? I.e. it behaves like a component in that > > > it gets its own Packages (and Sources?) indices, but it has neither its > > > own area in pool/ nor is it used in packages' Section field. > > > > Right. This would be nice for some other use-cases too, like cut-down > > Packages/Sources files for special-purpose systems. > > Correct. And that's why I was actually hoping that something like this > could actually be a *generalization* of how Packages/Sources files are > being generated, rather than a new special case to be added---which > would certainly be a sign of bad design for this proposal.
Right, it would be nice to implement something similar to SQL VIEWs vs SQL TABLEs: the underlying data (packages) would be exactly the same, but dak would generate an additional Sources/Packages with a restricted set of packages, based on a filter on packages' fields (here, the packages' section). The same idea could be used for LTS support, to expose Sources/Packages files with only supported packages. Lucas
signature.asc
Description: PGP signature
