hope out there is somebody who can clarify that a bit for me. Thank you in advance.
I read somewhere there is a problem using different package manager, what I mean is if you install a packet with apt-get does it show up in Yast or not?
I think yes but it would be nice to get your feedback regarding this, i think all packet managers use the RPM Database to get this information it would be nice to let me now if I am wrong.
Are there more databases and I just got the info wrong? If yes which Database is not syncronized?
Thanks for the reply, you’re right by default apt is not a packet manager in OpenSuse. Anyway I installed it as I am used to apt but learned to love Suse in older times.
Tried it myself and you can see also apt installed packages in Yast.
Then it must be clear to you that apt-get and zypper (which is the real packagemanager, YaST > Software only being the GUI to it) are different products using different methods and having different databases. So using apt-get you will not have the benefit of things like automatic warnings for security updates, etc.
That you see those packages is because of the common RPM database, but they still have different other features.
Thanks, I think we getting close. Both use the RPM Database for the installed packages, thats the reason it shows up in Yast.
Do you know which features don’t work with apt-get (you mentioned already Security Updates), are there more features? Which kind of database Zypper (libzypp) is using or what kind of information is stored in this Database.
Do you mean with Security Updates the Update Applet for example? So it shows the packages but can’t gather update information and does not show Security Updates?
I am sorry to bother you with this but got in the theme Zypper today and want to know more. I read all the information on the OpenSuse site but can’t find this information:
1, This features do not work with apt-get
2, What kind of second database additional to the RPM database and whats stored in there
The APT from openSUSE is APT-RPM. If you go t its website (APT-RPM) you will see the project is dead (original APT is still maintained).
ZYpp knows about soft dependencies (recommends, suggests, enhances, supplements). Not sure, but I don’t think APT-RPM does. That means you also loss automatic driver installation (Duncan Mac-Vicar P. · Extremely easy driver installation)
ZYpp knows about patches and packages, APT only about packages
I don’t think APT supports deltaRPMs.
…
Seriously, APT-RPM is just an unmantained port of a worse package management stack. Use zypper.
I will not add much to what RedDwarf says above. He knows much better then I.
When looking for the data that zypper maintains in youir system do a
find / -name 'zyp*'
and I have no doubt you will find several of those files in that list.
Personally, when I used RedHat years ago, I maintained the system the RedHat way. When I would go to Debian, I would no doubt do it the Debian way. So my advice in this matter can be guessed by you.
I think PClinux uses a variant of Apt-rpm and it works pretty well.
As for Apt vs Zypper I still think Apt does a better job from my experiences, I have had usede apt on Debian/Ubuntu for years and never hand an issue with it.
If Apt was so bad I would not use it, perhaps its RPM port is not so great but on debian Apt really kicks !@#@$
Kinda. See there is a database that zypper/YaST, smart, yum and apt4rpm use, and that’s the rpm database. Why? Because these package managers really just give rpm a better algorithm and enhance rpm to better do it’s job. So all these package managers read and write to the rpm database. Along side this, they also have their own database. Having their own database is not to be confused with the rpm database. Thier own database is for things like, which rpm’s are new since the last refresh of the repos. Things like that.
Don’t get defensive!!
“so bad”? I said it is “worse” than ZYpp. Since I also said ZYpp is perfect that means “worse than perfect”, “imperfect”… a big difference from “so bad”. And I gave as source a paper from the University of California to prove it.
I also made explicit the difference between APT and APT-RPM in the second point, avoiding any possible confusion.
I made clear, simple and specific assertions about the problems of APT and APT-RPM. You can refute any of them if you think they are wrong… specifically, point by point.
The paper (that I link expecting anyone that wants to argue what I say to read it) tests the original APT, the one from Debian, as of its publication date (year 2007). And clearly says APT, the one from Debian, fails:
These numbers show that apt-get fails to find a solution when one exists in about 0.61% of install attempts. This is not a large error rate, but one has to remember that users perform many install attempts over the lifetime of their system. Assuming an average of 87 install attempts over the lifetime of a user system (computed from the average size of our trace lengths), the chance that a user will hit an in completeness error in the lifetime of their system can be computed to be 41.2%. The actual number collected in our experiments is smaller than this, but in the same ballpark: 23.3% of the 600 traces encountered an incompleteness limitation of apt-get. These numbers indicate that the completeness of Opium has the potential to improve the end-user experience of a large fraction of Debian users.
It doesn’t says it is “bad” or anything similar… they tested it and gave numbers. You can’t argue that without one of these:
a) A link showing an APT developer explaining improvements in the dependency resolution since 2007.
b) Reproducing the tests and showing different results.
Saying it works “pretty well” in PCLinuxOS, that it “does a better job from my experiences” or that “I have had usede apt on Debian/Ubuntu for years and never hand an issue with it” doesn’t means a thing (to start with, when APT returns a result you just suppose it’s correct, no user verifies the result is the correct/best one). For sure nothing that can compete with numbers from reproducible experiments from Ph.Ds. in computer science.
