On Sat, Jul 23, 2011 at 8:58 PM, Thomas Dukes tdukes@sc.rr.com wrote:

Red Hat does not support upgrades between major versions (doesn't necessarily mean it's not possible) http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installati... http://linsec.ca/blog/2011/02/23/my-adventure-upgrading-rhel5-to-rhel6/

Since when?? I started with slackware 1.0 on a pentinum 1 system from VaResearch back in the mid 90's, change to Redat 2.0, then Fedora, then to Whitebox, then CentOS.. Never had a problem upgrading on an rpm based system.

That's a good question. It seems that since RHEL 4 (2005), Red Hat has been telling us that upgrading from earlier major versions is not a good idea.

- RHEL 3 docs say it's possible to upgrade from 2.1 to 3.x (http://goo.gl/8Gwrs) - RHEL 4 docs don't bother showing the steps and provide a lot of warnings for 2.x/3.x to 4.x (http://goo.gl/yiRGK) - RHEL 5 docs explicitly say Red Hat does not support upgrading from earlier major versions (http://goo.gl/RQABB) - RHEL 6 docs explicitly say Red Hat does not support upgrading from earlier major versions (http://goo.gl/H9zBU)

I don't think RPM is the one allowing/disallowing the upgrade between major versions. The kernel architecture and other major components changes are more likely to be the culprit. I'd be surprised how you moved from Slackware 1.0 all the way to CentOS without a reinstall (because that's what is being discussed here).

Just as reference, starting with Solaris 11, it'll not be possible to upgrade from earlier major versions either (although binary compatibility will still be there). Oracle is asking customers to treat earlier versions as legacy and put them in containers and/or virtual machines. Solaris 11 will change so much how things work that Oracle says it's better not to bother upgrading path from Solaris 10.

My point is that big changes happen in Linux much frequently than in Solaris and even Solaris sometimes doesn't support these kinds of upgrades.

-- Giovanni Tirloni

Am 24.07.2011 14:04, schrieb Always Learning:

On Sun, 2011-07-24 at 08:30 -0300, Giovanni Tirloni wrote:

...

My point is that big changes happen in Linux much frequently than in Solaris and even Solaris sometimes doesn't support these kinds of upgrades.

It is the inevitable and time-consuming upheaval which many will probably find daunting. Installing Centos then configuring it for a specific manner of operation can take several hours.

When I recently re-installed C 5.6 as a server/desktop, the configuration took 4 to 5 hours to complete. I didn't use kickstart.

People love and appreciate Centos. They sometimes shudder at the implication of effectively a re-installation, re-configuration and a translation of perfectly good reliable working applications into unfamiliar compulsory alternatives. Get something wrong and the time and effort increases and competes with the daily priorities of running a smooth computer operation and responding to all the things that do occur.

The challenge is how to do an easily transition from one major version to its successor version with the least physical, emotional, intellectual and time-consuming effort.

Paul,

as much as I understand your point of view, I must disagree taking upstream's and CentOS's position. Your description reflects a home user or an administrator with just less than a handful of systems.

CentOS and RHEL aims for the enterprise use. Of course that does not imply people can not rely on this stable platform in very small environments, but that's not the focus of the OS design. And speaking about the enterprise scenario, no serious administrator will risk the proper function of his install base by going risky paths. Typically the OS is just the base for the middleware and application level. Switching to a new major level of OS with lots of important changes means, the administrator will have to test and adjust his setup of OS and application use in multiple aspects. This even applies to applications the base OS ships with.

In enterprise environments, where the CentOS systems are more than a simple shell box or a trivial webserver, it is more time consuming to find all the possible places to adjust the obsolete configurations being transferred by an upgrade and to find the tripping points than to run a clean and fresh installation with a defined state. In less trivial setups the applications even get wrecked because of library changes and such.

Regards

Alexander

Am 24.07.2011 14:04, schrieb Always Learning:

...

The challenge is how to do an easily transition from one major version to its successor version with the least physical, emotional, intellectual and time-consuming effort.

Paul,

as much as I understand your point of view, I must disagree taking upstream's and CentOS's position. Your description reflects a home user or an administrator with just less than a handful of systems.

CentOS and RHEL aims for the enterprise use. Of course that does not imply people can not rely on this stable platform in very small environments, but that's not the focus of the OS design. And speaking about the enterprise scenario, no serious administrator will risk the proper function of his install base by going risky paths. Typically the OS is just the base for the middleware and application level. Switching to a new major level of OS with lots of important changes means, the administrator will have to test and adjust his setup of OS and application use in multiple aspects. This even applies to applications the base OS ships with.

In enterprise environments, where the CentOS systems are more than a simple shell box or a trivial webserver, it is more time consuming to find all the possible places to adjust the obsolete configurations being transferred by an upgrade and to find the tripping points than to run a clean and fresh installation with a defined state. In less trivial setups the applications even get wrecked because of library changes and such.

I am a sysadmin for an enterprise running both RHEL and AIX...both of them being enterprise level OSes.

IBM has managed to support in place upgrading of their OSes from one major version to another for several versions, now...in fact, each release is, according to IBM, a separate release, with technical levels or maintenance levels and service packs being in-level patches.

So, going from 5.3 TL6 SP6 to 5.3 TL12 is as considered patching and is as simple as running "smitty update_all" from within an appropriately configured repository directory (or directories), much like running "yum update".

On the other hand, going from 5.1 anything to 5.2 anything, 5.2 to 5.3, 5.3 to 6.1 is considered a major release...and upgrading those, in place, is fully supported by IBM, and is as simple as either booting from an appropriate boot disk, or using the appropriately configured NIM boot and install/up process.

If IBM can make this happen for their OS, and Red Hat certainly supports such a process in the Fedora line of releases (including the ability to list additional repositories for remote installation as part of the process), they could certainly make it a supportable option for the RHEL line.

On Tue, 26 Jul 2011, Mike Burger wrote:

...

If IBM can make this happen for their OS, and Red Hat certainly supports such a process in the Fedora line of releases (including the ability to list additional repositories for remote installation as part of the process), they could certainly make it a supportable option for the RHEL line.

The upstream supports nothing as to Fedora, and indeed, members of that project regularly (and seem to gleefully) break forward compatability

I can not believe that the upstream does not guide/provide direction with regard to the Fedora project, given that the Fedora project is still the test bed for what eventually goes into the upstream's commercially supported product.

But you are missing the point -- WHY spend the engineering effort on trying to support such Major 'upgradeany's? A new deployment takes mere minutes for a commercial shop, and by NOT supporting such explicitly, the upstream avoids much support and engineering load.

Quite simply, because the customer base, which is paying the upstream for support, is requesting that such a process be supported.

Quite simply, as well, because the upstream is selling the customer on the idea that their product is an enterprise level product. Other enterprise level *NIX providers support this process...the customer may reasonably expect that this provider do the same.

Sure...it may take only a few minutes for a commercial shop to deploy an OS, it takes that shop much more time to have to reinstall and reconfigure the applications that run on those OS instances, test, cut over, etc.

Additionally, not every shop is running their entire Linux infrastructure in a VM based environment. For those running physical systems, the hardware may still be within their viable hardware lifecycle, but be in need of a newer version of the OS. Should the customer have to purchase an additional physical system for each instance of their OS that must be upgraded from one major release to the next? Where would that leave the customer, as far as having been sold on the cost effectiveness of their Linux installs vs other commercial *NIX offerings?

How about those virtualized environments? Spinning up a new VM environment to eventually replace the existing VM with a new OS instance may also require the purchase of additional hardware, in an effort to support the temporary resources needed to spin up, configure and test the new instances prior to putting them into live use.

The cost of testing and then supporting live upgrade scenarios, born by the upstream, would likely be less than the cost to the customer base in potential hardware and manpower cycles, and would undoubtedly build the upstream more good will from the customer base.

Consider, again, that the feature to perform an upgrade (and not via a hidden upgradeany command line option) is available in the version of Anaconda (the installation tool used by the upstream) that is in use for Fedora intallations and upgrades, and that particular compilation of Anaconda does include the ability to specify those third party repositories from which one may have installed packages. It may be compiled out of the binary that is in use by the upstream, but any of us who have also used their test environment know that it's there, and are more than aware that the upstream has and continues to disable certain features of various included tools when shipping those tools in their commercially supported distribution.

On 07/26/2011 02:07 PM, Mike Burger wrote:

...

But you are missing the point -- WHY spend the engineering effort on trying to support such Major 'upgradeany's? A new deployment takes mere minutes for a commercial shop, and by NOT supporting such explicitly, the upstream avoids much support and engineering load.

Quite simply, because the customer base, which is paying the upstream for support, is requesting that such a process be supported.

And this would be a sensible argument, were it not being made on the CentOS list. Folks here aren't paying anyone anything.

This is more like an extension of the Fedora community, in a way -- free testers and freeloaders. Big deal. Red Hat doesn't *need* to do anything for us, come to think of it they're already doing quite a bit, so I see no point in complaining.

-Iwao

On 07/26/2011 01:32 PM, R P Herrold wrote:

On Tue, 26 Jul 2011, Mike Burger wrote:

...

If IBM can make this happen for their OS, and Red Hat certainly supports such a process in the Fedora line of releases (including the ability to list additional repositories for remote installation as part of the process), they could certainly make it a supportable option for the RHEL line.

The upstream supports nothing as to Fedora, and indeed, members of that project regularly (and seem to gleefully) break forward compatability

But you are missing the point -- WHY spend the engineering effort on trying to support such Major 'upgradeany's? A new deployment takes mere minutes for a commercial shop, and by NOT supporting such explicitly, the upstream avoids much support and engineering load.

[I say this having done an 'upgradeany' and run into a later 'nss' in C5 than the C6 initial media provides, that required some head scratching, and a nasty workaround, to solve over the weekend]

RPH is definitely right about "gleefully breaking forward compatibility".

It is easier to control compatibility backward and forward when you're deploying a closed (or at least tightly controlled) system as opposed to one that boils with change the way the Fedora upstream does.

Example: systemd

Find a way to make a transition from 6x to 7.0 seamless by way of a simple "yum update" once SysV init goes away and all system services must grow configuration files and drop init scripts. That's just one subsystem, there are other huge changes as well (Gnome3...).

IBM and the tightly controlled (and decades long) OS/360 -> z/OS process or their linear passes through AIX Ver.n -> Ver.n+i do not compare to Red Hat's situation. Anyway, compatibility is often complex enough for IBM to address by quietly including emulators for their previous systems instead of shooting for base compatibility.

The key to Red Hat's success has been its hands-off approach to the Fedora Project. If Red Hat ever desires to implement something they must first present working implementations for acceptance by FESCo -- which implies promising, working implementations. This forces a lot of unique situations, but the primary effects are: * Advances occur at a rate difficult to compare to other projects * Entire subsystems can be marked "obsolete" if a working implementation demonstrates superior function (systemd ousting the venerated SysV init is an example of this "nothing sacred" attitude) * Technical debate about anything/everything crosses company, private and personal lines in ways difficult to interpret from a traditional development perspective * The chaos level is high (marked by the inability for any one person to be an expert on everything at a given time -- by the time one thing is thoroughly understood something else has changed) * Absolute forward and backward compatibility requires too much effort, so the concept of "compatibility" moves up two levels to the data layer[1]

IBM, on the other hand, has a long-term compatibility program they consider to be at the core of their business model (System/360 history is interesting here). They plan their changes around a few subsystems they consider to be sacred. If you want to change something sacred you have to plan it out through the high priest in charge of that subsystem -- and it is acceptable for major system changes to take several years.

The whole thought process is entirely different -- as are their target markets. Red Hat is a good value for large- to huge-sized businesses, and IBM is a better value (sometimes with a mix of Red Hat in some areas/departments) for titanic- to ZOMG-sized businesses.

I apologize for the long message. I didn't have time to write a short one.

-Iwao

[1] I've been thinking about this a bit and I've come to think that there are roughly three layers to compatibility -- so I'll define them here since I referenced my own definition:

1- Absolute forward and backward compatibility. Code builds and runs in exactly the same way on any system in the series.

This is the level IBM shoots for. System upgrades and downgrades are clean, reliable and easy to recommend and support.

In Linux terms this would mean you could load, say, RHEL 3 and "yum upgrade" to RHEL 6.1 -- whether that is through a yum-initiated upgrade chain or a one-step upgrade is of no concern to the user.

2- Configuration compatibility. Implementations change in radical ways, but the interpretation, format and semantics of configuration files is absolutely respected between versions and often between competing implementations of a single standard. OpenLDAP's move to cn=config while retaining the ability for slapd.conf to be read and converted to a cn=config loadable set of LDIFs is an example of this.

This is roughly what Microsoft used to aim for (somewhere on the road between XP and 8 they seem to have totally quit the idea, though).

In Linux terms this would mean you can copy things like /etc, /var and /home/~/.* and add the contents to whatever new is in the upgrade and not endure any major shocks.

3- User data compatibility. Config files might change, because entire subsystems might evaporate or be replaced. Converting between radically different concepts (Gnome 2 to 3 with gconf to dconf, for example) means that finding enough logical parallels to define a user/upgrade friendly automatic conversion tool is at least as difficult as developing the replacement system was in the first place -- and therefore an unrewarding level of effort. User data, on the other hand -- being the actual media, business files, whatever, are considered sacred, however, and the system must be able to support loading the old media onto the new system. Universal support for ODF, import support of database dumps between PostgreSQL versions or MySQL to MariaDB, universal image formats, JwCAD .jww export to .dxf and import to LibreCAD, mbox, etc. are examples of this level.

This seems to be what Red Hat considers acceptable.

In Linux terms this means that you should be able to copy /home without the dotfiles and a lot of /var (or /var-type things, depending on how you're set up) and not be surprised by the result.

On 7/26/2011 9:03 AM, Lamar Owen wrote:

I'm sure that some of these major upgrades *can* be done, but in a land where the package is the unit of OS granularity, and package maintenance practices vary from package to package as to 'upgradeableness,' it really becomes a task, and this is before even considering the upgrade-hostile attitudes of some software projects that upstream ships packaged in upstream EL.

Keep in mind that the Linux kernel itself makes no concessions to backwards compatibility and demands that all related modules be recompiled to match changes. Enterprise distributions have their hands full just trying to keep things working within the life of a major rev and are generally restricted in how much new development can be added without major breakage.

Other OS kernels have more reason to maintain backwards binary compatibly (i.e. paying customers that demand it...).

On 7/26/2011 10:18 AM, Lamar Owen wrote:

...

Keep in mind that the Linux kernel itself makes no concessions to backwards compatibility and demands that all related modules be recompiled to match changes.

One of my paragraphs originally included a fairly lengthy passage on kernel ABI compatibility, but I trimmed it out, and I 'genericized' to more than just the one project, and put in parentheses the statement 'partly to prevent closed-source programs from continuing to work' as a more generic thing, more than just binary kernel modules.

It's most assuredly not just the kernel.

Yes, its only a slight over-generalization to say that free projects have no obligation to existing customers and they usually prefer 'new and different' development to boring backward compatible support work.

Even though RHEL isn't a free project, there's only so much they can do to reconcile the wild changes in the code they include.

When I say non-rpm, I mean source packages I compiled such as zoneminder.

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of R P Herrold Sent: Saturday, July 23, 2011 7:36 PM To: CentOS mailing list Subject: [CentOS] Upgrading from CentOS 5.6 to 6.0

On Sat, 23 Jul 2011, Thomas Dukes wrote:

...

I use to be able to upgrade by doing a 'yum update'. That

doesn't work

...

either.

A low skill user was never able to go from 2.1 to 3, nor 3 to 4, nor 4 to 5, and an a minimally skilled will not be able to go from 5 to 6. This is the policy of the upstream, and a sensible one, because of invasive changes each major release represents. Functionally, each major is a new product.

That said, the CentOS wiki has an UNSUPPORTED method for media based 'upgradeany' transitions of the type you mention. It IS UNSUPPORTED, because it can break systems. For that reason, I specifically added warnings to that article, to take and test backups before trying that path

...

Guess I'm stuck with 5.6 as I an not about to install a new version and have to rebuild all non-rpm packages from scratch. This

is worse than Microsoft!!

Much worse -- you could not steal binaries and license keys from CentOS because we give them away for free

CentOS ships no non-RPM packaged packages -- look to whoever put those packages on your box without using the packaging system if you feel the need to blame someone

-- Russ herrold _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Saturday, July 23, 2011 10:25:56 PM Alexander Dalloz wrote:

Am 24.07.2011 02:00, schrieb Thomas Dukes:

...

When I say non-rpm, I mean source packages I compiled such as zoneminder.

And even *if* you would be able to upgrade from CentOS 5.x to 6 - technically and by personal skills - what makes you think that your self compiled software would not completely fail, just because libraries change?

The specific example of zoneminder is particularly insidious. On our zoneminder systems, even point updates to certain libraries has created problems. A good, modern, package of zoneminder in a repo somewhere would save a lot of grief in that particular case.

And even having maintained packages before, I'm not sure I would want to touch rolling my own zoneminder package(s).

On Monday, July 25, 2011 11:22:37 AM R P Herrold wrote:

1.24 looks 'doable', although perhaps not without some C6 libraries -- I see it in rawhide, and in F, after F13, as I recall

I managed to get 1.24.x (VM is shut down right now due to VMware update 'things' going on, so can't check specific version) running, but it wasn't pleasant, and required very specific versions of things to get it working on CentOS 5. It does work, but it is touchy if any of its dependencies gets updated. And now there is a newer version than the one I have running.....

And the SELinux business is still there (or rather, not there) and that complicates things. This seems to be more true with network cameras than with native v4l devices.

With the library version in C6 being more close to what ZM wants, it should be easier to make it work with C6. Haven't tried out C6 on our VMware setup yet; it's ESX 3.5U5, and AFAIK EL6 isn't supported on ESX3.5. But I'm still digging into that, and seeing if vSphere 4 vmware-tools from packages.vmware.com will work on ESX3.5.

If ZM just wasn't the most useful CCTV webcam software out there, bar none, I'd probably not even bother. I haven't found anything even close to ZM in terms of functionality in the open-source realm.

On Sat, July 23, 2011 19:36, R P Herrold wrote:

On Sat, 23 Jul 2011, Thomas Dukes wrote:

...

I use to be able to upgrade by doing a 'yum update'. That doesn't work either.

CentOS ships no non-RPM packaged packages -- look to whoever put those packages on your box without using the packaging system if you feel the need to blame someone

If that person just happens to be oneself then I suggest that you use "checkinstall" in the future so avoid the pain of dealing with custom installed software outside the rpm/yum package manager

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Lanny Marcus Sent: Sunday, July 24, 2011 8:51 PM To: CentOS mailing list Subject: Re: [CentOS] Upgrading from CentOS 5.6 to 6.0

On Sat, Jul 23, 2011 at 5:41 PM, Thomas Dukes tdukes@sc.rr.com wrote:

...

Just ran the installation DVD but there is no option to 'upgrade'. Looked at the RHEL docs,

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Inst

...

allati on_Guide/ch-guimode-x86.html#id4594292 referenced off the CentOS Release notes but the CentOS installation doesn't offer the

'upgrade'.

...

I use to be able to upgrade by doing a 'yum update'. That

doesn't work

...

either.

Guess I'm stuck with 5.6 as I an not about to install a new version and have to rebuild all non-rpm packages from scratch. This

is worse than Microsoft!!

@Thomas: I'm a "newbie" home user, with CentOS on our Desktops, and Red Hat Linux, before that.

I do not believe you understand the philosophy behind CentOS (an Enterprise OS) or RHEL (the upstream distro). This is a distro with a *LONG* life, and without the "latest and greatest", for security and stability reasons.

It has always been recommended to do a "Clean Install" when moving from one major version (ie: 5.x) to a newer version (ie: 6.x) and then to Restore your data, from your backup.

If you do it in some other fashion, there are apt to be problems, which will probably not be supported on this list. If you break it, you will fix it.

There is a lot of information available, on CentOS.org in the Wiki. HowTos, FAQs, etc. If you look there, you will find many things explained clearly.

Also, if you search the archives of the mailing list, you will find a ton of information, from a large group of highly knowledgeable users. People who work with CentOS in the Enterprise, all day, every day.

Installing non RPM software on an RPM Distro like CentOS is frowned upon. That is the worst way to do it. There are 3rd party Yum repositories, with lots of things that have been packaged for CentOS and you can install them with Yum, once you have the Repository data ready for yum. You probably won't need to rebuild many packages, if any, if you use the 3rd party repositories. GL

I have never had a problem upgrading a CentOS release since I started with 3.x. Seems now, I can't even upgrade from 5.6 to 5.7. I have never had to do a complete re-install since moving from Slackware 1.x to Redhat 2.x except once when I had a hard drive failure.

I'll be moving to Ubunto. They have a 3 year window for support on a distribution unlike CentOS/RHEL. They seem to be more user friendly for a home networking environment.

The software package I use which takes hours of trial and error to compile and install is as simple apt-get install under Ubunto. There are no rpms for zoneminder 1.24.x. The compliation of ffmpeg/zoneminder seems to be an issue with CentOS with the outdated php/mysql and other various libs.

I can see the direction RHEL is taking and its more and more like Microsoft. The enduser is having to be more and more dependent on the provider. CentOS has its hands tied.

I thank all for the help I have recievied over the years, its just not beneficial to stay this current direction.

TE Dukes

On Sun, 2011-07-24 at 22:20 -0400, Thomas Dukes wrote:

The compliation of ffmpeg/zoneminder seems to be an issue with CentOS with the outdated php/mysql and other various libs.

PHP and MySQL work fine for me. My systems depend on both these being reliable, efficient, dependable and robust - they are on Centos 5.6.

I can see the direction RHEL is taking and its more and more like Microsoft.

While Centos (and SL) exist, we are never going to be like M$. RH needs, commercially, to prevent/reduce business losses to copy-cat companies like Oracle etc.

The enduser is having to be more and more dependent on the provider. CentOS has its hands tied.

Yes all Centos users are dependent on RH if they want to run a 100% binary compatible system. However there is flexibility to add non-standard software and, as you have proved, one's own non-standard applications successfully.

Good Luck. We will be here if you pop back sometime in the future.

I'll be moving to Ubunto. They have a 3 year window for support on a distribution unlike CentOS/RHEL. They seem to be more user friendly for a home networking environment.

RHEL is supported for 10 years on each major release.

-- Eero

On Mon, Jul 25, 2011 at 07:33:41AM -0400, Thomas Dukes wrote:

Huh??

RHEL/CentOS are supported 7 years from date of release to EOL date. RHEL has an optional extended support plan that you can purchase if you are a RHEL subscriber; CentOS does not offer this extended support as upstream does not make the update source RPMs available for download unless you are a paying customer.

John

On Sun, 2011-07-24 at 19:51 -0500, Lanny Marcus wrote:

Installing non RPM software on an RPM Distro like CentOS is frowned upon. That is the worst way to do it.

---- why?

you made a vacuous argument.

Craig

On Mon, 2011-07-25 at 10:05 -0400, R P Herrold wrote:

On Sun, 24 Jul 2011, Craig White wrote:

...

you made a vacuous argument.

Hunh. You are ** still ** trolling here [arguing against package management] and on this thread [C 6 matters], Craig?

I thot back on June 13 you said here:

...

easier just to give up - I moved my new servers to ubuntu - no more new CentOS installs any more

---- still running some CentOS 5 servers... what's your point?

Craig

On 07/25/2011 06:07 PM, Lanny Marcus wrote:

On Sun, Jul 24, 2011 at 10:52 PM, Craig Whitecraigwhite@azapple.com wrote:

...

On Sun, 2011-07-24 at 19:51 -0500, Lanny Marcus wrote:

...

Installing non RPM software on an RPM Distro like CentOS is frowned upon. That is the worst way to do it.

---

why?

you made a vacuous argument.

@Craig: I retract that. Probably something that is discouraged, rather than frowned upon Lanny

In the RHEL environments where I have worked, installing non RPM software was more than frowned upon. It was strictly forbidden and cause for immediate public flogging. If someone could not (or did not want to) understand why installing non RPM software was a bad idea then that person would have been removed from his duties.

It's like using imperial units or US customary units (so non-metric) in Satellite design. It's just not an option. And if you insist then you can use it but it will be in your own basement and not at a vendor creating a Satellite.

Regards, Patrick

On Mon, 25 Jul 2011, Les Mikesell wrote:

On 7/25/2011 11:37 AM, Patrick Lists wrote:

...

...

...

...

Installing non RPM software on an RPM Distro like CentOS is frowned upon. That is the worst way to do it.

else has already done it. That is, building an RPM is always more work than doing a source install and often imposes inconvenient restraints like only permitting a single version to be running at once, and doesn't give you any guarantee that you won't have to repeat that extra work when the distribution changes. If you aren't planning to repeat that install on other machines, where's the payback for the extra work and constraints?

The rant at the start of this thread was about a migration into C6, so of course, your predicate condition: 'you aren't planning to repeat that install' does not apply

The disciplne and benefit of identifying and solving dependencies in a packaged system, rather than splatting as root over system libraries upon which other packages depend [also, the same isue using CPAN shell to 'solve' a problem, rather than packaging, as ZM has many such [1]] is obvious, and needs no further advocacy, even for a single install; the 'straw man' about setting different private library paths assumes that the person building such even comprehends that there is an issue in play. Not likely

-- Russ herrold

[1] [herrold@centos-5 zoneminder]$ ls -1 | grep ^per | wc 37 37 1354

On 07/25/2011 07:26 PM, Les Mikesell wrote: [snip]

My condition in that case was that you couldn't count on the RPM to work anyway once the distribution changes. So you'll likely be repeating that extra effort anyway.

Not sure what you mean with "once the distribution changes" but within a major CentOS/RHEL version (e.g. 5 or 6) there is a stable ABI so an update to the distro should not introduce issues. In my experience apps deployed on RHEL 5.1 work equally on 5.7. If they work crappy, hire better developers :)

And of course your next install may be on a non-RPM based system, making any rpm-packaging effort moot.

So do people in the Windows world decide to *not* build msi packages because their PHB might decide to replace all Windows with RHEL/CentOS? I have never seen that (the not building msi packages that is). And neither the reverse. I build versioned packages so (amongst other things) I can create a controlled and predictable environment. Are you going to install from source on thousands of servers or do you push *one* tested rpm? I know what I will be doing. Anything else just does not make sense to me.

Regards, Patrick

On 07/25/2011 10:49 PM, Les Mikesell wrote:

The context for the issue was someone moving from 5.x to 6.x.

Still normal procedures apply: port to the new platform and/or rebuild for the new platform, test on the new platform, rinse & repeat, verify, give seal of approval, package and finally deploy the RPM(s).

...

So do people in the Windows world decide to *not* build msi packages because their PHB might decide to replace all Windows with RHEL/CentOS?

But wouldn't it be better if they actually did that instead of locking themselves into a single vendors system?

Really? No. I wish you good luck with the DLL hell caused by your non-versioned, non-packaged, non-controllable, non-manageable source install on a few thousand servers. You don't get freedom or not-being-locked-in from not using best practices like versioned packaging. The choice for a certain platform was made. Deal with it.

...

I have never seen that (the not building msi packages that is). And neither the reverse.

How do you deal with java apps in cross platform environments?

RHEL5 life cycle ends on 31/03/2017 so for now I don't.

Regards, Patrick