[conspire] Ehhh... Linux image problem, ya think?

[Rick Moen]

Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> Nevertheless, and this is not a fact that I like, it is definitely the
> de facto standard UNinstallation tool for installed .pkg packages.

Again, quite a lot of software isn't installed from .pkg files --
because there is no enforcement, either by conformance testing or by
cultural expectation.

> Oh, it is most definitely very poorly developed. As for being "unreliable
> in practice," that can describe RPM as well, and if you include package
> systems abused by clueless sysadmins, dpkg too.

No, there's quite a huge difference.  The RPM/dpkg regimes of distros
based on those are a prominent, nearly pre-eminent feature that the new 
admin is pointed to forcefully -- and routine software installations are
expected to be compliant by custom and culture.  Going outside those
regimes for installation and maintenance (even only by fetching packages
from out-of-the-way sources) requires a very definite act of will that,
by design, should leave admins with the nagging feeling that they're
doing something questionable that might be risky.  

If the admin heeds that nagging feeling and doesn't venture outside the
regime without very compelling reasons, then he/she will find it _very_
reliable in practice.  In the alternative, after the admin does
otherwise and shoots a hole in his/her pedal extremities, whole
communities will gladly point out that fact and suggest how not to do
that again.

None of that is true on OS X.


> The lack of coherence is an attribute not of the package management
> system, but of the larger filesystem hierarchy design that the system is
> built around, which compromises between the coherence of a Unix filesystem
> hierarchy and the lack of coherence in Mac OS.

No, that's really quite irrelevant, in the most literal sense of the term:  
A proper package-management regime knows where all of a package's
compenents went, irrespective of hierarchy design.  You can have a
strict hierarchy, a loose hierarchy, or complete anarchy, and the 
regime still works equally well.


> I have not forgotten that, nor have I forgotten how mind-bogglingly
> non-trivial it was to accomplish a full system rebuild of 6.0.x or 7.x
> (or even worse, a 6.0.x/7.x dual boot system, which was not uncommon for a
> while). Any place that had a concentration of people even slightly
> experienced in such system rebuilds saw a disproportionately large number
> of people needing help with such. Everybody else just made do with their
> screwed-up systems.

The point, which I said explicitly, is that a system so badly screwed up 
as to need a full system rebuild is hardly "something unique to the
Windows world".


> Correct, and this further illustrates and supports my above claim.

No, it was a _digression_ from that discussion.  

Although exhausted storage was, as mentioned "the _most_ typical" MacOS
user's hard disk problem, I fairly frequently had to reinitialise 
HFS volumes on account of virus problems (not so far a significant
problem on OS X, by contrast) or other causes of systemic damage to 
critical system files/folders.  

Now, you might say that, typically a Mac _OS X_ HD never gets
reformatted during the entire life of the HD in that machine, and that 
the installed _OS X_ never gets reinstalled.  (In that sense, it's 
a pretty typical *ix.)  However, that's not what you said.


> > Actually, the need for package management exists irrespective of that.
> 
> Not sure how that follows from what I said here...

See above:  Whether there is a specific filesystem hierarchy or not, 
a proper package system remains desirable regardless.


> When I say that it was traditionally a need nobody had, I'm
> referring to early traditions from before networking entered the fray in
> any real way, which carried over into the networked world you describe
> despite changing needs.

OK, noted.  I know the mindset well.  I just never found it to be a
reasonable viewpoint.


> The pieces of software themselves are very fundamentally different topics,
> yes. The ways people think about them are not.

I'm trying to follow your point, here, and thus far not getting it.
Honestly, probably my fault.


> Comparing Mac OS's disdain for package management to the way Slackware
> used to treat the same is apples and oranges. And Slackware is just an
> example here.

Huh?

I hope you don't think I'm much of an admirer of Slackware's installpkg
/ *.tgz regime, where there's sort-of a package database, but no record of 
dependencies (unless one uses Swaret).  Still, at least there was that
much.  On OS X, you're talking about a situation where a
behind-the-scenes system facility exists that installed software can
talk to but often doesn't, and no local-admin access to or even
knowledge of that information without fetching and installing
third-party proprietary tools.

Again, I'm really not following your point.  Sorry.


> That depends on exactly how you choose to define "locally-installed
> software" and on the exact manner of installation.

I saild "_unmanaged_, locally-installed software", i.e., software
installed outside the system package regime.

So, if you're saying that's a worse idea on Ubuntu than on OS X, I am
absolutely not seeing it.  Seems like the same problem -- except that,
for practical purposes, _all_ software installed on OS X is unmanaged
(since there's effectively no real use of the regime you pointed to
and effectively no admin access to it within reason).