[CLUE-Tech] Arch Linux: Thumbs Up!

[Nate Duehr]

On Tuesday 31 August 2004 11:08, Matt Gushee wrote:

> Hey, Mike, thanks for the suggestion, but nope. First of all, I've
> already switched, and I'm not going to switch again for a while.
> Secondly, I know about Debian's packaging system; it was one of the
> major reasons I switched from RedHat to Debian 3 years ago. And it's one
> of the major reasons I've gotten tired of Debian. See, I couldn't use
> apt-get anymore, because every time I tried it would propose to remove
> 91 packages. It wouldn't tell me which ones or why, and there didn't
> seem to be any way to prevent the packages from being
> deleted--positively Kafkaesque.

If you were running "stable" this is damn near impossible.  So you have to 
preface the story by stating that you were CHOOSING to run the unstable 
branch, and thus any breakage was -- expected and that this rick is 
well-documented everywhere on the Debian site, right?

> I've come to believe that the big distributions try to do too much. I
> used to just think that about RedHat--how they try to automate
> everything, which helps a lot of people but causes disasters for a
> significant minority. Debian is different, and in some ways better, but
> I think it tries too hard to standardize the system. Standards are great
> when they are consistently applied and well understood; otherwise they
> just add complexity. For example, Debconf is a great idea, but only a
> minority of packages actually use it ... and how do you tell which ones?
> And even when a package doesn't use Debconf, it often has some
> Debian-specific configuration method, so that you can't rely on the
> program's man page to tell you how to configure it.

The standards are well-documented in the Policy and Package Maintainer 
documents, so any lack of "understanding" is on the part of the reader... or 
non-reader as the case usually is.  Or a bug.  Either way, the only way to 
fix it is to contribute and send in patches and bug reports, just like code.  
Documentation needs love too.

Debconf is just a tool.  Many packages do not NEED such a tool.  Who cares 
which packages use it?  All packages have the ability to use a pre-install 
and post-install shell script to "do the right things" to the system to get 
installed and uninstalled, and if they don't, they should have bugs opened 
against them.  

Last time I checked, installation and upgrade bugs were tagged as at least 
"Important" in the bug tracking system.  

Any and all Debian-specific configuration items must be documented 
in /usr/share/doc/<packagename>/README.Debian, per package policy... if 
they're not, that's a bug that can cause a package to be removed from the 
package pool for not meeting the requirements for a new release of "stable". 

As far as the man page goes -- I'm with you on just that one... you should 
have opened bugs against packages where the man page told you to edit a 
particular file and it didn't exist on the system in that location.

> And then there's the issue of creating packages. Having written a few
> programs, I always thought I'd like to create DEBs of them. But in three
> years, I never learned how to create a Debian package. I just never had
> the energy to wade through 1000s of pages of mostly-obsolete
> documentation.

I never found the package documentation to be "mostly obsolete" in the Policy 
manual.  Wordy yes, but obsolete, no.  

However truly there's very little to learn about the insides of a Debian 
binary package file... a simple "ar -x <filename>.deb" on any one of the 
17,000 or so (for i386 arch) packages would render plenty of examples, to 
study.  And one could pick the complexity of the package one was attempting 
and look at a similar Debian package.

> Now contrast that with Arch, on the other hand: if the manual page for
> 'foo' says you configure the program by editing '/etc/foo.conf,' then by
> golly, that's exactly what you do. And if you want to create packages,
> (assuming you know generally how to compile software and know a bit of
> shell scripting) you can learn the basics in about 10 minutes. In fact,
> I installed Arch on my first box Saturday night, and created my first
> two Arch packages on Sunday night.

You can learn the basics of Debian packages in 10 minutes too, but don't take 
my word for it... here's Zonker's article... 

http://linuxdevices.com/articles/AT8047723203.html
(Reprinted with permission by LinuxDevices - originally published at IBM 
DeveloperWorks, according to the bottom of the page.)

> I didn't mean for this to turn into an anti-Debian rant. I don't hate
> Debian; it has served me well for 3 years. But, you know, I'm an
> experienced Linux user, and don't need much hand-holding. I want a
> simple system that *works the way I want it to.* That's why I started
> using Linux in the first place.

And I'm not meaning to turn this into a pro-Debian rant, I just honestly think 
you didn't dig hard enough -- or something else never "clicked" for you about 
Debian if you were having these problems.

I'm not sure which "hand-holding" was offensive to you in Debian, but it's 
assuredly child's play to download the debian source package for anything on 
the system and rebuild it with whatever switch options and customizations one 
wants. 

I just felt like people reading your rant might get the wrong idea about 
Debian, like there are some kind of limitations there that don't exist.  
Debian's packages are for the most part built from the same upstream source 
everyone else uses for the same packages.  They add on some meta-information 
about the dependencies of the package, and also enforce location rules for 
the filesystem.  

(Packages aren't "allowed" to install to /opt, or /usr/local for example, even 
if that's what the upstream source says... those areas are reserved for the 
local admin and never touched by the package tool, ever.  Packages MUST 
install configuration files to /etc, binaries to /usr/bin or /usr/sbin, etc.  
I feel that these common sense rules promote some sense of order.  I 
absolutely *know* that the documentation for the software is 
under /usr/share/doc/<packagename> even if the author put it in some 
completely insane place in his original code, like /home/<packagename>.  BUT 
if the sysadmin WANTS them there, one can download the source .deb and very 
very easily rebuild it with a different set of rules.)

All of the filesystem location rules are defined in the Policy and Packaging 
manuals.  

Basically a friend's rule of thumb applies... he says, "Linux is Linux.  You 
have the source, do what you want with it!"

I mean, seriously -- if all you wanted was "total control" of your packages, 
install a Debian base system, and then build everything else from upstream 
source and put it all in /usr/local - it's really really easy if that's the 
type of control you want to have... nothing stops anyone from having total 
control of their software on Linux, that's the great part about it.

I agree with you 100% that distro-wars are stupid, I just felt a need to point 
out some alternatives to various assumptions in the original post.  You 
obviously understand the power having the source code gives anyone wishing to 
do exactly what they want with their software and OS.  I truly wish more 
people could "get it" like that.  

Overall, distros exist for the convenience of the people too lazy, busy, 
tired, bored or distracted to learn to build their own software from source.  
There's always http://www.linuxfromscratch.org and embedded Linux'es where 
the user has zero access or control, and everything inbetween.  

--
Nate Duehr, nate at natetech.com