Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > alt.os.linux > #54299 > unrolled thread

"semi-open source package maintainer perversion"

Started byPedro Valdez <pedro1492@lycos.com>
First post2019-03-02 19:43 -0800
Last post2019-03-03 17:45 +0000
Articles 4 — 4 participants

Back to article view | Back to alt.os.linux


Contents

  "semi-open source package maintainer perversion" Pedro Valdez <pedro1492@lycos.com> - 2019-03-02 19:43 -0800
    Re: "semi-open source package maintainer perversion" gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-03 04:43 +0000
    Re: "semi-open source package maintainer perversion" "J.O. Aho" <user@example.net> - 2019-03-03 10:07 +0100
    Re: "semi-open source package maintainer perversion" William Unruh <unruh@invalid.ca> - 2019-03-03 17:45 +0000

#54299 — "semi-open source package maintainer perversion"

FromPedro Valdez <pedro1492@lycos.com>
Date2019-03-02 19:43 -0800
Subject"semi-open source package maintainer perversion"
Message-ID<2cdd8213-460f-4594-a232-92582fb28953@googlegroups.com>
I came across a how-to guide that begins like this:

"There is a strong initial tendency of CentOS and RHEL users is to rely on RPMs for initial installation of new packages. For small or widely used packages this approach usually works OK. For complex and rarely used packaged you are often to nasty surprises. Typically you face "libraries hell" problem. Also some packagers are pretty perverted and add to the package additional dependencies or configure is is a completely bizarre way.  They are typically volunteers and nobody controls what they are doing.

As the result you can spend the amount of time that vastly exceed the amount of time and effort of compiling executables from the source.

There are RPMs fro Torque available from Fedora  ELEL repository but those RMS are fools gold: the current version for RHEL 6.x is broken due to SNAFU committed by maintainer.

As usually for semi-open source packages, installation and configuration documentation is almost non existent. This page might slightly compensate for that.

First you need to download the correct version of RPMs for installation of RHEL/CentOs 6.x. The one that works. The version that yum picks up from EPEL repository does not work. The package maintainer recklessly enabled NUMA memory and screwed the application, instead of creating a separate set of packages for NUMA-enabled Torque.  NUMA is not needed for typical Intel boxes. So this was a typical package maintainer perversion, for which users paid dearly.

Sh*t happens, especially with complex open source packages, which do not have adequate manpower for development, testing or packaging, but this was a real SNAFU that affected many naive users with real and pretty large clusters:"

Sounds like he was really pissed off.
Seems to be par for the course when such things are privatised, then a
public-domain version is forked off the old code.

[toc] | [next] | [standalone]


#54300

Fromgazelle@shell.xmission.com (Kenny McCormack)
Date2019-03-03 04:43 +0000
Message-ID<q5fm1a$htb$1@news.xmission.com>
In reply to#54299
In article <2cdd8213-460f-4594-a232-92582fb28953@googlegroups.com>,
Pedro Valdez  <pedro1492@lycos.com> wrote:
>I came across a how-to guide that begins like this:
>
>"There is a strong initial tendency of CentOS and RHEL users is to rely on RPMs
>for initial installation of new packages. For small or widely used packages this
>approach usually works OK. For complex and rarely used packaged you are often to
>nasty surprises. Typically you face "libraries hell" problem. Also some packagers
>are pretty perverted and add to the package additional dependencies or configure
>is is a completely bizarre way.  They are typically volunteers and nobody
>controls what they are doing.
>
>As the result you can spend the amount of time that vastly exceed the amount of
>time and effort of compiling executables from the source.
>
>There are RPMs fro Torque available from Fedora  ELEL repository but those RMS
>are fools gold: the current version for RHEL 6.x is broken due to SNAFU committed
>by maintainer.
>
>As usually for semi-open source packages, installation and configuration
>documentation is almost non existent. This page might slightly compensate for
>that.
>
>First you need to download the correct version of RPMs for installation of
>RHEL/CentOs 6.x. The one that works. The version that yum picks up from EPEL
>repository does not work. The package maintainer recklessly enabled NUMA memory
>and screwed the application, instead of creating a separate set of packages for
>NUMA-enabled Torque.  NUMA is not needed for typical Intel boxes. So this was a
>typical package maintainer perversion, for which users paid dearly.
>
>Sh*t happens, especially with complex open source packages, which do not have
>adequate manpower for development, testing or packaging, but this was a real
>SNAFU that affected many naive users with real and pretty large clusters:"
>
>Sounds like he was really pissed off.
>Seems to be par for the course when such things are privatised, then a
>public-domain version is forked off the old code.

