Re: [BLUG] newbee

Yes, it's convenient to do in-place upgrades but you have to calculate
the risk. Also in-place too many generation might result in unsolvable
dependencies (or years of leftovers :-)); e.g., you have an old package
you need that depends on old python 2.4 while the new system supports
2.6. Unless you have a good way for several versions of python (or
other packages) to co-exist. Do you still do in-place upgrade when the
supported filesystem gets changed (and not as easy as going from ext2 to
ext3?) --Shing-Shong

>> So now I'm on CentOS mostly for its long term support and stability.
>> I've been dabling with Debian and Ubuntu a bit on virtual machines, but
>> nothing serious yet.
>>
>
> This is one area I think OpenBSD really shines in. I've done in-place
> upgrades with other systems, but none have been as detailed and as
> straightforward as OpenBSD.
>
> Aaron W. Hsu
>

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, 10 Nov 2009 20:17:33 -0500, Mark Krenz <mark@slugbug.org> wrote:

> So now I'm on CentOS mostly for its long term support and stability.
> I've been dabling with Debian and Ubuntu a bit on virtual machines, but
> nothing serious yet.

This is one area I think OpenBSD really shines in. I've done in-place
upgrades with other systems, but none have been as detailed and as
straightforward as OpenBSD.

Aaron W. Hsu

--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, 10 Nov 2009 12:11:52 -0500, Steven Black <blacks@indiana.edu>
wrote:

> The best way to muck up any system is to install external packages.

And therein lies the rub: the complicated dependency repositories often
demonstrate fragility when faced with external packages. This results in
an usually flawless installation process for internal packages, but a good
deal of overhead for external packages.

> Now down-loading a third-party DEB file *usually* has problems. I've
> found myself downloading the source when a site offers a DEB package,
> just so I could make the DEB less broken.
>
> I never use third-party packages, so I never really have problems.
> When I need an external package I get the source and use GNU Stow.
> GNU Stow is my friend.

This is one of Slackware's strengths. When you really want some particular
package or version of a package that doesn't exist in a repository, you're
usually stuck with complicated work to bring that package in, and
oftentimes, the packaging that you can get isn't right, so you have to do
it by hand. Doing it by hand in a system like deb is pretty involved.

In Slackware, it is quite common to grab external packages, and the
process has evolved into SlackBuilds. Because the packaging system is
fairly simple, it's very easy to make packages for it, and SlackBuilds are
a way to easily make sure that the package does what you want. The
overhead associated with building one of these packages is much less than
something like Debian or BSD ports. I have 20 - 30 external packages
installed on my Slackware box, and these are all easily maintained through
SlackBuilds.

> The big difference there is that with DEB-based systems you rarely
> actually need to use external repositories. :) Using stable versions of
> DEB-based distributions I've never run in to missing dependancies.

Indeed, in large repositories that are available for Debian based systems,
you usually don't need to do external packages, provided that you can live
with the versions in the system. Fortunately, this works well for most
people. :-) But boy, it's a pain when you have to go out of the "norm."

Aaron W. Hsu

--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Wed, Nov 11, 2009 at 12:19:27AM GMT, Kirk Gleason [kgleason@gmail.com] said the following:
> I remember being appalled by RHEL 4 when I wanted to upgrade to RHEL5.
> Having come from Gentoo and BSD (Net and Open), I just couldn't fathom
> having to use CDs to upgrade. As I dove into Deban more and more, I
> thought that my outrage was validated.

I think you're a little spoiled. To be able to upgrade an OS to a new
"major version" without having to even take the machine down for hours
is an awesome feature. In fact its such an awesome feature that I made
the mistake of setting up a couple servers at Suso with Gentoo. What I
forgot to consider is that being servers, you need to make sure that you
can roll back changes to packages in case some upgrade doesn't work out.
It never really burned me but its made me get stuck in one place because
I'm afraid to upgrade and mess something up and not be able to roll
back. Gentoo makes this practically impossible and if you wait too long
to upgrade, you can find yourself with a machine that doesn't have the
current versions of its packages in the distribution directory. Gentoo
development simply moves too fast to use on a server. Plus, constantly
compiling stuff bogs the server down for other users who don't really
care about it being Gentoo or not.

