LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware - Installation (http://www.linuxquestions.org/questions/slackware-installation-40/)
-   -   Updating to 12.0 from 10.0 (http://www.linuxquestions.org/questions/slackware-installation-40/updating-to-12-0-from-10-0-a-4175435929/)

stf92 11-06-2012 11:38 AM

Updating to 12.0 from 10.0
 
I want to update slackware 10.0 to 12.0. I do not exactly know what 'update' means in this context but, in the partition were I had the whole of 10.0 I want to have now 12.0 in its place. But if I directly install 12.0 above 10.0 there will be left a lot of files with no purpose there. Formating is not an option because I have personal data and programs in the same partition. How should I proceed?

TracyTiger 11-06-2012 12:35 PM

Update incrementally - Of course backup first
 
Note Alien Bob's response in the following thread regarding the use of slackpkg.

http://www.linuxquestions.org/questi...nt-4175435551/

I'm not sure if back in release 10.0 that the changelog format in use then allowed slackpkg to work. Perhaps someone else knows how far back slackpkg will work.

stf92 11-06-2012 12:40 PM

Are you telling me the scenario would be different if upgrading to 11.0 from 10.0 or to 12.0 from 11.0?

TracyTiger 11-06-2012 12:48 PM

If you're using slackpkg the process should be the same from any old release to any new release. (As long as you do it incrementally as Alien Bob stated.) However slackpkg depends upon the content/format of the changelog for each release. Slackpkg has not been around forever. It is possible that an earlier release of Slack (perhaps 11.0) used a different changelog format and that the current slackpkg tool wouldn't understand properly.

I've only been using slackpkg for the last year so I have no experience with slackpkg on older releases. When I see references to using slackpkg in LQ posts I don't remember seeing anything about using slackpkg before release 12.0.

There may be other ways to upgrade from one older release to a "newer" older release but slackpkg works so well these days that I would recommended investigating the use of slackpkg first.

Perhaps someone with knowledge about using slackpkg on release 10.0 will respond.

EDIT: It may also be the case that you would have to be careful about which version of slackpkg you used at each step of the upgrade process. You may need to use an older version of slackpkg or you may need to use a newer version to fix a bug found in an older release. Just my thoughts, no experience on using slackpkg with older releases.

TobiSGD 11-06-2012 01:14 PM

You really should backup your personal files first, as you always should do when doing something system-critical. But if you do that there is really no point in trying the update, just make a clean install.

stf92 11-06-2012 01:43 PM

Thank you, TobiSGD. I now for the first time understand the difference between updating and a clean install. So, all I have to do is to backup /home, /root/ and perhaps some directory created at /. Perhaps /usr too.

TobiSGD 11-06-2012 02:08 PM

You only need to backup the files you want to keep. Backing up /usr will have no use for you, it contains only files that will be part of a new install anyways.

stf92 11-06-2012 03:44 PM

Thank you. I have installed some third-party software under 12.0, which I hope will work when reinstalled under 14.0. Is software generally designed to be upwards compatible. I.e., if it works under a given OS then it will work under a new version of the same OS?

TobiSGD 11-06-2012 05:08 PM

No, it depends on the libraries that the software is dependent on. If it is software you have compiled yourself (or using Slackbuilds) it may work, but it may be better to compile it new for the new system. It may also be possible that older software will not work on newer systems, so that you have to use a newer version (if available) of that software.

stf92 11-06-2012 05:52 PM

Well, then I must say things in the old days of MS-DOS were simpler than elsewhere. I have a chess program for MS-DOS 3.3 that stills works under the last microsoft windows (xp, to be honest).

At least, while the OS was DOS and not windows, that is before DOS became just the command interpreter, given any third-party program for DOS it would continue to run OK as the DOS version numbers increased. Although unofficial sources of the OS calls could say "support for this function [call] may cease at any time".

This is not a critic but a simple "note on the margin".

TobiSGD 11-06-2012 06:05 PM

You can run your DOS program in Linux also, using DosBOX. The difference is that in Linux you know that it is an emulator, while Windows silently pretends to just run it, using an emulator nonetheless.
But the thing is that those problems usually only occur with proprietary programs, open source programs usually don't have such problems, and if they have you can try workarounds, like chroots with older libraries (impossible on proprietary OSes).

stf92 11-06-2012 06:20 PM

You've given a step forward to defend linux, and that's fine with me. But I have now another question. The is a given version of a library and now comes a new version. A library is a collection of subroutines or, in the C jargon, of functions. Incompatibility you say can occur because of the libraries. So, the old library could have funcion A whose first argument is number of birds in a cage but, in the new one, function A first argument is the color of the birds. Or the new library could just lack function A.

Now, how is this possible? Wouldn't things have to try to be downwards compatible? Intel x86 processors are downwords compatible. This means any program that runs, for instance, in the 8086 will run in a Pentium. If hardware manufactures can do it, why software manufactures can't?


EDIT: I think I was wrong with my definition of library but the concept applies equally well for my example.

TobiSGD 11-06-2012 06:35 PM

The question is not "why can't they", the question is "why don't they". For that you have to ask the particular developers.
It may be a case of "we want to rewrite it and in this process we cut out some old, nowadays very rarely used functions", sometimes it is that there are bugs in older libraries and the dependent software used workarounds that will no longer work with newer libraries, or it is simply that some developers have used a library in an originally unintended way the library developer doesn't think about when developing the library further. There are many reasons.

To make that more clear. A newer version of a library can be backwards compatible. Your software doesn't have to break when the libraries are upgraded. But it may be possible that the developer decides not to make the effort.

stf92 11-06-2012 06:50 PM

I see. But getting back to "hardware vs software", and referring to Intel x86 which is what I know, I think the main difference is that the whole of software depends on the CPU and they (CPUs) must therefore be free of bugs, they can't malfunction because they are being used not as intended, et cetera. It is the enormous body of software that will be based on that processor that makes the designers to plans things in a very serious and deliberate way. I think that, in many ways, hardware manufactures are an example to follow by software designers.

EDIT: an exception to what I said above is somebody using a non-existent OP-code, although modern processors must surely produce an exception or software interrupt.

TobiSGD 11-06-2012 07:00 PM

Quote:

Originally Posted by stf92 (Post 4823757)
I see. But getting back to "hardware vs software", and referring to Intel x86 which is what I know, I think the main difference is that the whole of software depends on the CPU and they (CPUs) must therefore be free of bugs, they can't malfunction because they are being used not as intended, et cetera. It is the enormous body of software that will be based on that processor that makes the designers to plans things in a very serious and deliberate way. I think that, in many ways, hardware manufactures are an example to follow by software designers.

CPUs aren't bug-free. There were famous bugs, like the FDIV bug in the Pentiums or the bug in the first generation Phenoms, but also lesser known bugs. Any CPU has a list of errata, bugs found in them that can sometimes be fixed with microcode updates, sometimes the compilers have to use workarounds.
The real difference is that CPU manufacturers are one company. They are the ones setting the standards and they have all completely in-house, from design to manufacturing. Software developers have to rely on parts that are delivered to them (libraries) and which they mostly are not really able to influence. If such a library changes in a way that they have to adapt their software they simply have to do it. Otherwise software development would be stagnating and we would still run Bash 1, KDE 1 and Netscape 1 for daily use, on machines that are running a Linux 1 kernel.


All times are GMT -5. The time now is 11:08 PM.