So is arch basically gentoo without the long compile times?

sarah31 · 2005-07-26 02:07:35

Gentoo was not very stable when I used it. I felt more geeky using Debian since your average gentoo user cannot install it or anything that does not have a set of documents that holds your hand.

Like I say the only way to know if they are "equal" is try arch out. Each person has a different tale to tell.

ozar · 2005-07-26 02:35:56

It takes hardly any time to install Arch, so it would be very easy for someone to spend more time just thinking and worrying over it than to buckle down, install it, and then see for him or herself.

archdaemon · 2005-07-26 03:28:52

paranoos wrote:

if you don't mind simplifying things this way, it helps decide if a distro is better than the one you are/were using. i switched over to arch from debian, so to me:
arch = debian + bleeding edge + i686 + much simpler init
in fact, arch has a much simpler init than most distros. i think slack uses it too?

Slack and Arch both use what are called 'BSD-style inits' which means, basically, a simple handful of scripts rather than a squillion symlinks and an indefinite number of indecipherable scripts. Arch has a cutesier style in the actual scripting rather than Slackware's straight-ahead no-crap style. But both are fast and clean and simple and sensible, unlike the SysV mess.

In case it's not obvious, I come from Slack (and I'm still there in that I'm a switch hitter - Arch on one box and Slack on another) and, to me, Arch has some of the virtues of Slack - keeps things simple, expects the user to halfway know what he's doing, let's him screw up if he wants, which means it also lets him do whatever he wants. Arch has the simplest and least intrusive package manager you can have if you have one at all. In all honesty, I get a more secure and stable feeling from Slack. Patrick makes mistakes but I basically trust that he knows what he's doing. With Arch, there are more cooks in the kitchen and some packages can be non-optimal. Slackware's been in the game a *long* time and the experience shows through.

So (sort of) Arch = Slackware + pacman - Patrick.

As far as Gentoo goes, it's about my third favorite distro, but I hate every other Linux distro I've tried (except LFS, which is in a different category) so that isn't as big an endorsement as it sounds like. Still, Gentoo might be Arch + more packages + more flakiness + more complexity + (a tendency towards) more compiling. And I just really didn't care for Gentoo's portage at all. Great when it worked but a far bigger pain than it needed to be in general. But, again, I generally hate package management. Arch is by far the best 'managed' distro around.

TheDoctor · 2005-07-26 13:47:09

archdaemon wrote:

... In all honesty, I get a more secure and stable feeling from Slack. Patrick makes mistakes but I basically trust that he knows what he's doing. With Arch, there are more cooks in the kitchen and some packages can be non-optimal. Slackware's been in the game a *long* time and the experience shows through.

There is also a pitfall to having too few cooks in the kitchen. Slack doesn't support PAM, and that doesn't look like it is going to change any time soon. That's the main reason that I switched. Slack is great for stand alone servers, but NIS is not a secure or flexible enough authentication scheme for a network environment.

As linux approaches the corporate desktop, there appears to be two main authentication schemes. LDAP, and LDAP-Kerberos. Novell, who is the definitive leader in user management, has gone this route with their NDS for Linux, Redhat is travelling this road with its own LDAP based on Netscape DS, and Slackware is going to be left out in the cold. Sure you can use straight ldap authentication on a slackware box, but you don't get the full experience, and to Pamify slack is not a small chore. On this box here, to pamify slack, I had to download and install packages from dropline, recompile the entire KDE package with PAM support, and OpenSSH, telnet, login, replace crypt, and bugfix everything. The first time I decided to do it, I buggered SSH and it logged on as root without a password. Not very nice. And if I wanted to roll out my own distro based on slack with PAM, I'd be spending even more time going over my systems, configuring, installing, and doing systems design, rather than computer and user administration.

Arch may not be perfect, but in the few weeks that I've been playing with it, it has given me the tools that I need to do what I need. I can have centralized login servers, centralized update servers, centralized logging servers, single sign on, and most importantly, spare time.

deft · 2005-07-31 05:35:36

