Bug 250103
Summary: | enable libdap for EPEL | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Balint Cristian <cbalint> |
Component: | libdap | Assignee: | Patrice Dumas <pertusus> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | Flags: | kevin:
fedora-cvs+
|
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-10-27 21:14:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Balint Cristian
2007-07-30 14:42:34 UTC
Who will maintain this package in EPEL? Can we get an ack from Patrice? Trouble with libdap is that currently they change the API very often and I don't think it is doable to maintain it in EPEL. However I contacted upstream about ABI stability stating the issue, in particular the inclusion in EPEL. They are still evaluating this issue. In the mean time I am not ready to maintain it in EPEL. Cristian, if you are ready to backport code, you can maintain it in EPEL, but otherwise I think it is better to wait and don't build libdap support for the time being. I am setting fedora-cvs to - for now... please reset it to ? and add a new template if you requre further cvsadmin action. OK. Patrice lets drag in libdap in EPEL but lets not follow upstream necesarilly. However this lib provides only db interconect stuff, so we can live 2 years on top of one version without update it all time. When applications will require newer libdap i will announce you, fill bz with explanations and so on. I would prefer to leave you as admin for EPEL too, just dont update it too often, i will prefer discuss with you if i will encounder issue wich require update of package. I will re-fill now a CVS request. Package Change Request ====================== Package Name: libdap New Branches: EL-4 EL-5 (In reply to comment #4) > OK. > > Patrice lets drag in libdap in EPEL but lets not follow upstream necesarilly. > However this lib provides only db interconect stuff, so we can live 2 years on > top of one version without update it all time. When applications will require > newer libdap i will announce you, fill bz with explanations and so on. Of course if we are to put libdap in EPEL we should just let it stay as is forever, unless some app needs a new version. But it opens the possibility for the following problems: - if there is a security issue in libdap, and it is a network app so it may happen, the fix will need to be backported from the libdap current release to the release in EPEL. I don't have the skills and time to do that. I can report security issues and talk about on the upstream mailing list, but I can't do the backport. Are you committing to do the security issues backporting? - if a new version is needed, it means that a compat package has to be made, since ABI in EPEL should never be broken. I don't want to maintain compat packages in EPEL (except when it is needed and was unforeseen). Are you committing to maintain the compat packages? > I would prefer to leave you as admin for EPEL too, just dont update it too > often, i will prefer discuss with you if i will encounder issue wich require > update of package. Trouble is that I don't want to maintain it as long as they break the ABI every 6 months and support only the latest release. It implies the work I describe above and I don't have time for that. Now that upsteram is aware of this issue, they may commit themselves to keep ABI or maintain other releases since they want libdap in EPEL, but until they do I don't want to maintain it myself. Ok. I help you to maintain. Package Change Request ====================== Package Name: libdap New Branches: EL-4 EL-5 Updated EPEL Owners: pertusus, cbalint Ok. Be prepared for backporting of C++ code... cvs done. Good luck and make sure to do lots of testing. ;) |