Re: [PLUG] Linux and package managers/repos

[Matt Mossholder <matt@mossholder.com>]

On Tue, Mar 22, 2011 at 4:28 PM, <bergman@merctech.com> wrote:
>
> The pithy ruminations from JP Vossen <jp@jpsdomain.org> on "[PLUG] Linux and pa
> ckage managers/repos" were:
>
>
> =>
> => To update Windows you use WindowsUpdate, which was tacked on at the 11th
> => hour because no one updated anything and thus left gaping holes
>
> Citation, please.
>
> I'm most familiar with RPM-based distributions, but the "repository"
> concept (particularly "yum" as opposed to the proprietary RHN) came
> pretty late in the hi story of using RPMs to package the files used in a
> distribution. A quick search seems to show that "yum" appeared in about
> 2005, as a successor to "yup" (c. 2001), well after the RPM format was
> determined (c. 1998)[1].
>


Mandrake had urpmi in place for this at least as far back as 2000 [1].
I agree that network based file installation and upgrades were an
afterthought, but the file format doesn't really have much relevance
to when the feature appeared.

With regards to WindowsUpdate, here's what Wikipedia has to say:

"Windows Update was introduced as an InternetÂweb siteÂwith the launch
ofÂWindows 95. A link to Windows Update on the Start Menu gave access
to additional downloads for the operating system. At the time of
Windows 98's release Windows Update offered additional desktop themes,
games, device driver updates, and optional components such as
NetMeeting.[1]ÂWindows 95ÂandÂWindows NT 4Âwere retroactively given
the ability to access the Windows Update website, and download updates
designed for those operating systems, starting with the release of
versions of Internet Explorer 4 for those operating systems. The
initial focus of Windows Update was on free add-ons and new
technologies for Windows; security fixes forÂOutlook Express, Internet
Explorer and other applications appeared later, as did access to beta
versions of upcoming Microsoft software, most notablyÂInternet
Explorer 5. Fixes to Windows 98 to resolve theÂYear 2000 problemÂwere
distributed using Windows Update in December 1998. Microsoft
attributed the sales success of Windows 98 in part to Windows
Update.[2]"

> => been baked in to the very core of what a "distribution" is. ÂAnd as long
>
> What is the "core" of a distribution? You seem to be conflating the concepts of
> Â3rd party products, the package management interface, and a lot of anti-Window
> s bias.

I think this applies more to Debian-based distributions than it does
to RPM-based distributions. Debian-based systems tend to see most
components as removable and interchangeable, which impacts the way
that the distro is organized to a larger extent than it does with
RPM-based distros, which in my opinion tend to be less modular.

>
> => as you stay inside the package manager, 'sudo aptitude update && sudo
> => aptitude full-upgrade' updates *everything* on the system...bang...done.
>
> Usually. Unless (as happened to me last night), "apt-get upgrade" breaks
> because the Nvidia driver (a piece of "not free as in freedom" software,
> from it's own repository, but available through the same interface as
> the other free & non-free software on the machine) didn't get upgraded
> to match the new kernel.
>
> Or, on some of my servers, when the same kind of issue happens with
> the Qlogic drivers (proprietary, free-of-charge, available from 3rd
> party repositories via the same "yum" interface used to manage other
> components).
>

Someone didn't setup the dependencies to prevent the older nVIDIA
driver from being used with untested kernels. It is a trade-off...
often the older drivers will work ( if your distro uses something like
DKMS), but there is no guarantee.

> => Â (Or 'yum upgrade' for Red Hat-ish or 'emerge world' (Rich, right?) for
> => Gentoo.)
> =>
> => So what does "stay inside the package manager" mean? ÂIt means that you
> => don't install stuff from source (except Gentoo, but that *is* the
> => package manager :), you install from the repo. ÂOK, but what if you need
>
> What "repo"...there are many repositories...some free-as-in-beer,
> some free-as-in-speech, some neither. The fact that a single interface
> (apt-get, or yum, or emerge) can reference multiple repositories is
> a tremendous convenience vrs. the WindowsUpdate interface, but it's
> not fundamentally different than using a single Windows product (SCCM,
> for example) to manage updates that are distributed from multiple sources.
>

