Bug 253557
| Summary: | Packaging mercurial extensions | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan S. Shapiro <shap> |
| Component: | mercurial | Assignee: | Neal Becker <ndbecker2> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 9 | CC: | dennis, mads, mmcgrath, triage |
| 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: | 2008-12-02 21:30:28 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
Jonathan S. Shapiro
2007-08-20 15:58:15 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Updating this to F9 to keep it alive. I believe all 'standard' extensions - that is: all that are in hgext are included packaged. Is this sufficient? Yes. The remaining problem is architectural: HG needs a way to let independent extensions be conveniently added, and it doesn't presently have one. That's probably out of scope for this bug and should be taken up separately. As far as I know the hg architecture and the Fedora packaging makes it easy to add extensions, and they can easily be provided in separate packages. It could be interesting to find out what is missing. But yes, that should probably be discussed and tracked upstream ;-) When last I looked (and this may have changed), the specific issue was that there is no good way to configure a list of locations to check for extensions. This makes it challenging to package extensions independently, because it's probably bad form to clutter up the hgext/ directory (seeing as how that is owned by the HG folks). It's certainly not a big or complicated problem. More of a very minor nuisance. Has a feature request been filed here?: http://www.selenic.com/mercurial/bts/ I agree that it could be a problem on systems without a proper package manager. On Fedora I think it would be fine if other packages placed extensions in /usr/lib/python2.5/site-packages/hgext/ - just like how mercurial-hgk does now. So just go ahead and package what you are missing from 1.1 ;-) (FWIW extensions can also be placed anywhere in python path or referenced with full path when enabling them.) Okay. It's coming back to me. The situation was as follows: 1. At that time, the fedora package for HG was missing a bunch of stuff. I wanted to package the missing bits, HOWEVER 2. I knew that several of those pieces were about to be merged upstream, SO 3. If I packaged them separately, it was important *not* to put them in hgext, because if they got put there they would interfere with the later update of the base HG package. So to summarize, I think it would be useful if an hgext-like directory scheme existed where upstream promised *not* to put things. I'll suggest it upstream and see what the response is. It also would have sufficed to have a systemwide hgext loaded, since that could conceivably add load paths. This too was under discussion, but I got distracted by other things. (In reply to comment #9) > Okay. It's coming back to me. The situation was as follows: > > 1. At that time, the fedora package for HG was missing a bunch of stuff. I > wanted to package the missing bits, HOWEVER > 2. I knew that several of those pieces were about to be merged upstream, SO > 3. If I packaged them separately, it was important *not* to put them in hgext, > because if they got put there they would interfere with the later update of the > base HG package. > How would it interfere? This is no different than many other examples: emacs/site-list, cron.d, preload.d ... Interfere as follows; I ship a package that deploys hgext/foo. Later, the mercurial team updates the main HG package to deploy hgext/foo, and their upgrade fails due to collision. The reason this happens is that we had two different people packaging the same stuff, and no sensible way in the HG extension directory structure for them to stay out of each other's way. |