So now I'm on CentOS mostly for its long term support and stability.
I've been dabling with Debian and Ubuntu a bit on virtual machines, but
nothing serious yet.

--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

I remember being appalled by RHEL 4 when I wanted to upgrade to RHEL5.
Having come from Gentoo and BSD (Net and Open), I just couldn't fathom
having to use CDs to upgrade. As I dove into Deban more and more, I
thought that my outrage was validated.

In the end, that, combined with my hatred of RPM, was the reason that
one of the companies that I support completely abandoned RH and moved
to Ubuntu server. Of course the other company is locked in by an
unsupportive vendor, so I always have to check myself whenever I log
in. So many times I have been scratching my head trying to figure out
why /etc/network/interfaces wasn't there.
Sometimes I think that RHEL/CentOS is the Newman to my Seinfeld ....
Then a windows server will crash.

On 11/10/09, Steven Black <blacks@indiana.edu> wrote:
> On Tue, Nov 10, 2009 at 04:16:45PM -0500, Steven Black wrote:
>> To my knowledge there is only one way to update a Debian-based system,
>> and that is online. Booting from CD is fine if you need to repartition
>
> I meant to say "live" instead of "online".
>
>> and reinstall, but to my knowledge Debian has never explicitly supported
>> booting from a CD to perform an update. Sure, it might work, but you'd
>> be better off doing it live and using the CD as a package store.
>
> I used the correct word later, so hopefully it made sense.
>
> Cheers,
> Steven Black
>
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
>

--
Sent from my mobile device

Kirk Gleason
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, Nov 10, 2009 at 04:58:05PM -0500, Barry Schatz wrote:
> I can't even imagine how you would do a dist-upgrade from a liveCD in
> Debian. The closest I can get to that is either chroot-ing into the
> installed system or bind-mounting parts of /var to know which packages
> are installed.

I was imagining it as booting from the CD and skipping some stages. Note
that this wouldn't even be possible on any of the GUI-installer CDs,
(they totally lack the functionality) but with the older text-based
interface (as used by Ubuntu's 'server' and 'alternate' CDs and the most
recent Debian netinst/CD1 I used) you can skip out to a menu and skip
certain steps. (Or switch to a VC, and perform specific commands by hand
to meet the requirements of a step.)

The key requirement is whether the basic infrastructure is laid out so
as to over-write what is already there or whether it doesn't install
things to the filesystem until it starts processing the packages. If
it doesn't, say, reinitialize your dpkg database and stomp on your
/etc/passwd file then it just might work.

> PS. For the uninitiated, Debian has five repositories: oldstable,
> stable, testing, unstable and experimental. stable is the latest
> released version, oldstable is the previously released version, testing
> is the staging ground for the next release, unstable is software deemed
> acceptable for distribution that hasn't been in the archive (repository)
> long enough or has too many bugs to go into testing, and experimental is
> beta or pre-release software. stable is more appropriate for production
> systems and testing is better for hobbyists who need more current
> versions of software.

Well, sometimes they don't have 'oldstable'. I don't know if their
current release strategy will mean they're keeping it around, but
previously 'oldstable' had a limited life-time before it fell off the
mirrors. I imagine that with a quicker release cycle there would be more
demand for it.

Also, sometimes they have 'frozen' instead of 'testing'. They have
'frozen' when they're preparing for release and they're in a "feature
freeze" which is when only bug fixes are allowed (no new packages or
new versions of packages without special approval).

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

I can't even imagine how you would do a dist-upgrade from a liveCD in
Debian. The closest I can get to that is either chroot-ing into the
installed system or bind-mounting parts of /var to know which packages
are installed.

Then again, I haven't done a real dist-upgrade in a long time. I use a
combination of testing and unstable packages and treat it like a rolling
release.

-Barry

PS. For the uninitiated, Debian has five repositories: oldstable,
stable, testing, unstable and experimental. stable is the latest
released version, oldstable is the previously released version, testing
is the staging ground for the next release, unstable is software deemed
acceptable for distribution that hasn't been in the archive (repository)
long enough or has too many bugs to go into testing, and experimental is
beta or pre-release software. stable is more appropriate for production
systems and testing is better for hobbyists who need more current
versions of software.
A "rolling release" is when the distribution doesn't have official
release milestones, but updates the individual packages as they are
deemed worthy. Arch Linux does this, I believe.

