"AT" <notme@example.com> wrote in message
newsan.2005.01.13.15.06.25.636647@example.com...
> On Thu, 13 Jan 2005 04:28:36 -0800, Tom F. wrote:
>
>>>You might need the upgrade CD set though (they've always
>>> done them, I think they might do a mini-cd for installing over
>>> the internet too, so that might work as an updater too)
>> Yes, the only real way to upgrade to the next version over the
>> internet is via the install boot disk. This is available for download
>> (about 50-60 Mb).
>>
>> It is also supposedly possible to do this via apt, but I've only heard
>> rumors. ;-)
>
> The rumors are correct, but you have to know what you are doing. See
> below.

For example, I just found a nasty boobytrap in the x86_64 network update.
The name of the initrd for x86_64 has changed from "initrd" to "initrd64",
because the installation trees have been merged. This was..... confusing to
say the least when grabbing the initrd from the FTP directory.

Nico Kadel-Garcia <nkadel@comcast.net> wrote:
> Heh. Try applying the suse-release RPM, and resetting where your download is
> from. It'll at least take a shot at updating you. But I wildly prefer fou4s
> to the YaST update tool.

YOU's improved quite a bit since fou4s came out.
In 9.1 they reduced the load on their servers by altering what was actually
in the update packages, previously, it was just a complete new package, but
now it's just the files that've been altered that are updated.

(They can still be quite large, kernels for example can't just be paired
down, but apart from that...)

<spike1@freenet.co.uk> wrote in message news:tk6jsc.79s.ln@freenet.co.uk...
> Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>> Heh. Try applying the suse-release RPM, and resetting where your download
>> is
>> from. It'll at least take a shot at updating you. But I wildly prefer
>> fou4s
>> to the YaST update tool.
>
> YOU's improved quite a bit since fou4s came out.
> In 9.1 they reduced the load on their servers by altering what was
> actually
> in the update packages, previously, it was just a complete new package,
> but
> now it's just the files that've been altered that are updated.
>
> (They can still be quite large, kernels for example can't just be paired
> down, but apart from that...)

And this approach is pretty fragile. It requires carefully differentiating
what the actual files in use are, on top of the file management already ini
place and attempting to finesse it even further.

Throw out YaST for package updates, use a real tool like YuM that is far
quicker and works out dependencies against multiple package sources
simultaneously so that it stops whining and trying to re-install your old
kernel every time you open the update tool. And document the available
options for the GUI and sending scriptable commands to the interface
somewhere, and pull the update tool away from the dozens of other distinct
and unrelated tools in YaST, and teach it that what you've installed via RPM
installations in fact exists and can be used for YaST update dependencies,
and teach it that when doing a YaST installation of a local file it should
still check dependencies instead of overriding the RPM dependencies willy
nilly, pant, pant, pant, pant, *i-i-n-h-a-l-e*......

And you may have a tool almost as useful as autorpm from www.autorpm.org,
fou4s for SuSE, or YuM for other Linux distributions. Unfortunately, you
can't just use those because SuSE once again interwove their own middleware
on top of RPM and YaST doesn't detect correctly what package versions you've
installed if you didn't use YaST to do it, so it will actually revert RPM's
installed via other means.

Nico Kadel-Garcia <nkadel@comcast.net> wrote:
> Not SuSE. Please. A bunch of people like it for the stability and support
> reasons, and if you're running a specific software package that is
> well-tested I can see continuing to use it. Also, SuSE takes its
> internationalization quite seriously (they're a German company). But they've
> been duplicating a mistake that RedHat stopped doing years ago and keep
> stapling functionality into YaST instead of using separate modules, and in
> the process they've created this incredibly complex and undocumented mess of
> interwoven dependencies and widgets that they seem to think are smarter and
> better than that of the authors of the software itself.

Um, have you SEEN yast2?
It's yast2 plus a set of modules for all the configury bits.
They have modularised it.

<spike1@freenet.co.uk> wrote in message news:mutlsc.v8v.ln@freenet.co.uk...
> Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>> Not SuSE. Please. A bunch of people like it for the stability and support
>> reasons, and if you're running a specific software package that is
>> well-tested I can see continuing to use it. Also, SuSE takes its
>> internationalization quite seriously (they're a German company). But
>> they've
>> been duplicating a mistake that RedHat stopped doing years ago and keep
>> stapling functionality into YaST instead of using separate modules, and
>> in
>> the process they've created this incredibly complex and undocumented mess
>> of
>> interwoven dependencies and widgets that they seem to think are smarter
>> and
>> better than that of the authors of the software itself.
>
> Um, have you SEEN yast2?
> It's yast2 plus a set of modules for all the configury bits.
> They have modularised it.

I've used it. It's not enough to say "ohhh, lookit, we've got the modules in
different RPMs!". The available modules are undocumented, and normally
summoned or managed only from within YaST. The one clear exception is the
SaX2 configuration tool for xorg or XFree86, which is actually a pretty good
tool which I rather like.

Let's take an example of the whackiness, shall we? Let's say I'd like to
configure an LDAP service for my network. Oh, look, YaST has some tools in
it to configure LDAP! Great! Oh, wait. It only knows how to turn on the
client, not the server. It has absolutely no clue about the server.

DNS? OK, let's add a zone. Hmm, when I add a zone, it creates new zone files
in /etc/named.d and lists them as included from /etc/named.conf.include. A
bit complex, but parseable and it gives a nice separation of zone
information from the base named.conf. But the name of the resulting zone
file in /etc/named.d/ is the same as the name of the zone, and there is no
way to change that in YaST. I can change it by hand in
/etc/named.conf.include to be /ec/named.d/{zone}.zone, so that my text
editors such as Emacs auto-update the serial numbers for me when I edit it
(which is very useful). YaST will happily even work with the alternative
zone file name now. But if I delete the zone and re-install it, I have to
change the name back.

Or software updates. Have you tried updating a kernel, then had YaST wine
every time you run the update tool about a dependency on an old kernel and
had it revert your kernel to the old kernel, even though you told it to
*UPDATE* the kernel to the most recent, not use the old one? This is deadly
as sin if the system requires special hardware drivers for its booted OS.

And even more fun, YaST broke grub. Kernel installations of multiple kernels
list only the single /boot/vmlinuz symlinked kernel as "Linux", and do not
list the additional kernels in /etc/grub/menu.lst. There is no way in YaST
to auto-generate the names of all the available kernels for bootable options
such as manipulating run levels or picking alternate configurations, it
seems to flush any entries you might add and set them back to only the
/boot/vmlinuz symlink kernel. If there's a way to do it right, I haven't
found it.

And don't get me going on what they did with the symlinks in what are
described as chroot cages for bind.