I’ve been jumping around trying to find a Linux distro that I like, and after trying many different ones, openSuse is my favorite so far!
Anyways, after a bit of messing around I have some newbie questions:
When I make a text file, should I add .txt to the file name?
I was trying to install Octave (a math program), so I went inyo YaST > Software Management > Search, and I typed in Octave and nothing showed up. So then I went into YaST > Package Search, and typed it in there. I got some hits but it was listed three times, all with the same version. I realized that these are from different package repositories. So
[LIST=1]
What is the difference between going through “software management” and “searching for packages?”
How do you choose the repository? Do you just choose a random one? How do you know if it’s safe?
> - When I make a text file, should I add .txt to the file name?
If you want it with txt extension, yes, if you don’t add .txt you’ll
have a “name” file that are a plain text file
> - I was trying to install Octave (a math program), so I went inyo
> YaST > Software Management > Search, and I typed in Octave and nothing
> showed up. So then I went into YaST > Package Search, and typed it in
> there. I got some hits but it was listed three times, all with the
> same version. I realized that these are from different package
> repositories. So
>
> - What is the difference between going through “software
> management” and “searching for packages?”
Software management only show you packages on the configured
repositories, searching use webpin to search on diferent repos
> - How do you choose the repository? Do you just choose a random
> one? How do you know if it’s safe?
>
Use the repositories on the openSUSE web
VampirD
Microsoft Windows is like air conditioning
Stops working when you open a window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
You can name the file whatever you want, you don’t need an extension. make sure set the permissions when you make it, and always remember linux IS case sensative.
Software management has options to manage software/packages that you already have, or have already installed. Searching for packages is self explanatory. As far as the various repos, I’d have to see them, but always check the opensuse repos first. Also don’t forget, that after you download and install and update your package to kill the repository and get it off of your list. Having too many repos can be conflicting, making you life chaotic. Also you can always google and research the repos that did pop up.
If so, then I am in luck because that is from where I got it. Also, what is the difference between the factory and non-factory version of these two repositories?
allwires wrote:
>
> By saying “Use the repositories on the openSUSE web” do you mean
> repositories from here? ‘Package repositories - openSUSE’
> (http://en.opensuse.org/Package_repositories)
Yes
>
> If so, then I am in luck because that is from where I got it. Also,
> what is the difference between the factory and non-factory version of
> these two repositories?
Factory contains packages that are being developed, tested and are
unstable (lastest version, but unstable), the other are the stable
software (maybe not the last version)
VampirD
Microsoft Windows is like air conditioning
Stops working when you open a window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
Allwires your post suggests to me you are a bit puzzled about repositories in openSUSE, and apologies if I have this assessment wrong, but let me pass some information in case my assessment is not too far off the mark.
Typically I recommend new users permanently enable 4 and ONLY 4 repositories. Those are OSS, non-OSS, Update and Packman. The 1st 3 (OSS, non-OSS, and update) are official repositories. The 4th packman is the largest 3rd party repository:
OSS - which is open source software, is the main official Novell/SuSE-GmbH repository. It contains open source software only, per the free software foundation definition.
Non-OSS - This is the official Novell/SuSE-GmbH non free (as in the free software foundation definition of free) software, such as Flashplayer, Java, Opera, IPW-firmware, RealPlayer etc.
Update - This is the official Novell/SuSE-GmbH repository for official security and bugfix updates for both OSS and Non-OSS.
Packman - Packman offers various additional packages for openSUSE (especially lots of multimedia and games and some drivers). It’s the largest openSUSE external repository.
Now there are many other repositories, of which a small number are mentioned in these two URLs:
… and having passed all that information I recommend you restrict your enabled repositories to 4 and ONLY 4: OSS, Non-OSS, Update and Packman. The 1st 3 will already be setup and you just need to add Packman. Only experienced users or advanced users can ‘get away’ with permanently adding more than those 4.
If you MUST install an app from a 5th repository, then add the repository, install the app, and then remove the repository. If you do NOT do this you risk instability.
Again, just the 4 I noted should be enabled permanently: OSS, Non-OSS, Update and Packman.
Thanks for the response. Yeah, I am a little confused hehe. If I enable a repository just to install a single program, and then disable the repository, does that mean that the program I installed won’t get updates?
Add repo, install special app, remove, add repo, get update, remove
Add repo, add special package, Disable the repo, enable the repo, get update, disable repo
Problem is that some of these repo’s have older or buggy packages in the repo with the app you want. If you fail to remove or disable the repo, these bad or older packages can be drawn into your system when a normal update is done. This results in a working package being downgraded to a faulty one which is what you don’t want. The ones oldcpu has stated have been checked for stability and are actively being improved. The same package in some obscure repo may not have been maintained for some time and is there because the app you needed depends on the helper package to function if not already installed on your system. Thusly as your needed package installs it see’s it needs a helper (dependency) and see’s you don’t have it installed so it includes the one from the repo. On the other hand, it may see you already have the package to satisfy the dependency so it says “nope I don’t need to install it again”
Just wanna throw out the fact that you are great, and its people like you that keep new linux users like myself in the game. your knowledge is useful, help, and always seems to spread, thank you.
So once I install and update the Vbox, your saying to kill the repo and forget about it, including the updates. would it be appropriate to attemp stable updates annually?
Is there any indication(s) anywhere for different programs to help me determine what to do with the repo’s and how often to update? the websites sometimes give guidelines/advice/and explanations of how they do it, but some don’t… I understand about disabling/killing the repo’s after installation/updates…I’m most concerned w/ the updates at this point…
The repos is never truely dead. You can revisit it any time. You can add it back any time. By removing it you remove the possibility that an rpm in its repos that is not necessary (and that could cause problems) is not inappropriately installed at the wrong time.
Hence this gives you control over your PC’s updates, as opposed to the updates controlling your PC.
My view has always been that the best way to solve a dependency problem or functionality problem is to never encounter one.
If its a Novell packaged app, then important security updates will appear in Update and you will get them.
How many 3rd party apps are you planning to install ?
If it is an app you use all the time, then simply bookmark the repository and visit every 3 to 6 months, checking for an update. Also bookmark the applications web page (practically everyone has a web page) and every 3 to 6 months visit its web page. If you see an update on the web page, then go visit the repository (or do a search on Webpin or Software search openSUSE.org ) to see if the update has been packaged. This takes next to no time, and it will IMHO save time in terms of avoiding problems one may otherwise encounter.
Adding a repository is easy. I would say too easy, as too many users add too many and cause them selves no end of problems. One can add a repos via the gui: Repositories/11.2 - openSUSE-Community
or even via zypper with the “add repository” (ie “ar” ) option. For example, to add packman for openSUSE-11.2 (with root permissions):
zypper ar http://ftp.gwdg.de/pub/linux/misc/packman/suse/11.2/ packman
and to “remove repository” (ie “rr” ) packman if added with the name “packman” (with root permissions):
For the specific case of VBox this is how I do it.
I do not use the repo’s They tend to be back a version. I download the generic version from Sun and use the installer to compile (note need gcc and kernel-source packages) Then when a kernel update happens I just reinstall VBox thus compiling it for the new kernel.
I used to do this for the video driver also but the NVIDIA repo seems to work well in 11.2 and I have yet had to manually re-install. When I get a notice that the kernel is to be updated ( by updater) I simply turn on the NVIDIA repo and install the new kernel then turn it off after the reboot.
Actually fast bugfixes via a systemwide package manager are one of the major reasons why Linux-systems tend to be more secure than Win or Apples. To state that less updates might be better for the stability of a system is just wrong. It is also plain wrong to state that using a potentially risky repository just occasionally will lower the risks.
This is an attempt to boil down the pretty complex topic of package management to a few rules - which can not work out. For example suggesting to deactivate the VirtualBox-repo after each upgrade makes no sense at all, since it only provides VirtualBox anyway. What’s the use to deactivate it? Also remember that by deactivating repositories you could unintentionally lock groups of packages since their dependencies can not be met anymore.
There are relatively safe repositories like oss, non-oss, update and to a certain degree Packman and there are lots of other repositories. If one wishes to use such repositories, there’s no way around finding out what a certain source is up to (providing rock stable applications, beta-software for testers, alpha-software for developers, killing time etc. pp.). It’s also necessary to learn how to use multiple repositories, for example by using priorities, package locks and the like - deactivating repositories while actually still using them is just a workaround that makes the package manager look like a useless obstacle while it’s actually there to manage such stuff. And it can do if used as intended. I use about 20 or 25 repositories since at least two years and never (never!) did it gave me a problem that I didn’t know how to undo - my point is: it can manage such stuff without risking system stability, but the user still has to know what parameters are important, which packages should not be installed using unstable versions, which one do hardly matter in the systemwide context, how to find out about which sources can be used with others and which not - experience can not be substituted by workarounds. A n00b should stay with oss, non-oss, update, Packman and a source for a GFX-driver if needed. This will give you a stable and reliable system and enough time to find out about the rest.
@gogalthorp: since the VirtualBox repository is maintained by Sun, the versions provided there are always up to date. Just a hint.
gropiuskalle YES you are right AND I still most definitely disagree with you.
For users who are advanced enough to have the common sense to look to see what else is in the repository, and have the knowledge to assess the risk, then what you state is absolutely correct. This is what experienced average users, and advanced user do.
Frankly, the ability to make an accurate assessment here is WELL BEYOND the capability of a new USER. Well beyond.
Hence is IS important, indeed I go a step further and I still MAINTAIN it is ESSENTIAL for new users to follow my recommendation.
Despite you being correct in the technical aspects of your assessment, you will not find me agreeing with the ‘advice’ part of that assessment.
My comments are aimed at new users and NOT aimed at experienced average nor advanced users.
I strongly recommend to ANY new user reading this thread to stick with JUST OSS, non_OSS, Update and packman. Do not be over confident in one’s abilities to assess what is inside a repository (as a new user). So just those 4 repositories. No others. None. Not one.
oldcpu, I was also referring to this statement of yours (which contradicts your paradigma):
If you MUST install an app from a 5th repository, then add the repository, install the app, and then remove the repository. **If you do NOT do this you risk instability. **
…which actually suggests that this will lower risks, but it definitely does not. If I install a unstable xorg-version it might disable the entire GUI, no matter whether the respective repository is disabled or not. When installing a package, it often will install dependencies or different versions of already installed packages - usually such a “must have” is hardly about a single package.
Must or not: if a n00b can not find a certain package within a stable repository then it’s just bad luck. I suppose we agree on that.
But: if an advanced user will use advanced repositories, he / she will have to learn how to manage them. It can not be used “a little bit”.
Reducing the repositories does IMHO lower risk (and hence improve stability). And IMHO lower it significantly (and improve new user stability assessments).
I do not agree with your assessment here, or perhaps we are refering to different things.
When a user adds repositories, which has additional applications present besides the one that they are interested in, there is always that risk that those applications, which have not had the same level of testing as OSS, non-OSS, Update or Packman rpms, will cause problems, and indeed cause instability problems.
I have seen this dozens of times in users problems.
Dozens.
Experienced average, or expert users do not have this sort of problem because they can easily assess and sort any such problem, and IMHO this is where your accurate assessment is coming from. That I don’t dispute.
Still, in my case, I keep my repositories to the absolute minimum. Even if I “might” have the knowledge to sort resulting problems, I can not be bothered. My view is that the “best way to solve a dependency or functionality problem (due to additional repositories) is to NEVER encounter one”. Keeping my repositories trimmed to the bare minium does that nicely.
My humble opinion: Just stick to the famous four. Unless you know what to do when getting lost, take care you don’t get lost. If you don’t, get help before you start, i.e. let somebody teach you, or read read read.
The couple of customers that don’t stick to this rule are the ones that pay my bills