reub2000 wrote:

I've been recently trying different distros, and was considering trying arch linux. I've always liked gentoo because of it's thorough package database that always up-to-date, and it let's you install and update packages with one command. But I've always hated it's long compile times. And it's not like I really need super fast programs when I have an Athlon 64 3000. So is arch linux kept up-to-date, and can you install every single package known to man using pacman?

Gentoo and Arch have some similarities and many differences - it's likely that a majority of desktop Linux users don't have a compelling need to utilise use flags and compile every last piece of software from source - that said, if you have those requirements and want to use Gentoo for that, then feel free - there's plenty of choice in the desktop LInux world

jerem · 2005-07-31 10:13:05

Well with Debian you don't need documentation but you read the information on the screen :-)

And I never thought having a documentation was a drawback...

Perhaps will your opinion change with the new Gentoo installer.

I also feel and continue to feel that Gentoo is more stable than Arch, because system-critical packages are tested and ~x86 marked for days before they are released in the normal branch.

What I also lack with Arch is selective branch mixing. I can't choose to upgrade ONLY that particular testing package and not ther others...

Pacman can only have either the testing repo enabled, or not.

This is far from arch/~arch package testing system.

iphitus · 2005-07-31 11:13:34

jerem wrote:

Well with Debian you don't need documentation but you read the information on the screen :-)
And I never thought having a documentation was a drawback...
Perhaps will your opinion change with the new Gentoo installer.
I also feel and continue to feel that Gentoo is more stable than Arch, because system-critical packages are tested and ~x86 marked for days before they are released in the normal branch.

Do what I do, syu once a week, and leave system packages if there are known issues.

To be fair, most packages are fixed within days, and we have only had a handfull recently, before udev and the procps packages, we really didnt have too many issues at all.

Arch tends to be aimed at being more cutting edge anyway, we tend to have packages for many things before many major distros, at the lack of testing. We get away with it most of the time

For example, inkscape 0.42 came out the other day, it was in the repos in less than 12 hours. Back in the days when I used mandrake, it definitely didnt have a response speed like that.

What I also lack with Arch is selective branch mixing. I can't choose to upgrade ONLY that particular testing package and not ther others...
Pacman can only have either the testing repo enabled, or not.
This is far from arch/~arch package testing system.

Ah.... oh but there is!

pacman -S testing/mp3splt

will install mp3splt from testing instead of from extra.

that really ought to be documented somewhere.

[root@asandrial archie]# pacman -S qt

Targets: qt-3.3.4-8

Total Package Size:   8.6 MB

Proceed with upgrade? [Y/n] n
[root@asandrial archie]# pacman -S testing/qt

Targets: qt-3.3.4-12

Total Package Size:   9.9 MB

Proceed with upgrade? [Y/n] n

jerem · 2005-07-31 12:02:45

Yes, but to do a pacman -S testing/package ,

you need to enable the testing repo in pacman.conf, don't you ?

And then, when you do pacman -Syu, it installs all the testing packages, for example GCC 4 and a plenty o others...

iphitus · 2005-07-31 12:09:35

jerem: no, my testing repo is in my pacman.conf, uncommented, but it's listed after my extra/current repos.

That means extra and current get priority, so no, testing GCC won't overwrite my current gcc. But i can also pacman -S testing/gcc if i wanted to force it to install that from testing.

iphitus

Convergence · 2005-07-31 20:14:07

jerem wrote:

- Arch's speed in general is amazing, especially pacman, since it is written in C and not in Python. Searches with pacman are completed in less than a second. Portage will take...er.....longer...

Python is NOT the reason that portage is slower.

butters · 2005-08-31 07:23:53

I'm a die-hard longtime Gentoo user (forget udev, the first beta release of Gentoo I used didn't have devfs support) considering Arch for turning a craptastic HP 433MHz Celeron with 64MB RAM into a samba file server with a very light desktop. I've previously installed Gentoo on a 100MHz i586 with 64MB RAM (from stage1 no less), but the gray in my beard is starting to come in at the age of 23, so I figure I would try something different this time.