Steven Black wrote:
> On Tue, Nov 10, 2009 at 04:16:45PM -0500, Steven Black wrote:
>
>> To my knowledge there is only one way to update a Debian-based system,
>> and that is online. Booting from CD is fine if you need to repartition
>>
>
> I meant to say "live" instead of "online".
>
>
>> and reinstall, but to my knowledge Debian has never explicitly supported
>> booting from a CD to perform an update. Sure, it might work, but you'd
>> be better off doing it live and using the CD as a package store.
>>
>
> I used the correct word later, so hopefully it made sense.
>
> Cheers,
> Steven Black
>
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
>

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, Nov 10, 2009 at 04:16:45PM -0500, Steven Black wrote:
> To my knowledge there is only one way to update a Debian-based system,
> and that is online. Booting from CD is fine if you need to repartition

I meant to say "live" instead of "online".

> and reinstall, but to my knowledge Debian has never explicitly supported
> booting from a CD to perform an update. Sure, it might work, but you'd
> be better off doing it live and using the CD as a package store.

I used the correct word later, so hopefully it made sense.

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, Nov 10, 2009 at 02:58:34PM -0500, Shei, Shing-Shong wrote:
> > That is odd. As I've mentioned, I've never seen that happen. Any
> package in particular? (And was it the same package each time?)
>
> No very specific but at least once I was adding lot of packages not
> installed by default (including some Asian fonts and input methods.)

Sounds like you didn't have the Multiverse repository enabled.

The 'Universe' repository includes non-Canonical free and open-source
packages. The 'Multiverse' repository contains the non-free or
patent-encumbered packages. I know there's at least one input manager
that is in the Multiverse repo. It likely was just set as "Recommends",
but as I said, by default Recommends is treated as "Requires".

Why do I know this? Back when I started using Debian I wanted to know
about all the great packages available, and during upgrades I always
paid attention to the new packages. At this point it is practically a
compulsion. At one point or another I've read the descriptive text on
every package available. (Though I don't pretend to actually retain
much of it, occassionally I recall something useful.)

> My got feeling is that it's always riskier to do a live-upgrade then a
> standalone upgrade. Weird things can happen when you upgrade important
> shared libraries such as glibc -- the old ones are still open by
> utilities already running while the new ones might kick in by new
> running programs -- e.g., there is a bug in, say, 'rm' that is not
> triggered by the old glibc. Now the new glibc is in place and the new
> runs of 'rm' will start using the new shared libraries and the bug got
> triggered. When it comes to our important servers, we either do a fresh
> install or, if upgrade route is necessary, a standalone upgrade.

At this time I don't recall if I did a live update when migrating from
a.out to ELF or not. I do know that during that time my resources were
limited and so if it were an option, I would have done it. (My first
Linux distro was a.out, but I may have still been using Slackware during
the switch... and I think I may have done a reinstall for a Slackware
update once to go from the CD-shipped to the then-current version.)

I recall once being shocked and horrified to find out that with RedHat
I'd need to boot to a CD to perform an upgrade. (When that was, I can
not say, it may well have been 12 years ago.) I was always only ever
talking about live-upgrades, as with Debian I have never done any other
kind in my ~13 years of using it.

To be safe, you want to perform a full update (dist-update in Debian
parlance) on the system first (rebooting the system if the kernel or
various important libraries were updated), then reboot the system when
the update is complete...

I don't know how the developers work over in RPM-based distributions,
but in the DEB-based world development happens on an open repository
so that if upgrading libc were to break package FOO then the entire
developer community would see it long before I -- a mere user of the
'stable' distribution -- would.

To my knowledge there is only one way to update a Debian-based system,
and that is online. Booting from CD is fine if you need to repartition
and reinstall, but to my knowledge Debian has never explicitly supported
booting from a CD to perform an update. Sure, it might work, but you'd
be better off doing it live and using the CD as a package store.

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, 10 Nov 2009, Shei, Shing-Shong wrote:
[....]
> My got feeling is that it's always riskier to do a live-upgrade then a
> standalone upgrade. [....]

Ah, but it's *so* much easier if you can bear the risk!

Reports about Fedora's "preupgrade" command on Gmane's
fedora.general list have been mixed, as you may know. Iiuc, what
it does is download and position the new stuff -- and let it sit,
till the next reboot, which can be at the user's convenience.

