Re: EPEL thoughts or views on packages deliberately left out of rhel?
On Thu, 1 May 2014 23:52:34 +0200 Dominik 'Rathann' Mierzejewski domi...@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. 1. 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 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 signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL thoughts or views on packages deliberately left out of rhel?
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_docs0
%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.
1. 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
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL thoughts or views on packages deliberately left out of rhel?
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? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL thoughts or views on packages deliberately left out of rhel?
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? ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