I've been following Arch from a distance for a year or two now, and it does, on the first through third -most superficial levels, closely resemble Gentoo. I read through all the basic documentation, and the differences seem to be:

* Strong package system from the start, with a source-based system well bolted on. Whereas Gentoo is the other way around with a less-well-bolted binary package system.

* Shell scripts for package config files rather than python for ebuilds (draw you own conclusion)

* Somewhat intolerant (confusable) ncurses installer versus nothing quite yet

* Prebuilt kernels (I think Gentoo should have had this *option* long ago)

* Both have stripped-down BSD init systems, Arch's is a little more stripped down (no rc-update or /etc/runlevels)

* Documentation can use some work (not bad though), versus documentation is the envy of all others.

* phpBB forum has almost 97K threads and 11 users online right now, phpBB forum has over 2.6M threads and 222 users online right now.

It seems like the process of taking the source tree from joe-opensource-project (to coin a phrase) and turning it into something that any user can install using the package manager is less labor-and-resource-intensive with Arch than with Gentoo. You pretty much need a working knowledge of python and a 3-hour training seminar to write an ebuild that is worth submitting for inclusion in the portage tree.

There are a lot of nonissues that are issues on Gentoo. For example, in Gentoo when an updated package comes with new config file that is nontrivially different from the existing config file, you must either use etc-update or the easier-to-use dispatch-conf utility to manage the config file updates. How does Arch get around this issue? Does a new version either clobber your config files or never update them?

Also in Gentoo there are "blockers," which are already-installed packages that are blocking the install of a new package or package version because it is deprecated by the new package, or because they are otherwise incompatible. Usually you are wanting to install this new package because it is a dependency of another package you are updating. How does Arch get around this issue? Is there a concept similar to "slots" in Gentoo?

Last (real) group of question: can I install Arch at the command line similar to how I install gentoo, minus the runlevel configuration, kernel compilation, etc. and replacing 'emerge system' with 'pacman -Sy base' or something like that? Come to think of it, can you even use pacman in the scope of package groups, rather than on all installed packages or individual packages? Will I have to, for example, create my own /etc/fstab if I do things this way? Is there a better solution to my madness? I just don't like installers that seem to be nothing more than ncurses-driven batch scripts with inevitable bugs.

Being that this thread started with flamebait, I figure I'll end with flamebait: how does the performance of Arch compare to Gentoo? What about Vector?

Now I start back at zero posts on yet another Linux forums. I better start building a bad reputation fast...

butters · 2005-08-31 07:32:43

Convergence wrote:

jerem wrote:
- Arch's speed in general is amazing, especially pacman, since it is written in C and not in Python. Searches with pacman are completed in less than a second. Portage will take...er.....longer...
Python is NOT the reason that portage is slower.

The only advantage to coding a package manager in C is that it's more difficult to develop and maintain... *pause; activate sarcasm filter*

Python is still the best choice in my educated opinion, although Ruby is a close second and I haven't played around with Perl6 yet (Perl5 would be easier to develop but possibly harder to maintain, because Perl readability is strongly correlated to the mood of the developer at the time). Portage searches are slow for the same reason this forum post isn't stored in a flat-file database. My guess is that pacman repositories are some sort of relational database. Someone here can confirm this hypothesis.

elasticdog · 2005-08-31 09:27:41

Ahoy butters! Thanks for the thoughtful post...I'm a relative Arch newbie (been using it for a couple of months), but I'll try to answer some of yer questions...

I do agree that Arch's packaging system is extremely well thought out...while at the same time it's still easy to use it and contribute to the community without a ton of extra knowledge. Basically if you can install software from source by hand, you can pretty easily make a PKGBUILD for it and manage the installation using pacman/ABS.

As far as pacman updating config files, there are a few ways to make sure it does what you want. Using the NoUpgrade and HoldPkg options in the pacman.conf file, users are able to control how special-case files are treated when updating. Most of the usual suspects are already there by default (etc/passwd, etc/fstab, boot/grub/menu.lst, etc.)

