Description of problem: kdiff3 is available for EPEL 5 but not for EPEL 6 Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: kdiff3 is available on EPEL 5 but not 6 Expected results: kdiff3 is available on EPEL 6 Additional info: Current srpm builds in EPEL 6 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3046755
Created attachment 517371 [details] spec file for kdiff3 0.9.95 el6 with qt4 tested under scientific linux 6 64 bits
Created attachment 517372 [details] kdiff3 0.9.95 el6 with qt4 srpm full srpm for kdiff3 0.9.95 built with qt4 (without kde) tested under scientific linux 6 64bits.
The attached spec file needs to be fixed at least wrt the source URL, and the ownership of /usr/share/doc/kdiff3.
Created attachment 517577 [details] fix source0 fixed source0
Isn't the ownership set for all files by %defattr(-,root,root,-)?
The statement /usr/share/doc/kdiff3/* only ends up owning the files in that directory, but it won't own the directory /usr/share/doc/kdiff3/ itself. Besides, why wouldn't you want to use %doc is beyond me...
Sorry, I'm a newbie packager. %doc added a directory /usr/share/doc/kdiff3-0.9.95-2 I didn't find how to change this dir to /usr/share/doc/kdiff3 in the spec file. I tried %docdir but this doesn't help. So should I add these lines? %docdir /usr/share/doc/kdiff3 /usr/share/doc/kdiff3 /usr/share/doc/kdiff3/*
(In reply to comment #7) > Sorry, I'm a newbie packager. > %doc added a directory /usr/share/doc/kdiff3-0.9.95-2 No, it should generate the directory /usr/share/doc/kdiff3-0.9.95 > I didn't find how to change this dir to /usr/share/doc/kdiff3 in the spec file. And why would you want to do that? > So should I add these lines? > %docdir /usr/share/doc/kdiff3 > /usr/share/doc/kdiff3 > /usr/share/doc/kdiff3/* The correct version would be %{_docdir}/kdiff3/ or %doc %{_docdir}/kdiff3/ with or without the trailing slash. This will end up owning the directory. But this is all extremely off-topic regarding this bug.
Created attachment 517622 [details] spec file for kdiff3 0.9.95 el6 with qt4: fix for doc ok, there are now 2 dirs in /usr/share/doc: kdiff3-0.9.95 containing changelog and readme and kdiff3 contains kde doc.
No, you should not have 2 different doc dirs.
I just couldn't find how to merge these dirs. Can I just remove the changelog dir?
For fedora, we have: %files -f %{name}.lang %defattr(-,root,root,-) %doc AUTHORS COPYING ChangeLog README TODO This doesn't work on el6?
I just tried the fedora15 srpm (0.9.95-6) file and it seems to generate in EL6 as is! But the 2 specs generate very different versions of the software. kdiff3 can be built with kde4/qt4 or only with qt4 without any kde dependency. My spec just built the qt4 version, and it is MUCH simpler. Maybe the 2 versions of kdiff should be made available into epel? Anyway, kdiff3 should be made available into epel6.
(In reply to comment #13) > But the 2 specs generate very different versions of the software. > kdiff3 can be built with kde4/qt4 or only with qt4 without any kde dependency. > My spec just built the qt4 version, and it is MUCH simpler. > Maybe the 2 versions of kdiff should be made available into epel? Neal: any reason as to why the plain qt4 version is not shipped? You can probably build the two versions at once, and provide two subpackages that contain the wanted flavor(s).
1. This is the first I've heard of a plain qt4 version 2. I don't see any motivation to modify the fedora version to build a qt4-only version. I understand that you feel it simplifies the el6 spec (though I don't know the details of why that would be true), but I've had to do almost zero maintenance as it stands, and nobody has asked for a qt4-only version.
(In reply to comment #15) > 1. This is the first I've heard of a plain qt4 version > 2. I don't see any motivation to modify the fedora version to build a qt4-only > version. I understand that you feel it simplifies the el6 spec (though I don't > know the details of why that would be true), but I've had to do almost zero > maintenance as it stands, and nobody has asked for a qt4-only version. If the fedora srpm builds in epel 6 then that should be used unless there is a very specific reason not to do so. kdiff3 in epel 5 required kdebase(3)-devel, so no change here. That being said, a kdiff3-qt package built from the same spec, with different options and same provides, might be useful for users without kdelibs. But that is not epel-specific.
Any progress? It would be nice to have kdiff3 in EPEL6.
(In reply to comment #17) > Any progress? It would be nice to have kdiff3 in EPEL6. The original srpm gave a successful build in el6. All "progress" that was needed was the packager (who owns the epel6 branch) pushing that build into epel6. It's been over a year now, and I haven't tried building current f16 srpms for epel6. Neal, what is stopping this?
I haven't tried F16 srpm. However, debian and ubuntu have 2 packages: kdiff3 and kdiff3-qt You should consider doing the same.
(In reply to comment #19) > I haven't tried F16 srpm. > > However, debian and ubuntu have 2 packages: kdiff3 and kdiff3-qt > You should consider doing the same. Please, don't hijack this bug again. It is clearly about providing kdiff3 for epel6 as it is in fedora, and this is simple because it builds as is (or built as it was at the time). Your request for a qt-only build is independent (unless epel has a specific need for qt-only; no one has claimed that so far) and has been keeping this bug from going forward. Please file your own bug (or clone this one) for your independent issue.
Could we please get this out already? -- it's now two years. And whoever cares about qt-only build can grab the srpm and roll their own binary.
Neal, please: Either build with the existing Fedora spec for epel6 and push the build, or explain if there is a good reason not to do that, or simply release the epel6 branch that you own.
Built for epel6 OK http://koji.fedoraproject.org/koji/search?terms=kdiff3-0.9.95-3.el6&type=build&match=glob Submitted to el6 testing.
Thanks!