Fwiw, as a complete and inherent subtechnoid (perhaps a
lucky one), I've been very pleased with it so far. I'll certainly
try it again, about the week after next, as soon as the F12
bandwidth has had a chance to diminish.

--
Beartooth Staffwright, Not Quite Clueless Power User
Remember I know little (precious little!) of where up is.

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

> That is odd. As I've mentioned, I've never seen that happen. Any
package in particular? (And was it the same package each time?)

No very specific but at least once I was adding lot of packages not
installed by default (including some Asian fonts and input methods.)

> Now, if you never got the network up it would make sense.
>
The network is definitely up and I always do the update right after
first boot up. I might have chosen some 'weird (albeit from Ubuntu)'
packages just like those I have installed on RH.

> I've heard that it was doable, though I did not know it was doable
> pre-Fedora. Still, I contrast "doable" with the fact that network-based
> live-upgrades have been the *recommended* upgrade procedure for
> DEB-based systems for the past 15+ years.
>
My got feeling is that it's always riskier to do a live-upgrade then a
standalone upgrade. Weird things can happen when you upgrade important
shared libraries such as glibc -- the old ones are still open by
utilities already running while the new ones might kick in by new
running programs -- e.g., there is a bug in, say, 'rm' that is not
triggered by the old glibc. Now the new glibc is in place and the new
runs of 'rm' will start using the new shared libraries and the bug got
triggered. When it comes to our important servers, we either do a fresh
install or, if upgrade route is necessary, a standalone upgrade.

Thanks,
Shing-Shong

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, Nov 10, 2009 at 02:35:34PM -0500, Steven Black wrote:
> Debian had 5 DVDs of binary content. Ubuntu is based upon Debian, but
> they do support a subset of the packages. On the CD it should be mostly
> self-contained and mostly Canonical supported packages. It likely
> increases some popular Universe packages -- however once you start
> going that route the sky is the limit when it comes to dependancies.

That should have read:

includes some popular Universe packages -- however once you start

-- Steven Black
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, Nov 10, 2009 at 12:56:29PM -0500, Shei, Shing-Shong wrote:
> > These were packages shipped with Ubuntu or external packages?
>
> Everything from Ubuntu CD (and its repository.) Never got far enough to
> need external packages. :-)

That is odd. As I've mentioned, I've never seen that happen. Any package
in particular? (And was it the same package each time?)

Now, if you never got the network up it would make sense.

Debian had 5 DVDs of binary content. Ubuntu is based upon Debian, but
they do support a subset of the packages. On the CD it should be mostly
self-contained and mostly Canonical supported packages. It likely
increases some popular Universe packages -- however once you start
going that route the sky is the limit when it comes to dependancies.

(For quite a while the Debian folks have had a "popularity-contest"
package which sends information about the installed packages to the
Debian folks. This is useful not only for cute graphs, as it allows them
to order the packages across the 31 binary CDs in the order that they
are most popular. Since any Debian-derived package can easily use this
package as well as the CD/DVD/BD creation logic that leverages it it
should be no wonder that Ubuntu would use it as well.)

The only place I can see an issue arise is if the network never got up,
and the package manager was left at the default of treating "Recommends"
as "Requires". (It does make things work better for GUI-users -- but
only when you have full access to the repo.) This would mean that things
that are not actually required -- but increase functionality in some
way -- are treated as required. This means that if the network is down
you can have a dependancy issue even if you're only are trying to use
Canonical-supported software. It's a minor configuration change to
prevent "Recommends" from being treated as "Required".

> BTW, I have upgraded many Red Hat systems (from non-RHEL era to RHEL as
> well) many many times. I did run into trouble couple times (mostly
> caused by third party RPMs.) But with so many upgrades been done, the
> number is pretty minor. I have not tried to upgrade on a live system
> (although in theory it's no more different than applying patches for,
> say, kernel or glibc.) So it's definitely doable. But most vendors
> won't recommend doing upgrade for liability reason.

I've heard that it was doable, though I did not know it was doable
pre-Fedora. Still, I contrast "doable" with the fact that network-based
live-upgrades have been the *recommended* upgrade procedure for
DEB-based systems for the past 15+ years.

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

> These were packages shipped with Ubuntu or external packages?