I'm not familiar with Gentoo "slots", and the "blockers" issue is one I haven't run across since using Arch. Someone who knows more and has been around longer can probably jump in here, but I would think those conflicts would mostly be corner cases...

As far as a command line installation, using the CD will basically give you what you are looking for. Part of the Arch philosophy is KISS (Keep It Simple...), and the installation CD doesn't do very much beyond helping you to setup the basics of the basics before throwing you into a command line with the tools you need.

The CD will help you configure your network if you are interested in doing an FTP install rather than pulling older versions off of the disc. You'll be able to use cfdisk to partition your drive accordingly and there's a simple interface to mount your newly created partitions. After that, you have the option to select what packages you want...although it's recommended to only install the base group (which is the only thing selected by default). You won't have to worry about runlevel configuration, or kernel compilation (unless you want to). Most of the basic config files are created automatically for you (fstab, etc.) and there is a menu with a short list of files for you to look at and change if you want using vi or nano. Really only a few lines need to be customized, such as the machine name, localization for time, etc.. Then you're given the option to install a boot loader, and that's the entire CD in a nutshell.

Once you reboot, hopefully you'll be taken to a login screen where you can set the root password, create your first user, and start to do/download whatever else you want.

Speed wise, I think Arch is very fast...search the forums for more anecdotes/flame wars on this subject, but I don't think you'll be disappointed. Not only is the speed good, but the time saved from not having to compile everything can be a life saver.

Anyway, hopefully that helps a bit...I'm sure someone else will chime in with more info. By all means, feel free to ask any other questions that may be on your mind...the Arch community is amazingly helpful!

dtw · 2005-08-31 11:54:37

butters wrote:

* Documentation can use some work (not bad though), versus documentation is the envy of all others.

Alas we still have a majority of "Could someone...." rather than "I just..." users. Our core of really competant users is growing pretty fast now - this is muddied by an influx of almost total newbies, not put off by the warnings I guess, but we are getting there. We have the new improved wiki etc.

butters wrote:

Also in Gentoo there are "blockers," which are already-installed packages that are blocking the install of a new package or package version because it is deprecated by the new package, or because they are otherwise incompatible. Usually you are wanting to install this new package because it is a dependency of another package you are updating. How does Arch get around this issue? Is there a concept similar to "slots" in Gentoo?

I don't fully get this either but I'll have a crack. I maintain a pkg that depends on php4 and the pkg knows it depends on php4. If you try to upgrade to a newer version it will refuse (but you can force it) - would that be a blocker?

Last (real) group of question: can I install Arch at the command line similar to how I install gentoo?

I have never installed gentoo but I read a lot about it then chose Arch. As far as I can tell the installation on the base cd will leave you with a system comparable to a stage1 install or what you have after you finish the first bit of LFS, without the compiling of course. You can compile your own kernel during install. Then, as edog said, you boot and are dropped in at a command line.

Come to think of it, can you even use pacman in the scope of package groups, rather than on all installed packages or individual packages?

Some pkg groups exist but mainly for DE like kde and xfce.

Will I have to, for example, create my own /etc/fstab if I do things this way?

The installer will put stock configs on your system and tell you to edit them before you reboot

Being that this thread started with flamebait, I figure I'll end with flamebait: how does the performance of Arch compare to Gentoo? What about Vector?

I am came here via Vector. I have only ever used Vector and Arch so I have never used a slow distro apparently. You might find Vector a bit "boring" for your liking. The development process is pretty slow and quite frustrating to observe and if you want to get more involved it will be at their pace. Here, as with gentoo I guess, you can get involved over night. Also, if you want to keep your server software up to date at your convinence then use Arch.

sepht · 2005-09-01 01:07:37

Arch and Gentoo performace? I did a stage1 gentoo install on the same box as my arch install, march=pentium4 -O2, pipe, formit frame, etc. and the results weren't shocking:
Bootcharts:
www.geocities.com/sephiroth230/