I hear ya.

Much the same things can be said about "Synergy".

I use Synergy, and like it a lot, but it is clearly a mess - for the very
reason you describe - it went "commercial" and the free version ended up a
mess.

-- 
People sleep peaceably in their beds at night only because rough
men stand ready to do violence on their behalf.

    George Orwell

[toc] | [prev] | [next] | [standalone]


#54301

From"J.O. Aho" <user@example.net>
Date2019-03-03 10:07 +0100
Message-ID<ge1jpmF4hdpU1@mid.individual.net>
In reply to#54299
On 3/3/19 4:43 AM, Pedro Valdez wrote:

> "There is a strong initial tendency of CentOS and RHEL users is to rely
> on RPMs for initial installation of new packages. For small or widely
> used packages this approach usually works OK. For complex and rarely
> used packaged you are often to nasty surprises. Typically you face
> "libraries hell" problem. Also some packagers are pretty perverted and
> add to the package additional dependencies or configure is is a
> completely bizarre way.

This ain't something RPM specific, nor distribution specific, nor Linux 
specific.


> First you need to download the correct version of RPMs for installation
> of RHEL/CentOs 6.x. The one that works. The version that yum picks up
> from EPEL repository does not work.

Seems to be someone who don't know how to block RPMs, all you need is to 
install yum-plugin-versionlock


> Sh*t happens, especially with complex open source packages
>, which do not have adequate manpower for development, testing
> or packaging

He also missed that there is a SRPM which has the spec file, just 
disable NUMA and build the packages, install the new RPMs.


> Sounds like he was really pissed off.

I would have gone with a pissed off ms-noob.


> Seems to be par for the course when such things are privatised, then a
> public-domain version is forked off the old code.

You don't need source code to be closed down, it's enough that the 
maintainers adds stupid dependency like adding dependency to a specific 
init system for a desktop environment and suddenly the desktop 
environment is Linux only instead for all Unix running X11.

The ms-noob should maybe have looked at a meta-distribution, as then he 
could have had a lot more control on the packages that would be 
installed, what features are enabled and which not.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]


#54307

FromWilliam Unruh <unruh@invalid.ca>
Date2019-03-03 17:45 +0000
Message-ID<q5h3rc$v3u$1@dont-email.me>
In reply to#54299
On 2019-03-03, Pedro Valdez <pedro1492@lycos.com> wrote:
> I came across a how-to guide that begins like this:
>
> "There is a strong initial tendency of CentOS and RHEL users is to rely on RPMs for initial installation of new packages. For small or widely used packages this approach usually works OK. For complex and rarely used packaged you are often to nasty surprises. Typically you face "libraries hell" problem. Also some packagers are pretty perverted and add to the package additional dependencies or configure is is a completely bizarre way.  They are typically volunteers and nobody controls what they are doing.

With a good packaging system, it will find and install the dependencies
for you. Eg, urpmi on Mageai.

>
> As the result you can spend the amount of time that vastly exceed the amount of time and effort of compiling executables from the source.
>
> There are RPMs fro Torque available from Fedora  ELEL repository but those RMS are fools gold: the current version for RHEL 6.x is broken due to SNAFU committed by maintainer.
>
> As usually for semi-open source packages, installation and configuration documentation is almost non existent. This page might slightly compensate for that.

Semi open? They are open source. The rpm is open source. You can go in
and change it if you want. 

>
> First you need to download the correct version of RPMs for installation of RHEL/CentOs 6.x. The one that works. The version that yum picks up from EPEL repository does not work. The package maintainer recklessly enabled NUMA memory and screwed the application, instead of creating a separate set of packages for NUMA-enabled Torque.  NUMA is not needed for typical Intel boxes. So this was a typical package maintainer perversion, for which users paid dearly.

Of course you could become the maintainer instead.

>
> Sh*t happens, especially with complex open source packages, which do not have adequate manpower for development, testing or packaging, but this was a real SNAFU that affected many naive users with real and pretty large clusters:"

You mean it affected you. 


>
> Sounds like he was really pissed off.

And now you are imputing motives to him?

> Seems to be par for the course when such things are privatised, then a
> public-domain version is forked off the old code.

Privatized? How is it privatized?

>
>

[toc] | [prev] | [standalone]


Back to top | Article view | alt.os.linux


csiph-web