The RC for el7 specifically omits packages that have drawn interest in the past. A few examples of such packages would be kmail and pidgin.
kmail is ordinarily part of the kde-pim suite, but is stripped from the final build via some 'rm' handiwork in the spec. Pidgin is omitted from the build via a check to see if the build host is rhel. The libs are used and included, but the binary is no longer produced.
I'm curious to know if anyone from the epel side has thought about how these might be included. This doesn't appear to be a more straightforward case like thunderbird, but would require some prep-work to not overwrite core packages.
Thoughts as to how this might be accomplished?
On 2014-04-30 06:57, Jim Perrin wrote:
The RC for el7 specifically omits packages that have drawn interest in the past. A few examples of such packages would be kmail and pidgin.
kmail is ordinarily part of the kde-pim suite, but is stripped from the final build via some 'rm' handiwork in the spec. Pidgin is omitted from the build via a check to see if the build host is rhel. The libs are used and included, but the binary is no longer produced.
In the pidgin case is libpurple the main thing that gets used in RHEL? If so but it's under the 'pidgin' namespace then maybe a -bin package could be provided via EPEL or some other means. Alternatively it might make sense to file a BZ to have it moved under a different package name altogether?
kmail seems like a more simple case - build an alternate spec which removed everything from the source tarball *except* kmail?
Just spitballing here to get the conversation started...
-s
I'm curious to know if anyone from the epel side has thought about how these might be included. This doesn't appear to be a more straightforward case like thunderbird, but would require some prep-work to not overwrite core packages.
Thoughts as to how this might be accomplished?
On 04/29/2014 10:43 PM, s@shk.io wrote:
On 2014-04-30 06:57, Jim Perrin wrote:
The RC for el7 specifically omits packages that have drawn interest in the past. A few examples of such packages would be kmail and pidgin.
kmail is ordinarily part of the kde-pim suite, but is stripped from the final build via some 'rm' handiwork in the spec. Pidgin is omitted from the build via a check to see if the build host is rhel. The libs are used and included, but the binary is no longer produced.
In the pidgin case is libpurple the main thing that gets used in RHEL? If so but it's under the 'pidgin' namespace then maybe a -bin package could be provided via EPEL or some other means. Alternatively it might make sense to file a BZ to have it moved under a different package name altogether?
Yes, libpurple seems to be the main thing needed/wanted. Important bits from the spec appear to be ->
%if 0%{?rhel} >= 7 %global build_only_libs 1 %global api_docs 0 %endif
%if %{build_only_libs} SWITCHES="$SWITCHES --disable-consoleui --disable-gtkui" %endif
%if ! %{build_only_libs} desktop-file-install --vendor pidgin --delete-original \ --add-category X-Red-Hat-Base \ --dir $RPM_BUILD_ROOT%{_datadir}/applications \ $RPM_BUILD_ROOT%{_datadir}/applications/pidgin.desktop %endif
kmail seems like a more simple case - build an alternate spec which removed everything from the source tarball *except* kmail?
kmail actually worries me a bit more, as they've removed it from kdepim via a patch:
%if 0%{?rhel} %patch400 -p1 -b .rhel %endif
which is 90 lines of various build options that impact the entire package. sample:
+ set(BUILD_kmail FALSE) + set(KMAIL_SUPPORTED FALSE) + set(BUILD_knode FALSE)
macro_optional_add_subdirectory(korganizer) if(KDEPIM_BUILD_DESKTOP) macro_optional_add_subdirectory(akregator) - macro_optional_add_subdirectory(archivemailagent) - macro_optional_add_subdirectory(importwizard) - macro_optional_add_subdirectory(kaddressbook) - macro_optional_add_subdirectory(kmailcvt) macro_optional_add_subdirectory(knotes) - macro_optional_add_subdirectory(ksendemail) - macro_optional_add_subdirectory(ktnef) - macro_optional_add_subdirectory(mailimporter) - macro_optional_add_subdirectory(pimsettingexporter) - macro_optional_add_subdirectory(kalarm)
I guess I have two specific questions for this.
1. Can epel track and provide the same source versions of packages that RH provides for RHEL? 2. Is the demand worth the effort?
On Wednesday, 30 April 2014 at 15:02, Jim Perrin wrote:
On 04/29/2014 10:43 PM, s@shk.io wrote:
On 2014-04-30 06:57, Jim Perrin wrote:
The RC for el7 specifically omits packages that have drawn interest in the past. A few examples of such packages would be kmail and pidgin.
kmail is ordinarily part of the kde-pim suite, but is stripped from the final build via some 'rm' handiwork in the spec. Pidgin is omitted from the build via a check to see if the build host is rhel. The libs are used and included, but the binary is no longer produced.
In the pidgin case is libpurple the main thing that gets used in RHEL? If so but it's under the 'pidgin' namespace then maybe a -bin package could be provided via EPEL or some other means. Alternatively it might make sense to file a BZ to have it moved under a different package name altogether?
Yes, libpurple seems to be the main thing needed/wanted. Important bits from the spec appear to be ->
%if 0%{?rhel} >= 7 %global build_only_libs 1 %global api_docs 0 %endif
%if %{build_only_libs} SWITCHES="$SWITCHES --disable-consoleui --disable-gtkui" %endif
%if ! %{build_only_libs} desktop-file-install --vendor pidgin --delete-original \ --add-category X-Red-Hat-Base \ --dir $RPM_BUILD_ROOT%{_datadir}/applications \ $RPM_BUILD_ROOT%{_datadir}/applications/pidgin.desktop %endif
[snip - about kmail]
I guess I have two specific questions for this.
- Can epel track and provide the same source versions of packages that
RH provides for RHEL? 2. Is the demand worth the effort?
I'd be interested in the pidgin package. However, current package in RHEL7 disables Gadu-gadu support in libpurple, which is a deal-breaker for me. I filed a bug[1] about it, but if it's not fixed, I'll be rolling my own packages anyway.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1064053
Regards, Dominik
On Thu, 1 May 2014 23:52:34 +0200 Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Wednesday, 30 April 2014 at 15:02, Jim Perrin wrote:
...snip...
[snip - about kmail]
I guess I have two specific questions for this.
- Can epel track and provide the same source versions of packages
that RH provides for RHEL? 2. Is the demand worth the effort?
I'd be interested in the pidgin package. However, current package in RHEL7 disables Gadu-gadu support in libpurple, which is a deal-breaker for me. I filed a bug[1] about it, but if it's not fixed, I'll be rolling my own packages anyway.
I think the way to go here would be for epel to ship parallel installable versions of those things. This would decouple them from trying to keep matching rhel exactly.
However, I don't know how hard this will be to actually do in practice. It might end up being way too much effort. ;(
kevin
epel-devel@lists.fedoraproject.org
-
Dominik 'Rathann' Mierzejewski -
Jim Perrin -
Kevin Fenzi -
Sam Kottler