Hi, > > I like this idea, but I think that there are, in the end, orthogonal, > > though this one would also allow handling the other one. > > I also consider this orthogonal, and think that it would be nice to > have pattern filtering moved to the core instead of only handling it in > some Source plugins, this would be more consistent with the existing > `path` attribute, and hopefully also allow removing the `directory` > attribute from `junction` elements (handling this generically from the > core might introduce a performance hit, though; it would be good if the > plugin had an opportunity to do the filtering, and fallback to generic > filtering for plugins which don't implement a filtering stage method). > > I do really think it is a different thing though, specifying /paths/ > (or subdirectories) to cherry pick in a source for staging, is > different from automatically excluding file /types/, inasmuch as the > feature being discussed initially here, does not require the user to > have intimate knowledge of the location of unsupported files within a > tarball (you don't have to know exactly where a dev node is; instead > things "just work"). > > > Would you see a reason why we would not want both? > > > > Not me :)
Fair points, I am now convinced that this is really orthogonal even though it may solve the current problem in a different way. I should also add that I'm +1 on Ben's medium-term proposal. Regarding where to implement it, I wonder if the DownloadableFileSource would be a better place than the tar source specifically. There is no particular reason a stage3 archive has to be a tar archive. Although tar is pretty common, there's nothing wrong with it being a zip, or any other archive format really. OSTree will still need to be handled differently than tar and friends, but that'd be the case either way. Thanks, Chandan
