Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Filtering in pulp currently only effects published Content Views but there is no way to apply a filtering algorithm to a yum repository feed.

There are often cases where repositories contain large sets of packages that are never used (architectures, subdirectories, etc), eg:

http://linux.dell.com/repo/hardware/latest/platform_independent/rh60_64/

where the user may only want a certain subset of the large repo.

The customer should have the ability to specify on the repo a set of filters which prevent packages from being synced thus saving disk space and sync time.

I'm interested in thoughts on how this might work. I imagine that some sort of regex matching on the "name" could get us a lot of the way. The question is, how many regexs is it going to take?

Are we interested in a scenario like the dell repo where there are tons of RPMs, but we only want a few?

Is it sufficient to do a default-none when one or more filters are present, so that the user must match the packages to get? Or do we need the ability to exclude matched packages?

Either way, this is only likely to be useful in cases where the user can make a small number of filters in a simple way to get the behavior they want. Thoughts?

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

*** This bug has been marked as a duplicate of bug 754576 ***