On Thu, 3 Jul 2008 19:59:58 +0200
a b <[EMAIL PROTECTED]> wrote:
> > I can only think of one instance where this
> > behavior makes sense, but haven't dealt with IRIX to know if that's
> > what you mean. Basically, the only time an OS update should *ever*
> > muck with third party software is if the package in question was built
> > by someone who's using it for an out of date rev of the OS, knowing
> > that a later rev of the OS will provide a compatible replacement.
> > Other than that, upgrading the OS should leave the third party
> > software alone. That includes the case where I skip over any revisions
> > the package author designated as suitable for replacing his package.
>
> Example
>
> sgi delivered (if my memory serves me correctly) openssh.
> When I comiled my own OpenSSH, which was newer, I also packaged it as
> openssh.sw, and inst(1M) picked it up as an upgrade, since the internal rev
> was higher than that of sgi's own openssh.sw.
>
> When it was time to go from IRIX64 6.5.15 to 6.5.16, sgi's version of
> ssh.eoe.ssh naturally had a higher revision, and so, inst(1M) correctly
> marked the openssh.sw.* subsystems for upgrade.
This is the single case I mentioned above where that's what you want
to have happen. Basically, you're providing a custom-built upgrade to
part of the OS, and will go back to the stock parts when they catch up
to the reveision.
> Perfect. I don't believe things could have possibly worked out any better
> than that.
True. On the other hand, I find that things are *seldom* that straightforward.
> My supposition was, among other things, that NOBODY, and I do mean
> NOBODY knows IRIX better than sgi (same logic applies to Sun and
> Solaris, IBM and AIX, and hp and HP-UX). Going in position with this
> kind of thinking, sgi delivered ssh.eoe.* subsystems that were
> perfectly crafted for their operating system.
Um, so why did you upgrade the openssh that came with the system? At
least, that's what I read you as having done. In my experience, that's
a recipe for disaster with most non-trivial packages, because the
people who built the system version have added some very carefully
thought-out extensions/plugins/whatever to their version of the
package, and installing an upgrade will lose those, and break any part
of the system that needs them.
Of course this cuts the other way - it's common for my custom version
of some package to not only be more up to date, but to include
plugins/extensions/etc that aren't part of the base package. If the
packaging system comes along and replaces my install because it has a
newer one, it's going to break anything that depends on those
modifications.
Possibly "namespaces" solves this. I'm used to packages that don't
care using the most recent available, and packages that do being able
to specify whether to use the system version or the matching
repository version.
> And they did. Things just worked, beautifully. Sun really does the same
> thing, at least we should credit the engineers there for attempting to do so.
> They don't always manage to do it correctly because the open source software
> is inherently unstable and mostly not well through through like traditional
> products are, but they are getting better and better at it.
>
> P.S. you actually made me power my Octane on, after such a long time. Picture
> speaks a thousand words; /tmp/install is NFS mounted from a Solaris 10 (!)
> system, serving out IRIX media:
>
> # inst
>
> Default distribution to install from: /tmp/install/IRIX/6.5.30-3of3/
>
> For help on inst commands, type "help overview".
This really does remind me of portugprade on FreeBSD, except it's much
more polished. But that's only to be expected.
> This is what the future of Solaris could be like.
Well, some people will hate it because it's not point-n-drool. Being
literate, that doesn't particularly bother me.
> Am I still being ambiguous?
No, just not as good as what I'm used to. Or maybe the issues never
arose, so I didn't see them.
In particular, was there a phase where it offered to upgrade any
package that depended on the new libraries to use them instead of the
old ones? Does it just quietly save the old versions as well, rather
than offering that as one of the options? If so, how do they get
cleaned up when nothing needs them?
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
