[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: perl-Net-IP need on EPEL-4

Xavier Lamien wrote:

2008/5/22 Xavier Bachelot <xavier bachelot org <mailto:xavier bachelot org>>:

    Remi Collet wrote:


        I maintain ocsinventory-agent for Fedora/EPEL.
        This package requires perl-Net-IP which is not available on RHEL-4
        (was in "extras" until FC4 and in "core" from FC5)

        Would it be possible you push it to EPEL for RHEL 4 ?
        Test "build and use" seems ok for me.

    You may want to file a bug, you'll have more chance it doesn't get
    lost in the noise than a mail and it will be easier to track for the
    perl-Net-IP owner.

    Review request is : https://bugzilla.redhat.com/show_bug.cgi?id=226271
    Include it in the bug, it'll save the owner a bugzilla search to
    file the branch request.

Hmm, no really need to file a new bug for that.
Currently there is no maintainer/branches against epel repository.

If you're interesting to co-/maintain this package just request a CVS Change request into a new comment or ask for (in hope someone could be interested, maybe me :)).

That's not how I interpret what's in the wiki.

You cannot just 'hijack' a package, especially if the Fedora maintainer participate in EPEL, you have to ask first. In this very case, I suggested Remi to file a bug because the maintainer for this package wasn't very responsive to a build I requested for another package both by mail and then via bugzilla. The bug is less likely to get lost than the mail. Obviously, there's no offense intended here, I fully understand the maintainer is probably busy with other things, especially given he works for RedHat and probably have higher priorities. Also, as a side note, this package is included in RHEL5 proper, so it might make sense for the maintainer to be the same for EPEL4 and RHEL5.

Generally speaking, I went thru the process of requesting packages for EPEL several times now, and I find it hard to track by mail when the maintainer is not quick at responding. imho, a bug is easier to track both for the requestor and the maintainer. ymmv.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]