System performance,
160 FPS glxgears in Gentoo, wm:failsafe from kdm(nvidia drivers, from nvidia site)
162-165 FPS glxgears in Arch, wm:failsafe from kdm(same drivers, directly from nvidia)(stock arch kernel btw)
I didn't feel the need to pursue further, compiling the system(x11, gcc, etc) from scratch doesn't seem to make much of a difference. (or at least between i686 and pentium4 optimizations)

disk performance, cpu peformance, well, thats the kernel anyways, so it would be pointless to test. Gentoo's kernel patchs are downloadable if you like them oh-so-very much.

(Although I tried to be as fair and balanced as possible, none of these benchmarks have been approved or certified by either Arch Linux or other sources. lol)

butters · 2005-09-01 02:11:01

dibblethewrecker wrote:

Alas we still have a majority of "Could someone...." rather than "I just..." users. Our core of really competant users is growing pretty fast now - this is muddied by an influx of almost total newbies, not put off by the warnings I guess, but we are getting there. We have the new improved wiki etc.

Well, I'm fairly competent, and when I get done installing Arch from a generic LiveCD (i.e. Knoppix) using the Gentoo style (CLI only, mount, chroot, install base, compile kernel, edit config files, reboot), I'll write a Gentoo users's guide to Arch as well as the seemingly missing quickinst documentation. I think that a base tarball (gentoo style) would be a good thing for Arch to offer. Perhaps I'll enhance the quickinst script with an option to do a "fake install" to a tarball for extraction elsewhere, and then maybe the Arch people can push a weekly base tarball out to the mirrors.

I don't fully get this either but I'll have a crack. I maintain a pkg that depends on php4 and the pkg knows it depends on php4. If you try to upgrade to a newer version it will refuse (but you can force it) - would that be a blocker?

You're getting there. So lets say I maintain a pkg that depends on php5 and a mutual friend of our's wants to install both pkgs. How does pacman deal with that?

I have never installed gentoo but I read a lot about it then chose Arch. As far as I can tell the installation on the base cd will leave you with a system comparable to a stage1 install or what you have after you finish the first bit of LFS, without the compiling of course. You can compile your own kernel during install. Then, as edog said, you boot and are dropped in at a command line.

Gentoo's stage1 tarball is just the GCC toolchain, its dependencies, and the portage package manager. Arch's base install is actually comparable to stage3 in Gentoo. The latest Gentoo handbook doesn't even mention the possibility of installing from stage1 or stage2 anymore, and I say good riddance (unless your machine has really exotic architecture).

The installer will put stock configs on your system and tell you to edit them before you reboot

Will quickinst create stock config templates also?

I am came here via Vector. I have only ever used Vector and Arch so I have never used a slow distro apparently. You might find Vector a bit "boring" for your liking. The development process is pretty slow and quite frustrating to observe and if you want to get more involved it will be at their pace. Here, as with gentoo I guess, you can get involved over night. Also, if you want to keep your server software up to date at your convinence then use Arch.

I think I'll be happy here. The philosophy and infrastructure (pacman, ABS, pkgbuild, BSD-style init) keep the barriers to entry very low for aspiring contributors, and the community reminds me of Gentoo cerca 2002-2003. Newbies kind of suck the wind out of independent community projects like this, which is very unfortunate for noobs and gurus alike. If you've never written a shell script in your life, you should be using a distro that is somehow tied to a commercial entity. Leave Gentoo, Arch, Slackware, and Debian to those in the community who have something to contribute, whether it be experience, skills, time, insight, or the desire to learn what it takes to contribute. These are not distributions meant for public consumption, they are meant to drive innovation and cultivate talent within the community.

There are literally 40 billion Debian-based, easy-to-use, general-purpose distributions (both free and commercial) out there, and this clearly has nothing to do with the project's long-standing focus on catering to the novice.

butters · 2005-09-01 02:38:37

sepht wrote:

