[ FYI, top posting on purpose ]
This information should be in the SRPMS, correct? (Arch-specifics might be
more difficult though).
I'm thinking "out loud" here, so please excuse my ignorance of mash and
related support here.
Before looking at the effort required, could someone tell me if the
following solution be feasible?
1. Create a program to scrape through the SRPMS at ftp.redhat.com
under whatever directories are EPEL policy) and build an blacklist of
2. Modify mash to never build a package if it is this blacklist?
As far as Arch, as a start, the list could be only used for the x86-64 EPEL
repo. Or am I way off-the-mark of what is feasible?
On Sun, Mar 17, 2013 at 7:46 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
On dom, 2013-03-17 at 10:55 -0500, inode0 wrote:
> On Mon, Feb 25, 2013 at 2:37 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > On Sat, 23 Feb 2013 16:19:44 -0600
> > inode0 <inode0(a)gmail.com> wrote:
> >> Your situation probably explains most of the two large groups where
> >> either we see the same version or we see a lower version lingering in
> >> EPEL.
> >> Why not generate these lists and exclude the packages in question from
> >> the metadata built for architectures where they are included in RHEL?
> > Yeah, I suppose we could hard code such a list into mash.
> > I don't think the mash maintainers have time/desire to do this.
> > Would anyone else be willing to look into it?
> My lack of understanding the process is pretty limiting. Why in the
> world does it need to be hardcoded into anything? Surely mash can grab
> the list from a file or from the environment?!
mash is very simple. it takes the list of packages in the tag and makes
a repo from them. making sure the rpms are signed by the key defined.
it has no ability to do anything like has been proposed here. patches
are welcome. but it would require a manually managed list of packages.
since we don't have that info available. mash doesn't know about RHEL