Everything from Ubuntu CD (and its repository.) Never got far enough to
need external packages. :-)

BTW, I have upgraded many Red Hat systems (from non-RHEL era to RHEL as
well) many many times. I did run into trouble couple times (mostly
caused by third party RPMs.) But with so many upgrades been done, the
number is pretty minor. I have not tried to upgrade on a live system
(although in theory it's no more different than applying patches for,
say, kernel or glibc.) So it's definitely doable. But most vendors
won't recommend doing upgrade for liability reason.

Cheers,
Shing-Shong

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

Steven Black wrote:
>
> My big problem with RPM-based distros is that the RPM packaging system
> has been a huge thorn in the RedHat developer's side for years. Their
> management always made other things a priorities until a group of the
> developers got so fed up with it that they started Foresight.
>
> That is, the folks most familiar with RPM-based distros think the whole
> RPM-based packaging system stinks and should have been replaced in-whole
> years ago.

I'm pretty sure that's where Bill Reynolds aka Texstar of PCLinuxOS come
down on the subject. When he decided to strike out on his own with
PCLinuxOS, it remained an rpm system based on Mandriva, but he went with
apt-for-rpm/Synaptic as the default GUI package manager.

--
Mark Warner
MEPIS Linux
Registered Linux User #415318

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

Steven Black wrote:
> On Mon, Nov 09, 2009 at 07:44:57PM -0500, Mark Warner wrote:
>> I'd say it's a lot more elementary that a Linux From Scratch build.
>>
>> I start with a base Debian CLI install. The first command I do after
>> logging in for the first time is
>>
>> apt-get install kdm synaptic kdebase
>>
>> and go from there, installing packages with Synaptic.
>
> Oh, that's a lot more advanced than Linux From Scratch.

I meant "elementary" in the sense that even a unsophisticated user like
myself can do it.

--
Mark Warner
MEPIS Linux
Registered Linux User #415318

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Tue, Nov 10, 2009 at 10:59:25AM -0500, Shei, Shing-Shong wrote:
> I am one of those 'that have only used an RPM-based distribution' guy.
> I tried several Ubuntu versions in my VMware a little and had run into
> some problem installing some packages.

These were packages shipped with Ubuntu or external packages?

The best way to muck up any system is to install external packages.

The packages that actually ship with the distro (even the
Community-supported pacakges) have to comply with strict policy
requirements.

> I claim that I am both very experienced (in RPM-based area) and a
> novice (in DEB-based area). Yes, RPM system has its many problems but
> I can get by most of them.

My areas of expertise are the inverse.

My big problem with RPM-based distros is that the RPM packaging system
has been a huge thorn in the RedHat developer's side for years. Their
management always made other things a priorities until a group of the
developers got so fed up with it that they started Foresight.

That is, the folks most familiar with RPM-based distros think the whole
RPM-based packaging system stinks and should have been replaced in-whole
years ago.

> I have also created many RPMs using my own spec files. Bear in mind
> that RPM system (and I believe this holds for any other systems
> such as DEB-based or Gentoo as well) is only as good as the one who
> wrote the spec file. A badly written spec file can screw up many
> things either causing lots of unnecessary dependencies, installing
> files to the wrong location, or having incorrect assumption in their
> post-installation script(s), etc.

That is certainly true.

Now down-loading a third-party DEB file *usually* has problems. I've
found myself downloading the source when a site offers a DEB package,
just so I could make the DEB less broken.

I never use third-party packages, so I never really have problems.
When I need an external package I get the source and use GNU Stow.
GNU Stow is my friend.

> I have run into similar situations with efile in Gentoo, too. In my
> limited experience with Synaptic, there are situations that it could not
> resolve dependency.

The big difference there is that with DEB-based systems you rarely
actually need to use external repositories. :) Using stable versions of
DEB-based distributions I've never run in to missing dependancies.

> So to be fair, RPM-based system is not perfect but I am pretty
> comfortable using it in my daily job. :-)

That's the important part. You need to be comfortable with it. :)

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

