Re: [MiNT] OSMD - introduction (fwd)

[Teemu Hukkanen <tjhukkan@fishpool.fi>]

Guido.Flohr@t-online.de (Guido Flohr) writes:

> On Sat, Sep 08, 2001 at 03:31:09PM +0200, Michael Schwingen wrote:
> > On Sat, Sep 08, 2001 at 12:17:37AM +0200, Guido Flohr wrote:
> > > RPM can do the same, provided that the packages are properly built.  Write
> > > a wrapper that figures out the correct order for the installation (maybe
> > > rpm will already do that, not sure), and then install all packages in one
> > > go, that's it.
> > 
> > Thats the problem I have. "Write a wrapper that will do it" is a bit
> > different from having the feature designed into the system from the
> > beginning.
> 
> At least SuSE yast is such a wrapper.  Probably linuxconf has more or less
> the same strategy.

Which one do you mean, yast 1 or yast 2? IIRC 1 can do upgrades over the
network, 2 can't. Both screw up manual changes in configuration files.

> > However, I do not see why I would want to do that. apt-get displays in
> > advance what packages it will upgrade, and with which consequences (ie.
> > which additional packages are being installed, which are removed etc.), so
> > why would I ever want to do this manually?
> 
> Matter of taste.  I rather have the operation fail with "package foo
> requires feature bar" because I know that I wouldn't look at the output of
> apt after the second time I've done it.

You could try running the old and proven dselect in a debian system,
it's been around nearly as long as dpkg. Many people don't like dselect
though, and thus several front-ends to apt/dpkg have sprung up, namely
console-apt and aptitude. With this front-end, when you choose a new
package or are just upgrading, you are given a list of packages that the
new package or new versions depend, recommend and suggest, you get to
choose interactively what to take and what you get.

> > > Another advantage of rpm is its ability to easily integrate foreign
> > > packages whereas systems like Debian or (Free|Net|Open)BSD are somewhat
> > > "closed" in that respect.
> > 
> > In what way?
> 
> How many "foreign" (non-Debian packages) are installed on your
> Debian system?

Depends on how you count foreign, I have at least half a dozen packages
that I maintain locally but have not uploaded into debian proper, apart
from that, I have exactly 0. See my other mail in this thread about the
number of debian native packages.

> > Debian has the "alien" command which will install tar.gz/rpm/slp archives.
> 
> My system has the same "alien" command.  Sure you can convert from one
> format to the other.  Seems like all package manager have this feature.

This "feature" is a program of it's own, made by Joey Hess, a debian
developer. It can do .deb, .rpm and .tgz (slackware), from any to any.

> > Those were just examples - if the system is capable of doing these, it must
> > be designed the right way. I would not trust a wrapper script with such
> > tasks.
> 
> The system is GNU-Linux, not Debian.  If you can do it with one package
> manager, you can principally do it with any package manager that is
> capable of dependency tracking.

Yes, basically you can, and it's not the package manager text-frontend
that keeps me using debian, it's the technical quality of the
distribution.

> > And yes, such an upgrade works just fine in multi-user mode when done right.
> > Even if you lock out all users and terminate services, I see no need to
> > actually do a reboot or switch to single-user mode.
> 
> Emphasis on "when done right".  And "if everything is like apt expected
> it" omitted.  No package manager can find out every extension I have
> applied to my system and what consequences major modifications of the
> system will have for these extensions.

If you have things installed manually in /usr/local that might break
with an upgrade, it's your responsibility to make sure they work. Me, I
make them debian packages and instantly notice when their dependencies
break.

> As for the reboot: I'm neither paranoid nor windows-minded, but I want to
> be sure that my system will reboot properly after a major upgrade, no
> matter whether that upgrade has been prepared by Debian, RedHat, SuSE or
> whatever folks.  I would even reboot a Debian system after exchanging
> important shared libraries.

There is no need to reboot a gnu/linux system after an upgrade, unless
you do something major, like going from a.out to elf. A good shared
library upgrade also upgrades all the software that requires upgrading
(with glibc you don't get a lot of backwards compatibility, so you need
new binaries).

> To come back to the topic of this list, I think that a successful
> upgrade of any system (including MiNT) depends much more on the quality of
> the packages than on the particular package management software used.  

That's the beef, of gnu/linux distributions I've dealt with redhat,
suse, mandrake and debian. Only one of those has had the quality. I
guess I don't even need to mention which.

> Dependency tracking has not been invented by Debian.

No, it definitely has not.