CentOS - Oct 2017 - How to encourage maintainers to update their software

On 10/27/2017 2:54 PM, Frank Cox wrote:
>
> I do that with a number of packages that are either newer or simply not
available in the various Centos repos.  In many cases it's as easy as
downloading a new tar source file and adding it to the existing source rpm,
doing three seconds of editing on the spec file to account for the new update,
and compiling the result.  Sometimes it's even easier -- just download a
newer Fedora rpm and compile that on your Centos system.
>
It would be nice if this remained even a *suggestion* at the Fedora 
layer, but there seems to be from occasional obliviousness to outright 
hostility to the idea of keeping spec files broadly compatible across a 
range of downstream releases and for other RPM-based distributions, or 
not ripping out compatibility at Fedora-speed. (Even leaving aside 
"burn-the-ships" actions like outright banning SysV init scripts.)

It didn't seem to use to be that case. IMO it makes a lot more sense to 
wrap distro-specific .spec file changes in conditionals and let the 
rpmbuild do the right thing than to post and maintain separate versions 
for Fedora, EPEL, and anything else.


-jc

On 10/28/2017 12:28 PM, Japheth Cleaver wrote:
> On 10/27/2017 2:54 PM, Frank Cox wrote:
>>
>> I do that with a number of packages that are either newer or simply
>> not available in the various Centos repos.? In many cases it's as
easy
>> as downloading a new tar source file and adding it to the existing
>> source rpm, doing three seconds of editing on the spec file to account
>> for the new update, and compiling the result.? Sometimes it's even
>> easier -- just download a newer Fedora rpm and compile that on your
>> Centos system.
>>
> It would be nice if this remained even a *suggestion* at the Fedora
> layer, but there seems to be from occasional obliviousness to outright
> hostility to the idea of keeping spec files broadly compatible across a
> range of downstream releases and for other RPM-based distributions, or
> not ripping out compatibility at Fedora-speed. (Even leaving aside
> "burn-the-ships" actions like outright banning SysV init
scripts.)
> 
> It didn't seem to use to be that case. IMO it makes a lot more sense to
> wrap distro-specific .spec file changes in conditionals and let the
> rpmbuild do the right thing than to post and maintain separate versions
> for Fedora, EPEL, and anything else.
If people want all the newer packages that exist in Fedora .. why not
just use Fedora?

Enterprise distributions are designed to be maintained for 10 years so
when you make an investment of X million dollars in a piece of software,
you can use it for an extended period of time.  Having all the latest
packages is not what Enterprise Linux is about.  That is what Fedora is
about.