Actually, it is fundamentally different.  SCCM doesn't, as far as I am
aware, monitor for new updates from various sources, and pull them
down on request.  It can only push them out to the managed systems.
And the other thing to keep in mind is that most people test software
before they push it out through SCCM.  The issues you listed earlier
with proprietary drivers _might_ have been avoided if they were tested
first.


> => How long would a search for a similar tool take for Windows? ÂYou have
> => to Google it, read various descriptions scattered all over the web,
>
> Huh? If I was doing this on any platform, I'd still do some research
> (google, reading package descriptions available through the package
> manager, etc.) before blindly installing software. You're citing a false
> distinction between the Windows and Linux.

This is just a difference between your personal workflows. I tend to
use the package manager if I just want "something that does X", and
Google if I am looking for something very specific, or if the package
manager is failing me.

>
> => choose from possibly hundreds of analysis-paralysis-inducing choices,
>
> You seem to be arguing that having just 2 choices for a solution is better than
> hundreds... Maybe, but someone could make just the opposite case.
>

JP actually listed 6 solutions, that are packaged and available, with
specific, consistent descriptions of each, typically without all the
duplicates. (I say typically because sometimes there are multiple
concurrent releases of a program).

> => download it, hope it's not malware, figure out how to install it, try
>
> Um, how do you know that the thing you just installed on your Linux system isn't malware?
>

Because it comes from a source that you have chosen to trust, and the
packages typically have signatures so you know they are intact.


> How does the issue of "figuring out how to use an application" enter into
> the discussion about repositories & package managers, other than as a red
> herring which indicates your bias for or against a particular environment?
>

JP said figure out how to install it, not figure out how to use it.
He did mention "try it" but that step was the same in both processes,
so it is a wash.

> => it, then figure out if it will cleanly uninstall (probably not). ÂNot
> => for me...
>
> Again, this is a false distinction...the package management interface provides
> little assurance that something will cleanly uninstall.
>

It does for me. Especially since most distros will accept bugs for
packages that don't cleanly uninstall.

> Ironically, I'd actually argue that Windows is better at managing packages that do not come from Windows. If you want to install a Linux package that isn't packaged for your distro, you've got a few choices:
>
> Â [A] Âinstall the native version (ie., from source or the binary that came with the package). If you're
> Â Â Â Âvery luck, and you keep the Makefile for ever, there might be an uninstaller.
>
> Â [B] Ârepackage the native version in your own distro's packaging format (this is a path to madness for
> Â Â Â Âmost people...and still says little about a clean uninstall)
>
> Â [C] Âuse a tool like checkinstall[2] to do the above task [B]. Much easier, but it still doesn't do much
> Â Â Â Âfor the uninstall beyond removing files (ie., no reversal of any system files that were changed,
> Â Â Â Âetc.)
>
> In Windows, most installed packages--wether from the Windows distribution or not--show up in the "Add & Remove" control panel (ick...) and there's at least a place to try to begin the removal.
>

If you are going to resort to source, then you are making the explicit
decision to forgo the niceties of packaged programs. The exact same
thing can be said about windows programs that are distributed as
source.

With regards to programs distributed as binaries, they almost always
fall into a few categories: 1) those that follow standards and want to
live in /opt, 2) those that just want a directory to live in or 3)
things that are only making a token gesture to supporting FOSS, and
should probably be avoided anyway ;)

> =>
> => Notes:
> => * I prefer the command line. ÂThere are various GUI tools that do all of
> => this too. ÂThe names change based on distro and version of distro. ÂPoke
> => around...
>
> Hmmm...so the programs change with the distro & version...but that's not
> counted as a negative....compared to, for example
> "windowsupdate.microsoft.com"?
>
>
> By the way, I firmly agree with your preference for Linux (and it's package
> managers) over Windows. My issue here is with the specious reasoning & examples.
>
> Mark
>

[1]Âhttp://www.redhat.com/archives/rpm-list/2000-December/msg00136.html
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug