On Thursday 02 May 2002 16:31, Curtis Rey wrote: (big whine snip)

Just MHO, Curtis

(big whine snip)

...

cheers, Marcel (big whine snip)

...

...

...

...

Respectfully, Curtis

(big whine snip)

Ok guys, do you need some cheese to go with all that whine you have? ;o) First everybody complains about Yast1 going away, then they complain why don't we have apt-get type program like Debian. Is there no satisfying some people? Sounds and looks like there is pretty much everything needed to do what you want or replace what you had. Certainly some more features added to Yast2 will be forthcoming in good time, but I just don't understand all the whining I guess. Hey we are Linux guys! We know how to work around things, fix things and make things work that shouldn't for gosh sakes! :o) Patrick -- --- KMail v1.4 --- SuSE Linux Pro v8.0 --- Registered Linux User #225206 Magic Page Products -- Amiga-SuSE-PC Sales & Service URL: http://home.sprintmail.com/~tracerb

On donderdag 2 mei 2002 23:56, Stefan Nilsen wrote:

YOU only includes a small number of the updates available.

apt-get is no serious replacement because the SuSE rpm's don't have the correct dependencies in some cases. For an example try to have java2 installed and try to apt-get some updates. Won't work. Have to deinstall java2.

To my opinion APT is just the right candidate as it will lead to better defined rpms... Given your example: This happens because SuSE itself is not using APT. If SuSE would use APT, they would have determined the incorrect/missing dependency themselves. The java2 rpm can then be improved and released. In the long run this will lead to even better quality rpms from SuSE. And better rpms are attractive for every one. -- Richard Bos For those without home the journey is endless

...

suse's ftp), other settings I mostly change manually in the config files, because I think that gives me more control over the settings.

I trusted Yast better with my config files then with (incompatible?) packages ;-)

We all are different.

...

apt-get is no serious replacement because the SuSE rpm's don't have the correct dependencies in some cases. For an example try to have java2 installed and try to apt-get some updates. Won't work. Have to deinstall java2.

What are you saying? If SuSE rpm's don't have correct dependencies, yast could still install it so it would work correctly? i've experienced the opposite quite a few times. And then, would this be a deficiency of apt? Hardly so i think. At least apt would try to figure out how to fulfill the dependencies. Yast can't (or couldn't) and install it anyway, leaving you to clean up the mess it left behind.

Yast can install java2, apt-get can't find dependencies so it want to remove the "broken" java2 package. I think that explains pretty well that yast *can* install broken packages (--force --nodeps must be the reason), which also leads to SuSE, mistakenly I presume, delivers those packages to us. This is not a problem when using SuSE's tools, but apt-get is not SuSE's tool. apt-get is a little too picky to be usable with SuSE. apt-get likes debian better.

YOU and the possibility to update/upgrade (SuSE) packages, to me, is an important part of the system. This should work "out of the box" and as faultless as possible. Look at it this way: If this could implemented correctly it would save SuSE a lot of support calls (thus time and money they could spend on other important issues)? From my point of view apt4rpm, at this moment, comes closest in reaching this goal. It's not perfect yet and, like i said in an earlier mail, SuSE could help actively with the development and append it to their (and our) needs.

or maybe fou4s, with added possibility to add the complete update folders on the ftp, not just the security patches, and a good UI to manually be able to select what updates to install. Then we can call it yast, and everyone would be happy again :-) Maybe SuSE could strip the old yast from all the configuration tools, and only keep the parts for selecting and installing packages? That would be enough for me, because that is the part of old yast I'm using most. /Stefan PS: I still think SuSE is a good dist. Great work all SuSE ppl.

On Friday 03 May 2002 09.39, Richard Bos wrote:

On vrijdag 3 mei 2002 01:48, Stefan Nilsen wrote:

...

This is not a problem when using SuSE's tools, but apt-get is not SuSE's tool. apt-get is a little too picky to be usable with SuSE. apt-get likes debian better.

Humm, APT is not only officially supported/used by Debian. Conectiva uses it as their installer and updater as well, which is an rpm based distrobution just like SuSE. They even provide a GUI for it, I believe. Why is conectiva able to use APT and SuSE would not???