I am one of those 'that have only used an RPM-based distribution' guy.
I tried several Ubuntu versions in my VMware a little and had run into
some problem installing some packages. I claim that I am both very
experienced (in RPM-based area) and a novice (in DEB-based area). Yes,
RPM system has its many problems but I can get by most of them. I have
also created many RPMs using my own spec files. Bear in mind that RPM
system (and I believe this holds for any other systems such as DEB-based
or Gentoo as well) is only as good as the one who wrote the spec file.
A badly written spec file can screw up many things either causing lots
of unnecessary dependencies, installing files to the wrong location, or
having incorrect assumption in their post-installation script(s), etc.
I have run into similar situations with efile in Gentoo, too. In my
limited experience with Synaptic, there are situations that it could not
resolve dependency. This situation is especially bad in RPM-based
system as there are so many different repositories (such as rpmfind,
rpmforge, epel, etc.) that use theirs on assumption/rpms that it's
almost impossible to download from one repository and install on your
system without running into some issue (such as you use rpmforge as your
main non-vendor repository and need to install an rpm that's not
available in rpmforge but are in epel's.) So to be fair, RPM-based
system is not perfect but I am pretty comfortable using it in my daily
job. :-)

Cheers,
Shing-Shong

> Anyone that has only used an RPM-based distribution should really try a
> DEB-based distribution at some point. -- Just to see some of the other
> options.
>
> I've heard a bunch of the Redhat Engineers jumped boat and formed
> Foresight Linux: http://www.foresightlinux.org/ I've not used it
> myself, but I do know it uses a package management system that is a
> full generation beyond the (good) package management systems in other
> distributions.
>
> When I try to use RPM-based distributions, I almost always come away
> wondering just exactly who the competition of the product was supposed
> to be.
>
> I mean, with any DEB-based distribution when you install a package it
> will (1) use sane defaults, or (2) ask just enough questions. This
> results in packages that always work when installed.
>
> My experience is that RPM-based systems do not ask questions even when
> they really need to.
>
> Plus you have the whole upgrading thing... DEB-based distributions
> have had in-place upgrades from one major version to the next for 15+
> years. Even current Fedora releases "highly recommend" you perform fresh
> installs instead of in-place upgrades.
>
> Cheers,
> Steven Black
>
>
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] newbee

On Mon, Nov 09, 2009 at 07:44:57PM -0500, Mark Warner wrote:
> I'd say it's a lot more elementary that a Linux From Scratch build.
>
> I start with a base Debian CLI install. The first command I do after
> logging in for the first time is
>
> apt-get install kdm synaptic kdebase
>
> and go from there, installing packages with Synaptic.

Oh, that's a lot more advanced than Linux From Scratch. To get much
value with that, you need to make sure you have Synaptic set to only
download Required packages as if you're not careful, it'll download
Recommended packages automatically, increasing the functionality of
packages with no foresight from you.

In fact, what you're doing is little more than what I did in the 90's
when I got started in Debian. I downloaded the Debian netinstall CD,
installed it, then manually picked the packages to install. Of course,
back then I was using 'dselect', as Synaptic, aptitude, apt-get, even
meta-packages did not exist yet. (IIRC, the DEB packaging format
supported meta-packages, but they weren't used. I can't be sure of that
fact, as I didn't start making packages until much later.)

You may want to check out Aptitude sometime. It's the modern
ncurses-based packaging tool. It allows you to surf around the package
dependancies. That is, in addition to the descriptive text it not only
tells you about the Dependancies, Recommends, Suggests packages, it
also tells you about packages which Depend, Recommend or Suggest this
particular package.

With most GUIs you're stuck with the first of any pair of requirements.
For instance, most web-based CGIs Require "apache2 | httpd-cgi". That
is, in a GUI it will always simply install Apache httpd 2. However with
Aptitude you can expand that line and see every package which provides
either "apache2" or "httpd-cgi". (What would provide "apache2"? How
about any of the 3 current apache2-mpm-* packages -- each of these is a
different multi-processing module.)

With LFS, you start out in a (Linux) hosted environment and build your
target from scratch. Apparently, since I did it they include notes to
create the system from scratch using either their own (LFS) Live CD, or
your own Live CD (provided it includes a development environment).

With LFS the order that you install things matter, as you're compiling
everything from scratch. With autoconf things will successfully build
(simply with reduced functionality) if you fail to build things in the
right order. This also means that you can tweak the configurations of
every package in your system if you so choose. (Do you never use grep's
-P option? Then you don't need to link grep with libpcre.)

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug