On 10/11/2010 01:03 PM, Jason Dobies wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1good point .. to me a feed is just a way to get packages into a repo and uploads are another way. I don't think we said anywhere that by defining a feed for a repo we have a contract to ensure that the package content in the upstream is exactly the same as is on the pulp server.This is a good distinction. If we treat feeds the way Mike is suggesting, uploading a package into a repo isn't a huge issue. If we're treating the feed as the authoritative source on packages in that repo, then we have to take into account things like when the feed previously indicated package X was in it but is no longer there. Do we delete package X on pulp then? If we do delete package X, I don't see how we could support uploaded packages into a feed-backed repo. Otherwise, when we sync with the feed it will notice the uploaded package was not in the recent sync with the feed and delete it. And I'd really rather not go into the realm of keeping track of packages that were uploaded v. those that came from the feed.
We have slightly conflicting terms involved here. The term 'feed' suggests that it is a means to populate the repo. Basically, import packages. However, repo 'sync' implies that the feed represents an authoritative source. I know, it's only semantics but ...
So there's two questions here: - - What do we want the feed to represent, simply a one way mechanism to introduce packages into a repo (in which case we really should allow for more than one feed per repo) or the feed acting as a more authority figure who will keep the repo up to date with its knowledge of packages (in which case we may need to implement remove functionality). - - How does pulp currently act?That said I do see where you are coming from and I expect some people do see repos with feeds as behaving this way. I just don't want to keep going down a path where we constrain pulp to work the way Red Hat releases and manages content. I still see the project as having the goal to be a generic software distribution/management tool and not something who's job is to enforce workflow. If users want to mix content into one repo by uploading packages from a local dir and feeding them in from an external source I think we should let them do that. If we want to start putting rules, restrictions and policy around how content flows into a repo I think we should make it optional and configurable. Mike _______________________________________________ Pulp-list mailing list Pulp-list redhat com https://www.redhat.com/mailman/listinfo/pulp-list- -- Jason Dobies RHCE# 805008743336126 Freenode: jdob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMs1F8AAoJEOMmcTqOSQHCc/gIAJeeJ8Q0IbcdnnvJhaAKwwhe Mqw5o9xiXYQO9se7aFIGLKLzGazjLbTwXOoCK4A/LXFYjLT45v3nx1sS2vo3GQ/q BKxiTOiDbcTG1hrEYM+FU77GntLew4PdRyDMbPBNr4yE1gmY8LoozV7L8/G7eyE9 1oYIL9UvYFMzEWkr/Om4hdc8uDhGjIxvQ3J8uii0832Qq/iLwYHSPrbzUA0o8sjJ dq1elWrgL7QcAV9HTnQgSFxNcGmL3/8JW0YuCMz3f+RoNjj6R9HrnJFErEhZ88Pr P88+s/mn1Yn2SWWnrT1wgz6LKyttJnqzAOOmeTG47FB+9BexRg2nGMfOFo14C3Q= =aTxN -----END PGP SIGNATURE----- _______________________________________________ Pulp-list mailing list Pulp-list redhat com https://www.redhat.com/mailman/listinfo/pulp-list
Description: S/MIME Cryptographic Signature