The difference here is that conectiva and debian *supports* the use of APT. SuSE does not do that today. Thats why i believe APT is not a serious alternative. When, and if, SuSE would support the use of APT, it would be great. If they supported it they would also make sure the packages worked with that tool. Today some SuSE packages cannot be installed with APT.

If SuSE would adopt APT there would be 3 big distributions supporting it. By then APT would become a nice candidate to become part of the Linux Standard Base (LSB).

Super.

And by the time RH, SuSE and others are LSB complaint it would be good to have a non distro specific installer. In that case it would be possible to have APT monitoring non SuSE APT (rpms) repositories as well.

In what way is APT *less* distro specific than RPM? APT only works well in 2 big distributions. RPM works in most distributions... It even does not require dependencies to be correct, because you can always --force --nodeps when installing a package. This cannot be done with apt4rpm. I agree APT is a very nice tool in a perfect world, but the world is not perfect...

...

or maybe fou4s, with added possibility to add the complete update folders on the ftp, not just the security patches, and a good UI to manually be able to select what updates to install.

Both requests/wishes are already provided by APT. The UI to decide which packages to install is there as well. Just use apt-get -S upgrade, e.g.:

dar:~ # apt-get -S upgrade Processing File Dependencies... Done Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back k_deflt The following packages can be upgraded: mozilla from 0.9.9-9 to 1.0rc1-0 Importance: ? Date: ? xf86tools from 0.1-146 to 0.1-233 Importance: ? Date: ?

Now use "apt-get install mozilla".

I don't call that a good ui :-) Btw, when I try to install java2 I get # apt-get install java2 ..... java2: Depends: libodbc.so but it is not installable Depends: libodbcinst.so but it is not installable ..... And it wants me to fix problems like this by removing all packages with broken dependencies. That does not cut it for me. I need java2 on my machine. Because of problems like this I cannot use APT today. Lets hope SuSE corrects failing packages so that we can begin to fully use this tool also on SuSE. /Stefan

On zaterdag 4 mei 2002 20:19, Ben Rosenberg wrote:

::It even does not require dependencies to be correct, because you can ::always --force --nodeps when installing a package. This cannot be done ::with apt4rpm. I agree APT is a very nice tool in a perfect world, but ::the world is not perfect...

Exactly. You can still download things via ftp and do what you suggest above. If SuSE were to support the APT tool outright then you wouldn't have any of the issues such as you had with java2 because SuSE would most like make their directory structure on the ftp server match what APT needs and they would write the scripts for deps checking that you and others now have to configure manually. It's a chicken and the egg situation.