Fedora has introduced a new feature called modularity
(https://docs.pagure.org/modularity/).  Eventually, when / if modularity
is rolled into Red Hat Enterprise Linux, you will get some more
flexibility in RHEL (and therefore CentOS as we use RHEL sources).

CentOS Linux is a great Linux distribution.  We want everyone to use it.
 But trying to convert CentOS Linux into Fedora is not only redundant
(Fedora already exists .. use it) .. a bastardized version of CentOS
with hundreds of newer manually maintained components is not really
CentOS, and Fedora is likely more stable than that monstrosity anyway.

There are things to add newer pieces to CentOS (SCL SIG, PaaS SIG,
etc.), and those can be done now and integrated into the Enterprise
Distro.  If those are what you need, that is what they're for.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20171028/7e4e62d2/attachment-0001.sig>

On Sat, 28 Oct 2017 13:07:41 -0500
Johnny Hughes wrote:
>  But trying to convert CentOS Linux into Fedora is not only redundant
> (Fedora already exists .. use it) .. a bastardized version of CentOS
> with hundreds of newer manually maintained components is not really
> CentOS, and Fedora is likely more stable than that monstrosity anyway.
There's a difference between upgrading core operating system functionality
and a changing a few userland programs.  I compile the latest versions of
Sylpheed and astyle (for example) and use those programs on my Centos 7 desktop
computer.  I don't see any issue with doing things like this and don't
believe that it decreases the stability of the system.

I don't want to tear my whole computer down and upgrade my operating system
every six months, and I don't want to deal with the bleeding-edge stuff that
might or might not work when it affects something like network connectivity or
whether I actually get a picture on the screen when I boot up my computer.  But
for userland programs, why not run the latest version of Libreoffice or  Cool
Reader if it's easy to compile them and I can get a few new features out of
it?

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com

On 10/28/2017 02:07 PM, Johnny Hughes wrote:
> On 10/28/2017 12:28 PM, Japheth Cleaver wrote:
>> On 10/27/2017 2:54 PM, Frank Cox wrote:
>>> I do that with a number of packages that are either newer or simply
>>> not available in the various Centos repos.? In many cases it's
as easy
>>> as downloading a new tar source file and adding it to the existing
>>> source rpm, doing three seconds of editing on the spec file to
account
>>> for the new update, and compiling the result.? Sometimes it's
even
>>> easier -- just download a newer Fedora rpm and compile that on your
>>> Centos system.
>>>
>> It would be nice if this remained even a *suggestion* at the Fedora
>> layer, but there seems to be from occasional obliviousness to outright
>> hostility to the idea of keeping spec files broadly compatible across a
>> range of downstream releases and for other RPM-based distributions, or
>> not ripping out compatibility at Fedora-speed. (Even leaving aside
>> "burn-the-ships" actions like outright banning SysV init
scripts.)
>>
>> It didn't seem to use to be that case. IMO it makes a lot more
sense to
>> wrap distro-specific .spec file changes in conditionals and let the
>> rpmbuild do the right thing than to post and maintain separate versions
>> for Fedora, EPEL, and anything else.
> If people want all the newer packages that exist in Fedora .. why not
> just use Fedora?
>
> Enterprise distributions are designed to be maintained for 10 years so
> when you make an investment of X million dollars in a piece of software,
> you can use it for an extended period of time.  Having all the latest
> packages is not what Enterprise Linux is about.  That is what Fedora is
> about.
>
> Fedora has introduced a new feature called modularity
> (https://docs.pagure.org/modularity/).  Eventually, when / if modularity
> is rolled into Red Hat Enterprise Linux, you will get some more
> flexibility in RHEL (and therefore CentOS as we use RHEL sources).
>
> CentOS Linux is a great Linux distribution.  We want everyone to use it.
>  But trying to convert CentOS Linux into Fedora is not only redundant
> (Fedora already exists .. use it) .. a bastardized version of CentOS
> with hundreds of newer manually maintained components is not really
> CentOS, and Fedora is likely more stable than that monstrosity anyway.
>
> There are things to add newer pieces to CentOS (SCL SIG, PaaS SIG,
> etc.), and those can be done now and integrated into the Enterprise
> Distro.  If those are what you need, that is what they're for.
>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
Well, I am trying to get a couple of applications compiled that I believe are
quite compatible with the positioning of CentOS:

- The graphical configuration utility for fcitx (fcitx-configtool) is missing
and any configuration presently has to be done by manually editing the complex
configuration files which are very poorly documented. Thus configuration of
fcitx for e.g. entering/editing Chinese text took a long time and I still have a
couple of issues that I have been unable to resolve.

- The geany editor is missing the markdown plugin, this however, may shortly be
resolved.

- I'd love to have keepassx updated so bugs are fixed and the file format
becomes compatible with the file format used by its Windows counterpart and
files thus interchanged without any problems.

- pdfshuffler is not available for CentOS 7, only CentOS 6.

On 10/28/2017 01:28 PM, Japheth Cleaver wrote:
> It didn't seem to use to be that case. IMO it makes a lot more sense 
> to wrap distro-specific .spec file changes in conditionals and let the 
> rpmbuild do the right thing than to post and maintain separate 
> versions for Fedora, EPEL, and anything else. 
In my former role as package maintainer for the PostgreSQL development 
group several years ago, I was contracted to do RPMs for several 
different distributions.? And while this was several years ago, the 
basic RPM mechansims have not changed that significantly, and this kind 
of maintenance can become a rat's nest nightmare very quickly.? I found 
that, specifically for PostgreSQL, the complexity increase was not 
linearly proportional to the number of distributions and versions of 
distributions supported; rather, it was much more like a cubic or 
quartic relationship with multiple poles and zeroes (using Z transform 
terminology) and pitfalls everywhere.? The current PostgreSQL RPm 
maintainers do a great job supporting what they do, but it is not easy 
at all to support more than four distribution versions with one spec file.

Now, this thread is also talking about doing your own rebuilds, and, to 
a point, this works quite well.? Especially in cases where the EPEL 
maintainer simply refuses to update a package because it would cause a 
version bump of that particular package and 'version bumps require Deep 
Reasons' (paraphrased from an actual response).? My experience 
maintaining the PostgreSQL RPMs prepared me well for some of the things 
I have rebuilt (such as kicad) on C7.

HOWEVER, there is a hard and fast and totally inviolate rule to rolling 
your own rebuilds: "You break it, you keep it."? You are taking your
own
system's stability into your own hands; for some packages (like kicad, 
or gnuradio, or other relatively stand-alone packages that don't require 
major shared library replumbing) it's fairly easy and safe to do your 
own builds; for some packages it is going to be nearly impossible if the 
packages' upstream developers haven't made it easy to locally build 
their dependencies with the sometimes very specific version requirements 
(case in point: Ardour).? And some of these packages have no security 
footprint as far as updates are concerned (web browsers and email 
clients absolutely have major security footprints and need to stay 
updated, but something like kicad does not).

There are automated tools to do these sorts of things, such as the perl 
script 'smock' which does a reasonable job doing source build 
dependencies, as long as the buildrequires deps in the source RPM are 
proper and there are no hidden ones (experienced RPM rebuilders know I 
say that a bit tongue in cheek).? Whatever you do, do NOT rebuild as 
root.? Mock and similar tools make it possible to have reproducible 
builds, and it is strongly encouraged that these tools be used.

BUT, again, "you break it, you keep it" applies strongly because that 
package you built might have required a package that isn't currently in 
C7 but might be added at some future date, and your hand-built package 
might cause a real security update to fail in weird ways.? Caveat 
aedificator, perhaps?? You are then responsible to keep your hand-built 
dependency updated yourself.