brent saner on 22 Mar 2011 15:20:44 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Linux and package managers/repos


" 'apt-get upgrade' breaks..."
use aptitude; it handles reverse dependencies better. :) if old habits
die hard, then do:  export i=`which apt-get`;mv $i $i.orig;ln -s
`which aptitude` $i   (most likely won't survive between apt version
updates, though). also, that was Nvidia's fault. both Nvidia and ATI
are notorious for being slow to patch their drivers to match new
kernel releases. i believe JP's point here was "don't add any custom
repos and you have a great chance of things Just Working(TM)". both of
the cases you presented used out-of-distro repos.

"nothing intrinsic about the technical concept of the repository"
debian still, i believe, has free vs. non-free etc. repositories.
gentoo has a "LICENSE:" field in the ebuilds. so some actually DO
provide a mechanism for /specifying/ "free"-ness. whether all userbase
or package maintainers take ADVANTAGE of it, however, is something we
could comment on. :)

"If you want to install a Linux package that isn't packaged for your
distro"  see: http://sourceforge.net/projects/pdv pretty handy at
least for installation. just about everything in source these days has
a target for make uninstall. if it doesn't, it probably only build one
or two files (binary and library. or just binary, even)... which, if
you keep things localised (i.e. in ~/bin, /opt/bin, /usr/local/bin,
etc.) shouldn't be too hard to track down. and no registry changes to
undo, etc. windows .exe self-installers do not give you a --prefix=
option. the best they have is installation path- which doesn't
gaurantee that it didn't install things into system32, etc.

On 3/22/11, bergman@merctech.com <bergman@merctech.com> wrote:
> The pithy ruminations from JP Vossen <jp@jpsdomain.org> on "[PLUG] Linux and
> pa
> ckage managers/repos" were:
>
>
> 	[SNIP!]
>
> =>
> => Well, it actually does get a lot of press, but under a different name
> => and in a different context.  The one that gets press is called an "app
> => store," but Linux has had that since Debian (at least, possibly longer?)
> => except it's called a "repository" and it's full of free (as in no cost
> => and freedom) software.
>
> Repositories aren't necessarily full of "free" software...there's
> nothing intrinsic about the technical concept of the repository (or an
> "app store") that has any implication about the cost or freedom of
> the products. There are repositories for closed-source (proprietary)
> software that are free in cost, and every flavor in-between.
>
> 	[SNIP!]
>
> =>
> => 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].
>
>
> 	[SNIP!]
>
> =>
> => On the other hand, since not too long after the dawn of Linux, this has
>
> Um, how do you define "dawn of Linux" or "distribution"? I began with
> slackware, with a version number in the 0.9x range. The "distribution"
> was little more than a bunch of tar files and "Make".
>
> RedHat was a big improvement because of RHN, but that certainly didn't mean
> it was a very robust or open package manager.
>
> => 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.
>
> => 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).
>
> =>   (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.
>
> 	[SNIP!]
>
> =>
> => So, todays example.  I got an email at work discussion a non-intuitive
> => customer name issue, and I thought I'd be funny and try to do an anagram
> => of it.  But the name was 19 characters, which is too long for the
>
> Here's a good challenge...perfect for someone who enjoys shell scripting:
>
> 	Assuminng the presence of /usr/dict/words, do the anagram search
> 	using only "standard" shell tools (bash, sed, grep, awk, sort, wc,
> 	etc.) [note the absence of perl, python, ruby, etc.].
>
>
> => web-based anagram engines.  So in literally 10 minutes (read the
> => timestamps) I:
>
> I love the example!
>
> => 	1) Searched for apps to solve my problem
> => 	2) installed one, took a few minutes to realize didn't like it
> => 	3) installed the other, took a few minutes to use it
> => 	4) purged the one I didn't like, and am sure it's really gone
> =>
> => 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.
>
> => 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.
>
> => 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?
>
> 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?
>
> => 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.
>
> 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.
>
> =>
> => 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://magazine.redhat.com/2007/02/08/the-story-of-rpm/
>
> =>
> => Later,
> => JP
> => ----------------------------|:::======|-------------------------------
> => JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
> => My Account, My Opinions     |=========|      http://www.jpsdomain.org/
> ___________________________________________________________________________
> 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
>


-- 
Brent Saner
504.338.1513

http://www.houseoftherisingson.org
___________________________________________________________________________
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