disk performance, cpu peformance, well, thats the kernel anyways, so it would be pointless to test. Gentoo's kernel patchs are downloadable if you like them oh-so-very much.

Speaking of kernels, what is the Arch stock kernel like? Is it more-or-less vanilla 2.6.x, more like gentoo-sources, or more like ck/mm/love/nitro/etc?

Back when I was a college student skipping class and wasting time, I used to try out all the kernel patchsets and feel their... texture in desktop usage. My favorite used to be nitro, which seemed snappier than love and both were far more consistent that mm, which was very much in flux at the time.

Then I got sidetracked by an infatuation with Reiser4, which I grew to regret after I stopped drinking the Kool-Aid and realized that it has major regressions and bugs along with its few benchmarks of glory (some of which were apparently faked by Namesys... whoops). And Hans Reiser is a fascist who either ignores or fails to comprehend why the Linux kernel devs don't want to shove a round peg into a square whole and then dump epoxy resin in the resulting gaps. But I'll stop there and allow you to reach your own conclusion (seems to only exist in the google cache now):

http://72.14.207.104/search?q=cache:zj8 … 278/thread

Since then I've been using the ck patchset and ext3 with dir_index enabled:

# mke2fs -j /dev/hdxy
# tune2fs -O dir_index /dev/hdxy
# e2fsck -D /dev/hdxy

Try it, and you'll reconsider the myth that ext3 is slow.

Snowman · 2005-09-01 03:53:16

butters wrote:

You're getting there. So lets say I maintain a pkg that depends on php5 and a mutual friend of our's wants to install both pkgs. How does pacman deal with that?

If you want to install two versions of a pkg, you'll need to give them different names. If I use the php example, you can install php (version 5) from [current] repo and php4 from AUR http://aur.archlinux.org/packages.php?d … s=1&ID=658

butters wrote:

Speaking of kernels, what is the Arch stock kernel like? Is it more-or-less vanilla 2.6.x, more like gentoo-sources, or more like ck/mm/love/nitro/etc?

The stock kernel is vanilla with a couple of patches. There is also a mm kernel in [extra] repo, and a cko and archck in the [community] repo. The archck kernel was made by iphitus because cko is a dead project. It's pretty much the same patches that were in the cko.

Euphoric Nightmare · 2005-09-01 03:56:09

What is the point of doing a 'gentoo-style' arch installation if it will get you the same place as installing from installation thingy?

butters · 2005-09-01 04:54:36

Euphoric Nightmare wrote:

What is the point of doing a 'gentoo-style' arch installation if it will get you the same place as installing from installation thingy?

I can think of a few reasons:

1) You don't need to burn the iso
2) You don't need to worry about arch's install CD having support for your network card (will it be able to do an FTP install if my only network interface is ipw2100?)
3) The provided installer isn't very flexible, and the stuff it does is really, really basic
4) The provided installer is more likely to screw up your installation (something about making sure to hit "done" everytime...) than to make your life easier.
5) You don't really want to use the package selector anyway if you know what you're doing (I've read this a lot on various Arch webpages).
6) When you see how easy it is to do what I'm talking about, you'll want to install this way also.

So far it's 11 commands from fdisk to quickinst, and that should bring you to at least the "configure system" part of the normal install. The rest is subject to what quickinst actually does, which I don't exactly know because there's no documentation it seems.

butters · 2005-09-01 05:57:37

Snowman wrote:

If you want to install two versions of a pkg, you'll need to give them different names. If I use the php example, you can install php (version 5) from [current] repo and php4 from AUR http://aur.archlinux.org/packages.php?d … s=1&ID=658

OK, so when php6 comes out, and that goes into current as 'php,' then any packages that can't use the new version will need their dependency changed from 'php' to 'php5'... not too bad. Simple is good in this case.

