https://bugzilla.redhat.com/show_bug.cgi?id=1221459 --- Comment #14 from Dave Johansen <davejohansen@xxxxxxxxx> --- (In reply to Marcin Haba from comment #13) > Hello, > > (In reply to Dave Johansen from comment #12) > > (In reply to Marcin Haba from comment #10) > > > 1) add to Spec Requires and BuildRequires tags appropriate subversion > > > dependecies (>= 1.8.13-7) > > > > I don't think that this is worth the trouble. Plus, it wouldn't be correct > > for all Fedora/EPEL releases. > > Yes, it is worth the "trouble". If somebody will try to use your Spec and > SRPM to build hgsubversion with subversion < 1.8.13-7 then occur the same > problem with swig - Traceback and segfaults. I think that it is obligatory > to add dependecies that have chance to work with result RPM package. This was technically an issue with subversion and not hgsubversion. It's been fixed in the repos and the fix doesn't require any change or rebuild on the part of hgsubversion. Basically, if hgsubversion had already been packaged, then this issue would have been introduced and then resolved without anything being required from hgsubversion, so having an explicit Requires or BuildRequires isn't completely true. Yes, to be "bug free" the requires is correct, but I don't believe that sort of information is intended to be captured in the packaging/.spec file and that's what Bugzilla and other issue trackers are for. Plus, I'm planning on including hgsubversion in EPEL 7 which has subversion 1.7 and so putting a specific version on the Requires would be conditional, really complicated and honestly just doesn't make a lot of sense to me. > > > 2) add a sample rc file /etc/mercurial/hgrc.d/ to enable hgsubversion > > > extension > > > > I'll check with upstream on the recommended way to handle this. With most > > Mercurial extensions, they default to off and have to be enabled. I realize > > that this one is a bit different, so I just want to make sure that upstream > > is ok with the "enabled by default" approach. > > OK. Thanks. I will be waiting on response in this subject. hggit has to be enabled by the user after install (like basically all Mercurial extensions), and upstream agreed that this is the right model to continue using ( https://groups.google.com/forum/#!topic/hgsubversion/ek0rNLCPZ7E ). > > > I a have question about tests cases from hgsubversion: > > > > > > 1) Why all tests executed by run.py finished successfully with installed > > > subversion(-libs|-python) 1.8.13-2 that version caused segfault on clone > > > action call? > > > > I'm not sure. Is this reproducible with the current version? If not, it's > > probably not worth spending any time on. > > No. Current version is OK with subversion >= 1.8.13-7. I double checked. Ok, so I believe that there's nothing required of hgsubversion and the packaging of it. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review