In this particular case APT becomes unusable :( In case you would install java2 via rpm, APT would not work anymore after that, as APT will always complain about unmet dependencies and quit... The case is interesting: [final question: Can the incorrect dependency happen, because java2 has been build with an older version of unixODBC????] # apt-get install java2 ..... java2: Depends: libodbc.so but it is not installable Depends: libodbcinst.so but it is not installable Installed are: rbos@dar:/usr/lib> ll libodbc.so* lrwxrwxrwx 1 root root 16 Oct 20 2001 libodbc.so -> libodbc.so.1.0.0 lrwxrwxrwx 1 root root 16 Oct 20 2001 libodbc.so.1 -> libodbc.so.1.0.0 -rwxr-xr-x 1 root root 385423 Sep 24 2001 libodbc.so.1.0.0 rbos@dar:/usr/lib> ll libodbcinst.so* lrwxrwxrwx 1 root root 20 Oct 20 2001 libodbcinst.so -> libodbcinst.so.1.0.0 lrwxrwxrwx 1 root root 20 Oct 20 2001 libodbcinst.so.1 -> libodbcinst.so.1.0.0 -rwxr-xr-x 1 root root 65960 Sep 24 2001 libodbcinst.so.1.0.0 Which is done by: rbos@dar:/usr/lib> rpm -qf /usr/lib/libodbc.so /usr/lib/libodbcinst.so unixODBC-2.0.5-109 unixODBC-2.0.5-109 unixoDBC provides: apt-cache show unixODBC | grep Prov | tr " " "\n" | sort libodbc.so.1, libodbcinst.so.1, etc Now clearly there is a mismatch between what java2 requests and unixODBC provides :( I created my own unixODBC-addon spec file, that should provide the missing libs: # /usr/lib: cp libodbcinst.so.1.0.0 .../unixODBC-addon/libodbcinst.so cp libodbc.so.1.0.0 .../unixODBC-addon/libodbc.so tar czf <tarfile> .../unixODBC-addon Run rpm to create the packages, which is giving the following info: Processing files: unixODBC-apt-addon-1.0-1 Finding Provides: (using /usr/lib/rpm/find-provides)... Finding Requires: (using /usr/lib/rpm/find-requires)... ===>>> Provides: libodbc.so.1 libodbcinst.so.1 Requires... The *.so files are being recognized as *.so.1 files by rpm ... I now looked into the java2.spec file, there is no reference to unixODBC or whatsoever. So after building, rpm is finding the dependencies. In that state it probably determined that it is dependend on *.so instead of *.so.1 I don't want to build the 22MB java2 beast on my own system, so I can't figure out. Can the incorrect dependency happen, because java2 has been build with an older version of unixODBC???? -- Richard Bos For those without home the journey is endless

Crusher-1:/home/crrey # rpm -Fhv rpm: no packages given for install: A rather expected response. One has to know the package to update and hence back to the orignal frustration!

So I guess what your saying is that I have to go through every package and see if it will update? Original dilemma, How does one know if and when a package or list of packages has been updated by the developer?

So let's see: rpm -qv kdemultimedia3 rpm -qv kdelibs3 rpm -qv kdeartwork3 rpm -qv koffice rpm -qv kartsbuilder rpm -qv kpackage rpm -qv kpat rpm -qv ksysguard rpm -qv kugar rpm -qv lisa rpm -qv ktalkd rpm -qv xmms rpm -qv moneydance rpm -qv kappdock rpm -qv kec rpm -qv there are 113 files in the KDE/updates_for_8.0/applications directory alone, 13 in the base directory, 32 in the development directory. Then we have the SaX2, 3ddaig, commercial dirs and everything from a1 to zq1 in the updates. Granted the YOU reads the /update/8.0 files, however it has (and in fact just recently) omits packages from time to time that I could update visually and "quickly" compare against my system to see and compare the files be a simple highlight and "F2" button. So therefore we find ourselves spending an inordinant amount of time to do something that was previously a rather simplified task.

Hey, I'm all for innovations and moving forward. However, as and end-user and fanatically loyal SuSE patriot I find the lastest changes irksome and tedious.

Just MHO, Curtis

On Thursday 02 May 2002 02:39 pm, Marcel Broekman wrote:

...

Thanks Tor,

...

Subject: Re: [SLE] Ok, this sucks! Date: Thu, 2 May 2002 18:13:16 +0000 From: Tor Sigurdsson To: marcel@ietsmet.nl

Ever heard of "rpm -F" ?

It updates the package if and only IF

o It is already installed and o It is newer than the already installed package

rpm -Fhv *.rpm <-- updates everything that HAS to be updated, and nothing else.

Yes i know this! That said, i don't consider myself an rpm expert but you're forgetting that this thread is mostly about missing the ease of use of installing new, updated and individual packages, a function that Yast1 had and Yast2 doesn't. Before we can do what you suggest we'd still have to know which packages to download, then download and hope all dependencies are met (Yast1 didn't do this, i know). And run SuSEconfig afterwards. This is where apt-get could step in beautifully i think. It's here and ready, so why not use it and expand the possibilities.

cheers, Marcel

...

- -tosi

---snip---

...

...

getting apt-get to do the basic updating stuff is quite easy and won't cost you much time. Now if only SuSE could join the development of this great app and build their update, upgrade and install mechanism around it, preferably with a nice GUI plugin/module in Yast, they'd have the best package management tool in the world!

...

For those from SuSE that monitor the list post. Please inform the Product development department of these concerns. The feature I mentioned in YaST1 is sorely missed.

Respectfully, Curtis

ditto, Marcel A module for yast2 with the same functionality as Ximian's RedCarpet would

On Thursday 02 May 2002 13:31, Curtis Rey wrote: probably satisfy most peoples needs. Building it on top of apt4rpm would make a great package management and update utility. This is an area where mandrake has done pretty well with urpmi and the mandrake software manager. Throw in the cooker servers and Mandrake has a pretty useful and reliable update utility. If suse had something like this.....