What about if those crazy lunatics from the GNOME project decide one day that from now on, the libgnome-thingy package will be called gnome-thingy-backend and that the next version of gnome-desktop will depend on it. When I pacman -Syu after the new GNOME is in current, will I now have two packages installed, one which nothing depends on anymore? Speaking of which, what if multiple packages (with different names) own the same file (/usr/lib/libgnomethingy-2.so) and I install both of them? Does one package clobber the other? If I remove libgnome-thingy using pacman, will gnome-thingy-backend stop working because libgnomethingy-2.so was removed?

I'm not trying to bash pacman or anything, I'm just saying that these are the types of issues you can run into with package management, and pacman seems so overwhelmingly simple that I don't understand how these complex issues are being avoided.

The stock kernel is vanilla with a couple of patches. There is also a mm kernel in [extra] repo, and a cko and archck in the [community] repo. The archck kernel was made by iphitus because cko is a dead project. It's pretty much the same patches that were in the cko.

Yeah, cko just disappeared off the face of the earth one day. The freshmeat project is gone, but Piotr's website now serving the patch again:

http://kem.p.lodz.pl/~peter/cko/rel/pat … 2-cko3.bz2

I might try this patch instead:

http://kernel.damouse.co.uk/ck/ckx/2.6. … 3-ckx1.bz2

There seems to be a temporary slowdown in patchset land. I think it's a back-to-school-related slowdown compounded by the availability of free beer during rush.

Snowman · 2005-09-01 07:36:32

butters wrote:

OK, so when php6 comes out, and that goes into current as 'php,' then any packages that can't use the new version will need their dependency changed from 'php' to 'php5'... not too bad. Simple is good in this case.

Yes, that's correct.

butters wrote:

What about if those crazy lunatics from the GNOME project decide one day that from now on, the libgnome-thingy package will be called gnome-thingy-backend and that the next version of gnome-desktop will depend on it. When I pacman -Syu after the new GNOME is in current, will I now have two packages installed, one which nothing depends on anymore?

In the PKGBUILD, there is a replaces field for this scenario. So when you'll update, pacman will tell you "gnome-thingy-backend replaces libgnome-thingy, do you want to remove libgnome-thingy".

butters wrote:

Speaking of which, what if multiple packages (with different names) own the same file (/usr/lib/libgnomethingy-2.so) and I install both of them? Does one package clobber the other? If I remove libgnome-thingy using pacman, will gnome-thingy-backend stop working because libgnomethingy-2.so was removed?

You cannot install them. pacman will tell you that pkg A conflicts with pkg B. You could always force the install but it won't be wise to do so.

If you want to have multiple versions of an app and both binaries have the same name, you'll need to rename the binaries (like the php4 PKGBUILD does) or install it in another directory (like /opt/php4 for example)

dtw · 2005-09-01 08:48:17

butters wrote:

Well, I'm fairly competent, and when I get done installing Arch from a generic LiveCD (i.e. Knoppix) using the Gentoo style (CLI only, mount, chroot, install base, compile kernel, edit config files, reboot), I'll write a Gentoo users's guide to Arch as well as the seemingly missing quickinst documentation. I think that a base tarball (gentoo style) would be a good thing for Arch to offer. Perhaps I'll enhance the quickinst script with an option to do a "fake install" to a tarball for extraction elsewhere, and then maybe the Arch people can push a weekly base tarball out to the mirrors.

Ah, butters, you have made my day. You wouldn't believe the number of pacman GUIs that have appeared in the last two months and I have staved off my scorching criticism regarding replication of effort and "Do we really even need one???". But it seems to be keeping people happy, and there are some very good ones i.e. jacman. But finally someone comes up with something that would actually fill a real hole, something that actually enhances Arch rather than just adds to it.

We were recently discussing the slow release cycle of Arch ISO, which in itself is not a bad thing due to the way the Arch rolling releases system works but your suggestion of circumventing the whole ISO issue full stop is just what we need.

However, arguably, if you don't have a live-cd laying around and need to dl an ISO it's just as easy to dl the base ISO but who doesn't have an livecd laying around? I have 4 I think...

The Archie live-cd project has endevoured to make installation easier in a GUI way and it is great to have a well documented and accesible counter balance on the CL, ESPECIALLY given the type of users it will attract.

