Hide Forgot
I've been chatting with ThomasAH at selenic. A bunch of extensions are soon to be merged into trunk, and are currently unpackaged. I'ld like to build a mercurial-extensions package for extras, but I don't want to make your life harder by doing so. It seems to me that there are several ways one might proceed: 0. Offer you a modified package tree and spec file that generates both the existing package and a new package mercurial-extensions, which will (we hope) eventually disappear. 1. Offer you a modified package that simply incorporates more extensions into the existing mercurial package. 2. Whine at you to get you to do it (listed only for completeness :-) 3. Build and maintain a suitable extensions package until the corresponding extensions migrate into trunk, and ask you to add the appropriate Obsoletes line into the trunk package when these extensions have migrated. 4. Something else that you may suggest that would be better than any of these. Based on conversation with ThomasAH, the specific extensions that would make sense to package at this time are: forest keyword alias imerge parentrevspec children All of these (except forest) are in crew or going into crew, and ThomasAH thinks it is probably time for forest to go into crew, but those updates presumably won't hit the street until 0.9.5 or later, and the forest extension (at least) is widely used now. Reactions/thoughts?
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.