EPEL thoughts or views on packages deliberately left out of rhel?

[Jim Perrin]

On 04/29/2014 10:43 PM, s at 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?



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77