Snowman wrote:

If you want to have multiple versions of an app and both binaries have the same name, you'll need to rename the binaries (like the php4 PKGBUILD does) or install it in another directory (like /opt/php4 for example)

Building on this I'll clarify that this is exactly what abs can help you do. You can either use pacman as a no brainer way to get apps or you can exploit it to manage a virtually custom system using ABS and anything in between. Arch may not cater directly to installing 3 versions of php (and why should it?) but with abs you can do pretty much anything you like and have pacman manage it. As long as you know what you are doing with linux...well, it's just great

butters · 2005-09-01 08:48:49

Alright, so I get the sense that pacman can handle anything that portage can, except that (because pacman is a binary system) a lot of what portage does is much more simply implemented in pacman. There is an explicit conception of what files belong to which package(s) in pacman whereas that's fundamentally impossible in portage.

I'm sold, thanks for answering my questions, guys.

The only cloudiness I still have is related to the internal package representation used by pacman. There's a way leverage a pkgbuild (which is analogous to an ebuild) so that it becomes a "pacman package". This is conceptually a tarball of the built package along with the pkgbuild file and some sort of a metadata file that makepkg generates. I'll have to poke around in one of these tarballs to get a sense for what's going on. These tarballs are stored on repositories, and pacman syncs to these repositories to create some sort of a local database that might just be a collection of these metadata files. But in any case the data structure is proportedly more efficient to search than the portage tree.

agilyben · 2005-09-01 12:10:07

I have to agree: butters' idea of a base tarball release is a really good idea. I also tend to prefer a CLI based installation!

Arch Linux

#26 2005-07-26 02:07:35

Re: So is arch basically gentoo without the long compile times?

#27 2005-07-26 02:35:56

Re: So is arch basically gentoo without the long compile times?

#28 2005-07-26 03:28:52

Re: So is arch basically gentoo without the long compile times?

#29 2005-07-26 13:47:09

Re: So is arch basically gentoo without the long compile times?

#30 2005-07-31 05:35:36

Re: So is arch basically gentoo without the long compile times?

#31 2005-07-31 10:13:05

Re: So is arch basically gentoo without the long compile times?

#32 2005-07-31 11:13:34

Re: So is arch basically gentoo without the long compile times?

#33 2005-07-31 12:02:45

Re: So is arch basically gentoo without the long compile times?

#34 2005-07-31 12:09:35

Re: So is arch basically gentoo without the long compile times?

#35 2005-07-31 20:14:07

Re: So is arch basically gentoo without the long compile times?

#36 2005-08-31 07:23:53

Re: So is arch basically gentoo without the long compile times?

#37 2005-08-31 07:32:43

Re: So is arch basically gentoo without the long compile times?

#38 2005-08-31 09:27:41

Re: So is arch basically gentoo without the long compile times?

#39 2005-08-31 11:54:37

Re: So is arch basically gentoo without the long compile times?

#40 2005-09-01 01:07:37

Re: So is arch basically gentoo without the long compile times?

#41 2005-09-01 02:11:01

Re: So is arch basically gentoo without the long compile times?

#42 2005-09-01 02:38:37

Re: So is arch basically gentoo without the long compile times?

#43 2005-09-01 03:53:16

Re: So is arch basically gentoo without the long compile times?

#44 2005-09-01 03:56:09

Re: So is arch basically gentoo without the long compile times?

#45 2005-09-01 04:54:36

Re: So is arch basically gentoo without the long compile times?

#46 2005-09-01 05:57:37

Re: So is arch basically gentoo without the long compile times?

#47 2005-09-01 07:36:32

Re: So is arch basically gentoo without the long compile times?

#48 2005-09-01 08:48:17

Re: So is arch basically gentoo without the long compile times?

#49 2005-09-01 08:48:49

Re: So is arch basically gentoo without the long compile times?

#50 2005-09-01 12:10:07

Re: So is arch basically gentoo without the long compile times?

Board footer