FAQ
Help!

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/Installati
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!!

Search Discussions

  • Giovanni Tirloni at Jul 23, 2011 at 6:53 pm

    On Sat, Jul 23, 2011 at 7:41 PM, Thomas Dukes wrote:

    Help!

    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/Installati
    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!!
    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/Installation_Guide/ch-upgrade-x86.html
    http://linsec.ca/blog/2011/02/23/my-adventure-upgrading-rhel5-to-rhel6/

    Microsoft Windows and Red Hat Linux have a very different release strategies
    and version numbers. You can read more about the support lifecycle here:
    https://access.redhat.com/support/policy/updates/errata/

    --
    Giovanni Tirloni
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110723/673efa75/attachment.html
  • Thomas Dukes at Jul 23, 2011 at 7:58 pm
    _____

    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf
    Of Giovanni Tirloni
    Sent: Saturday, July 23, 2011 6:54 PM
    To: CentOS mailing list
    Subject: Re: [CentOS] Upgrading from CentOS 5.6 to 6.0


    On Sat, Jul 23, 2011 at 7:41 PM, Thomas Dukes wrote:


    Help!

    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/Installati
    <http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installat
    i%0Aon_Guide/ch-guimode-x86.html#id4594292>
    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!!



    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
    on_Guide/ch-upgrade-x86.html
    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.

    Microsoft Windows and Red Hat Linux have a very different release strategies
    and version numbers. You can read more about the support lifecycle here:
    https://access.redhat.com/support/policy/updates/errata/

    --
    Giovanni Tirloni


    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110723/f3313d62/attachment.html
  • Giovanni Tirloni at Jul 24, 2011 at 7:30 am

    On Sat, Jul 23, 2011 at 8:58 PM, Thomas Dukes 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/Installation_Guide/ch-upgrade-x86.html
    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
  • Always Learning at Jul 24, 2011 at 8:04 am

    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.


    --
    With best regards,

    Paul.
    England,
    EU.
  • Alexander Dalloz at Jul 24, 2011 at 9:59 am

    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
  • Always Learning at Jul 24, 2011 at 3:40 pm

    On Sun, 2011-07-24 at 15:59 +0200, Alexander Dalloz wrote:


    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.
    Alexander,

    I have 11 servers all running C 5.6 and will stay on 5.x while
    everything works satisfactorily. For development and experimentation I
    use 2 desktops, laptop and notebook running C 5.6 as a server/client
    (server/normal user). The 6.x kernel offers me new development
    possibilities.
    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.
    The operating system comprises several parts. The kernel, Red Hat's
    versions of various semi-system/application software, the extras like
    clustering and kvm. The focus of the design is to provide a very stable
    base upon which many different additions will successfully operate and
    co-exist.

    Red Hat provide one basic version of their RHEL which can be used both
    as a server and as a client (meaning 'normal user' environment). You may
    have noticed RH's endorsement of Gnome. RHEL is an enterprise operating
    system but enterprise, in the commercial understanding of the word,
    means more than a server farm or racks in a data centre. It means the
    entire corporation - servers and end-users. From the payroll system to
    the chief executive officer's desk. RHEL does all these different tasks
    admirably well.
    And speaking
    about the enterprise scenario, no serious administrator will risk the
    proper function of his install base by going risky paths.
    Is 'risky path' someone wanting to easily upgrade/convert from 5.x to 6.x ?
    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.
    The large? jump from 5.x to 6.x and the resulting pressure on people to
    find the problems and solve them is, obviously, time consuming and for
    some demanding.

    If some (certainly not 'all') of the 'new' 6.x
    systems/changes/improvements were available in 5.x, people could
    gradually learn about them including any changes. This pre-knowledge
    spread over a year, would make major version transitions easier and
    quicker. I acknowledge this is not a Centos issue but a Red Hat policy.
    A solution is to experiment with the relevant Fedora versions.
    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
    Hopefully each application has just one configuration file in one known
    location. Keeping a set-up simple and ensuring up-to-date documentation
    should avoid 'obsolete configurations' existing and 'tripping points'
    occurring.


    --
    With best regards,

    Paul.
    England,
    EU.
  • Mike Burger at Jul 26, 2011 at 12:14 am

    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.
    --
    Mike Burger
    http://www.bubbanfriends.org

    Visit the Dog Pound II BBS
    telnet://dogpound2.citadel.org or http://dogpound2.citadel.org

    To be notified of updates to the web site, visit:

    https://www.bubbanfriends.org/mailman/listinfo/site-update

    or send a blank email message to:

    site-update-subscribe at bubbanfriends.org
  • R P Herrold at Jul 26, 2011 at 12:32 am

    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]

    -- Russ herrold
  • Mike Burger at Jul 26, 2011 at 1:07 am

    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.

    --
    Mike Burger
    http://www.bubbanfriends.org

    Visit the Dog Pound II BBS
    telnet://dogpound2.citadel.org or http://dogpound2.citadel.org

    To be notified of updates to the web site, visit:

    https://www.bubbanfriends.org/mailman/listinfo/site-update

    or send a blank email message to:

    site-update-subscribe at bubbanfriends.org
  • Stephen Harris at Jul 26, 2011 at 1:20 am

    On Tue, Jul 26, 2011 at 01:07:36AM -0400, Mike Burger wrote:
    On Tue, 26 Jul 2011, 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.
    If there's sufficient customer demand _and_ if RH decide it's worth it
    then they might support it. However I can tell you that the 20,000+ RH
    machines at my place will not be major-version upgraded in-place; they'll
    be rebuilt (possibly onto new hardware; maybe onto a split-mirror).
    That's how we do Linux; that's how we do Solaris; heck, that's even how
    we do AIX.

    Our support dollars are pushing RedHat in a different direction. We don't
    care about in-place major-version upgrades.

    --

    rgds
    Stephen
  • 夜神 岩男 at Jul 26, 2011 at 1:57 am

    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
  • Jim Wildman at Jul 26, 2011 at 9:08 am
    Several points (all for "enterprises I've worked at")
    1) Folks tend to hold onto hardware WAY past the expiration date. We
    still have SunFire v1xx boxes alive and some x86 boxes that aren't 64
    bit capable. If they want the latest OS, buy new hardware.
    2) I've never seen an OS upgraded across major releases under an
    existing app (other than a web server). Generally it is the other way.
    The app guys want to run the new version, which requires the new OS, which
    requires new hardware, which requires a full recert.
    3) Just because IBM can do it on mainframes and Power/AIX boxes, doesn't
    mean you can do it on x86 hardware. Or should even try.
    4) As others have noted, comparing RHEL to Fedora is not valid.
    On Tue, 26 Jul 2011, Mike Burger 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.
    ----------------------------------------------------------------------
    Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.net
    "Society in every state is a blessing, but Government, even in its best
    state, is a necessary evil; in its worst state, an intolerable one."
    Thomas Paine
  • 夜神 岩男 at Jul 26, 2011 at 1:51 am

    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.
  • Lamar Owen at Jul 26, 2011 at 10:03 am

    On Tuesday, July 26, 2011 01:51:18 AM ????? wrote:
    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).
    As a slightly off-topic aside, there is a youtube video out there about doing just that; the video shows an upgrade chain that goes from Windows 1.0 (no, that's not a typo) up through Windows 7, all as upgrades, along with all the things that have to be changed along the way.... some of the text the guy enters in textboxes is NSFW, however. So you'll have to google for it yourselves; it made Slashdot a few weeks back, so it shouldn't be hard to find.

    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.

    While package groups give an illusion of a unit larger than a package, it's just an illusion, really. The collective set of dependencies defines the full distribution, and nothing in the dependency chain requires rigorous, tested, upgrade path implementation.

    In the case of other commercial vendors doing this, well, those vendors typically have strict and tight control over all the developers working on it, and have enforcement mechanisms in place to ensure that migration paths are implemented. It's called an employment contract, and it's enforced through the ordinary commercial developer chain of command.

    While open source developers and packagers are technically capable of doing this, some seem to take great delight in making it difficult to be compatible (partly to prevent closed-source programs from continuing to work). And if just one development group becomes the proverbial fly in the ointment, then all the users of that package that need upgrades to 'just work' suffer. And sometimes the developers care, and sometimes they don't.

    But consider: upstream doesn't employ a 'critical mass' of developers in all of its shipped packages to reliably enforce upgrade provisions, even if it wanted to do so.

    Beyond that, there are packages supported by upstream that have serious difficulties with major version upgrades, simply because supporting data in place upgrades is not a priority for that development group. I can think of more than one project that seems 'upgrade hostile' but in reality it's just something that's not front burner; they'd rather develop newer features and fix bugs than 'waste' time on a rarely used procedure that is, in some cases, extremely complex and in other cases simply won't work anyway. That is, there are data sets associated with some upstream packages that are impossible to migrate in place to a newer version in a seamless, nondisruptive, fashion.

    In a nutshell, it becomes a tradeoff of open source freedom versus the upgrade needs of the users. If the needs of the users trump the freedom of the developers, then developer freedom (the freedom to 'scratch ones own itch'), the very essence of open source, goes out the window.

    To the OP, if your itch is to have seamless in-place upgrades, then scratch that itch (or pay someone what scratching that itch is really worth... but be prepared to come up with six or seven figures). That's going to be a mighty big itch, though..... especially with over 2,500 upstream packages from nearly as many heterogeneous development groups with many more agendas of their own.
  • Les Mikesell at Jul 26, 2011 at 10:45 am

    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...).

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Lamar Owen at Jul 26, 2011 at 11:18 am

    On Tuesday, July 26, 2011 10:45:42 AM Les Mikesell 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.
  • Les Mikesell at Jul 26, 2011 at 11:29 am

    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.


    --
    Les Mikesell
    lesmikesell at gmail.com
  • R P Herrold at Jul 23, 2011 at 7:36 pm

    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
  • Thomas Dukes at Jul 23, 2011 at 8:00 pm
    When I say non-rpm, I mean source packages I compiled such as zoneminder.
    -----Original Message-----
    From: centos-bounces at centos.org
    [mailto:centos-bounces at 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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Alexander Dalloz at Jul 23, 2011 at 10:25 pm

    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?

    If you would have gone the proper way by using rpms, or where not
    available by building your own rpms, things would be no drama for you
    when doing a fresh install of CentOS 6, because you could again install
    additional software from 3rd party repositories or you could just
    rebuild and install your own rpms.

    You are barking up the wrong tree.

    Alexander
  • Lamar Owen at Jul 25, 2011 at 11:09 am

    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).
  • R P Herrold at Jul 25, 2011 at 11:22 am

    On Mon, 25 Jul 2011, Lamar Owen wrote:

    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).
    I've a full set for C5 on ZM 1.23 -- the SElinux blissful
    unawareness of that code is startling, as it is doing 'unsafe'
    operations all over the place. Running it on a dedicated
    appliance box and treating it as a vulnerable client to a
    SELinux enabled network using network sockets, is about the
    only way to run it safely

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

    -- Russ herrold
  • Lamar Owen at Jul 25, 2011 at 11:53 am

    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.
  • R P Herrold at Jul 23, 2011 at 10:45 pm

    On Sat, 23 Jul 2011, Thomas Dukes wrote:

    When I say non-rpm, I mean source packages I compiled such as zoneminder.
    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
    [clean up the trimming and leave the top post as it was]

    and so the person you are angry at for not taking the time to
    do the packaging, to have a SRPM that may be rebuilt, is ...
  • James B. Byrne at Jul 25, 2011 at 9:24 am

    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


    --
    *** E-Mail is NOT a SECURE channel ***
    James B. Byrne mailto:ByrneJB at Harte-Lyne.ca
    Harte & Lyne Limited http://www.harte-lyne.ca
    9 Brockley Drive vox: +1 905 561 1241
    Hamilton, Ontario fax: +1 905 561 0757
    Canada L8E 3C3
  • Lanny Marcus at Jul 24, 2011 at 8:51 pm

    On Sat, Jul 23, 2011 at 5:41 PM, Thomas Dukes 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/Installati
    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
  • Thomas Dukes at Jul 24, 2011 at 10:20 pm

    -----Original Message-----
    From: centos-bounces at centos.org
    [mailto:centos-bounces at 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
    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
  • John R. Dennison at Jul 24, 2011 at 10:28 pm

    On Sun, Jul 24, 2011 at 10:20:07PM -0400, Thomas Dukes wrote:
    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.
    There is no 5.7 yet.
    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 know of at least one packaged zoneminder and its required deps; I'm
    not sure if it's public but if it is the person that did the packaging will
    likely speak up as he is on this list. So it's indeed possible.
    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.
    This is purely FUD.
    I thank all for the help I have recievied over the years, its just not
    beneficial to stay this current direction.
    Good luck with future endeavors.




    John
    --
    What lies behind us and what lies before us are tiny matters compared to
    what lies within us.
    -- Ralph Waldo Emerson
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110724/70569a1a/attachment.bin
  • Always Learning at Jul 24, 2011 at 10:31 pm

    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.


    --
    With best regards,

    Paul.
    England,
    EU.
  • Craig White at Jul 24, 2011 at 11:48 pm

    On Sun, 2011-07-24 at 22:20 -0400, Thomas Dukes wrote:
    -----Original Message-----
    From: centos-bounces at centos.org
    [mailto:centos-bounces at 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
    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.
    ----
    update from CentOS 5.6 to 5.7 (when 5.7 becomes available) is
    automatic... just run 'yum update' - no extra efforts or thought need to
    be given.

    update from CentOS 5.x to CentOS 6.x is at best a crapshoot. Skilled
    admins should be able to fix whatever needs fixing. Less than skilled
    admins will find it takes less time to backup and re-install.

    As for switching to Ubuntu...

    I have switched my latest installs from RHEL/CentOS to Ubuntu. Primarily
    because I felt I couldn't rely upon timely releases/updates.

    Let me assure you though that nothing is perfect with any distribution
    and while some packages might be newer/more readily available on one
    distribution than the other, there are certainly other packages that are
    newer/better vice versa.

    ffmpeg on CentOS/RHEL 5.x is a bit behind (CentOS/RHEL 5 is way behind).
    zoneminder is just perl scripts so it doesn't make that much of a
    difference if it is RPM packaged or just tarball install

    CentOS/RHEL has a much larger window of support for a specific version
    than Ubuntu so claiming that Ubuntu has a 3 year window as an advantage
    suggests that you don't understand the RHEL/CentOS support windows at
    all.

    Craig


    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.
  • Eero Volotinen at Jul 25, 2011 at 1:52 am

    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
  • Thomas Dukes at Jul 25, 2011 at 7:33 am

    -----Original Message-----
    From: centos-bounces at centos.org
    [mailto:centos-bounces at centos.org] On Behalf Of Eero Volotinen
    Sent: Monday, July 25, 2011 1:52 AM
    To: CentOS mailing list
    Subject: Re: [CentOS] Upgrading from CentOS 5.6 to 6.0
    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.
    Huh??

    From: http://mirrors.kernel.org/centos/3/readme.txt

    CentOS Errata and Security Advisory CESA-2010:0817

    End Of Life security update for CentOS 3:
    https://rhn.redhat.com/errata/RHSA-2010-0817.html

    As per the upstream vendors errata support policy, updates for CentOS-3
    has ended on October 31th 2010.

    It is recommended that any system still running CentOS 3 should be
    upgraded to a more recent version of CentOS before this date to ensure
    continued security and bug fix support.

    see also http://wiki.centos.org/HowTos/EOLC3

    Thank you to everyone who helped make this project possible.

    Tru
  • John R. Dennison at Jul 25, 2011 at 7:49 am

    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
    --
    "Political Correctness is a doctrine, fostered by a delusional, illogical,
    liberal minority and rabidly promoted by an unscrupulous mainstream media, which
    holds forth the proposition that it is entirely possible to pick up a turd by
    the clean end."

    -- Unknown
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110725/fdc2c6ec/attachment.bin
  • Lamar Owen at Jul 25, 2011 at 11:12 am

    On Sunday, July 24, 2011 10:20:07 PM Thomas Dukes wrote:
    I'll be moving to Ubunto.
    Never heard of Ubunto....
    They have a 3 year window for support on a
    distribution unlike CentOS/RHEL.
    Right; RHEL has a seven year window, four years longer.
    They seem to be more user friendly for a
    home networking environment.
    No, they're not. Been there, done that.
  • Craig White at Jul 24, 2011 at 11:52 pm

    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


    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.
  • R P Herrold at Jul 25, 2011 at 10:05 am

    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
    -- Russ herrold
  • Craig White at Jul 26, 2011 at 12:56 am

    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


    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.
  • Lanny Marcus at Jul 25, 2011 at 12:07 pm

    On Sun, Jul 24, 2011 at 10:52 PM, Craig White 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
  • Patrick Lists at Jul 25, 2011 at 12:37 pm

    On 07/25/2011 06:07 PM, Lanny Marcus wrote:
    On Sun, Jul 24, 2011 at 10:52 PM, Craig Whitewrote:
    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
  • Les Mikesell at Jul 25, 2011 at 12:58 pm

    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.
    ----
    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.
    In production environments where you treat hardware as disposable
    commodity chunks it makes sense to demand the extra effort to make the
    software components reproducible across repeated installs. In other
    scenarios, it is just extra effort without much purpose unless someone
    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?

    --
    Les Mikesell
    lesmikesell at gmail.com
  • R P Herrold at Jul 25, 2011 at 1:05 pm

    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 at centos-5 zoneminder]$ ls -1 | grep ^per | wc
    37 37 1354
  • Les Mikesell at Jul 25, 2011 at 1:26 pm

    On 7/25/2011 12:05 PM, R P Herrold wrote:
    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
    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. And of course your next install may be on a
    non-RPM based system, making any rpm-packaging effort moot.
    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
    Now you are talking about very different things. Installing your own
    stuff in /usr/local (as most source installs would do unless you go out
    of your way to subvert it) bypasses the issue of overwriting
    disto-supplied files. You are right, of course, that outdated and
    missing libraries in the base disto are a complex problem particularly
    for languages/apps that have their own update/install concepts, no
    matter how you try to solve it. But a simple 'build an rpm' isn't going
    to fix those complications.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Patrick Lists at Jul 25, 2011 at 4:34 pm
    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
  • Les Mikesell at Jul 25, 2011 at 4:49 pm

    On 7/25/2011 3:34 PM, Patrick Lists wrote:
    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 :)
    The context for the issue was someone moving from 5.x to 6.x.
    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?
    But wouldn't it be better if they actually did that instead of locking
    themselves into a single vendors system?
    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?

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Patrick Lists at Jul 25, 2011 at 6:07 pm

    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
  • Mark Roth at Jul 25, 2011 at 1:29 pm

    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.
    ----
    why?
    <snip>
    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.
    In production environments where you treat hardware as disposable
    commodity chunks it makes sense to demand the extra effort to make the
    software components reproducible across repeated installs. In other
    scenarios, it is just extra effort without much purpose unless someone
    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?
    Another thing: most places I've worked, the large majority of projects
    will be running in production, eventually. Having specialized packages
    that you have to build, other than the project itself, means you'll
    eventually have to do it for the entire time the project's in production,
    and frequently means that the project itself is fragile, and perhaps
    poorly implemented, and likely to break.

    mark

Related Discussions

People

Translate

site design / logo © 2022 Grokbase