On Mon, Sep 01, 2008 at 05:39:35PM +0200, Bernhard R. Link wrote: > * Moritz Augsburger <[EMAIL PROTECTED]> [080901 15:16]: > > Currently, all packages that do not match a certain component in their > > "Section" field get put into the first available component. > > > > I would like to be able to specify some components that get never > > included in the repository. > > I'm a bit undecided what would be a good way to implement this in a > clean general way. > The section itself is primarily a section, and unknown values there > means usually just a subsection. > > I assume your packages in the case have a section like > foo-private/subsection?
Yes and no - that was the way we thought to do it when when I wrote the bugreport, but now we decided all our packages will get the same component but different sections. So we need to allow component == foo and not ( section == restricted or section == private ) > [...] > Without that that would need some filtering based on the section field. > The questions is where to do this. > > (2) One possiblity would be to extend the uploaders file with arbitrary > filtering (I wanted to add some more filters anyway, and just some > based on fields sounds quite a good thing to start with). > This would only work with include and processincoming (and not > includedeb or includedsc AFAIR), though. I think this is the best idea, but the file/keyword should be renamed to soemthing more descriptive like "permissions" or "upload-requirements". Then you should implement a bit more complex filter syntax, I thought of allow/deny statements, and the first one matching decides, eg: | allow from key-id 0xblablaa | deny component == "foo-restricted" | allow component == "foo" && section == "public" | allow component == "foo" && key-id 0xfoobar | deny component == "foo" | allow * This way, 0xblablaa would be able to upload everything, even into "foo-restricted" and all other. Nobody else can upload into "foo-restricted". Upload to component "foo" is only allowed if section is public or (and then to any section) if key-id is 0xfoobar. All other components/sections are free for everybody. You could match to all fields available in the changes/control/...-files, and a field not available evaluates to true. Additionaly, there should be the key-id of the uploader requiring a signature. I see no reason why you shouldn't be able to use them with includedeb or includedsc, I think all required informations are included in them. > Which of those options (1-4) would suite you? Do you see any advantages / > disadvantages I missed? As I wrote above, #2 seems to be the most flexible. > > This results from the fact, that we have some components > > "foo-restricted" and "foo-private" that musn't be available to all pcs > > and therefore musn't be in the public repository. Currently I'm using a > > "Log:" script that scans the component name and starts a "reprepro > > remove" for packages with the wrong component, which isn't too elegant. > > Another possible workaround is to actually have such a component and > make the pool/evilcomponent and dists/*/evilcomponenent directories not > accessible for the webserver. Also ugly but in another way... Yes, both are not really "clean". Schöne Grüße Moritz Augsburger
signature.asc
Description: Digital signature
