Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.linux > #54299 > unrolled thread
| Started by | Pedro Valdez <pedro1492@lycos.com> |
|---|---|
| First post | 2019-03-02 19:43 -0800 |
| Last post | 2019-03-03 17:45 +0000 |
| Articles | 4 — 4 participants |
Back to article view | Back to alt.os.linux
"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
| From | Pedro Valdez <pedro1492@lycos.com> |
|---|---|
| Date | 2019-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]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-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]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2019-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]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2019-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