Bug 253557 - Packaging mercurial extensions
Packaging mercurial extensions
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: mercurial (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Neal Becker
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-20 11:58 EDT by Jonathan S. Shapiro
Modified: 2008-12-03 08:35 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-02 16:30:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan S. Shapiro 2007-08-20 11:58:15 EDT
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?
Comment 1 Bug Zapper 2008-05-14 10:02:33 EDT
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
Comment 2 Jonathan S. Shapiro 2008-05-14 10:43:18 EDT
Updating this to F9 to keep it alive.
Comment 3 Neal Becker 2008-05-14 13:25:44 EDT
I believe all 'standard' extensions - that is: all that are in hgext are
included packaged.  Is this sufficient?
Comment 4 Jonathan S. Shapiro 2008-12-02 16:30:28 EST
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.
Comment 5 Mads Kiilerich 2008-12-02 18:05:13 EST
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 ;-)
Comment 6 Jonathan S. Shapiro 2008-12-02 18:14:11 EST
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.
Comment 7 Neal Becker 2008-12-02 18:25:28 EST
Has a feature request been filed here?:
http://www.selenic.com/mercurial/bts/
Comment 8 Mads Kiilerich 2008-12-02 20:02:22 EST
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.)
Comment 9 Jonathan S. Shapiro 2008-12-02 21:52:16 EST
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.
Comment 10 Neal Becker 2008-12-03 06:39:30 EST
(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 ...
Comment 11 Jonathan S. Shapiro 2008-12-03 08:35:26 EST
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.

Note You need to log in before you can comment on or make changes to this bug.