Thoughts/ Maintaining an ArchLinux System.

csgeek · 2010-09-28 16:42:17

So.. I'm a gentoo reform. I was on gentoo for 5+ years and mainly loved the customization of gentoo. I like that I know what's going on in my OS.

Arch has a similar approach in that regard. As in, I modify /etc/rc.conf or *insert config name* restart a service and I can see the effects.

I've been on arch on and off for over a year now, and it find that the more I use it.. the more I tend to lean towards abs.

I'd installed packages using pacman initially. After a while, I find that I need something or other from aur. I start using aur, and at some point or another, I upgrade/ replace
some library that forces me to pull a few packages from abs and rebuild them.

I ran across http://aur.archlinux.org/packages.php?ID=15982 which does make things a lot easier, but it seems like it would be beneficial to be able to have something like the freebsd ports or portage behavior.

It seems like abs has no manager, or I overlooked it.

I'd love to be able to cd /var/abs; and do a make world ;

rebuild all the packages and at the very least have some sense of dependency.

findpackages will give me a list of broken packages that I need to re-compile. The list can grow fairly large at times and it would be nice
if there was a tool that's more aware of the arch environment, what packages are dependent on what.. and compliment the findbrokenpkgs
script as well as allows the user to update against abs easily.

Now, it might just me being jaded by my gentoo experience.. but.

1. I'd like findbrokenpkgs or some similar tool to resolve the order of packages that they need to be installed in. x depends on y, and x and y are broken, so lets build y first.
even if the packages aren't installed automatically.. at least allow someway to auto build everything....

2. I'd like a way to auto sync and build and compile from world.

3. It would be nice if there was a way to notify pacman.... say.. user X has installed mplayer from abs. A new update for mplayer is available. Would you like to install mplayer from pacman anyways? Or update the makepkg. (Figure some sensible defaults, config file you can set... and maybe an -i for interactive mode that prompts you if you wish to have more options/fine grained control)

Am I the only wishing some of these things were feasible/doable? Would having some projects along these lines be welcome by the community.... or is it introducing more automatic behavior then is desired....and steering away from what arch stands for?

--
csgeek

Last edited by csgeek (2010-09-28 21:34:08)

karol · 2010-09-28 16:57:46

bauerbill?

jasonwryan · 2010-09-28 21:17:09

Please rename your thread to something that is specific and descriptive; imgagine trying to find this in 12 months time using the bbs search or google...

http://wiki.archlinux.org/index.php/For … ow_to_Post

And if bauerbill doesn't do what you are looking for, you could always develop something yourself: one of the basic philosophies around her can be summarized as "patches always welcome."

ngoonee · 2010-09-28 23:03:49

csgeek wrote:

1. I'd like findbrokenpkgs or some similar tool to resolve the order of packages that they need to be installed in. x depends on y, and x and y are broken, so lets build y first.
even if the packages aren't installed automatically.. at least allow someway to auto build everything....
2. I'd like a way to auto sync and build and compile from world.

Autobuilding bauerbill can do. Automatic order resolution I don't think it can, its not a trivial problem. Sometimes you'd have to manually intervene. Go ask Xyne more about it.

csgeek wrote:

3. It would be nice if there was a way to notify pacman.... say.. user X has installed mplayer from abs. A new update for mplayer is available. Would you like to install mplayer from pacman anyways? Or update the makepkg. (Figure some sensible defaults, config file you can set... and maybe an -i for interactive mode that prompts you if you wish to have more options/fine grained control)
Am I the only wishing some of these things were feasible/doable? Would having some projects along these lines be welcome by the community.... or is it introducing more automatic behavior then is desired....and steering away from what arch stands for?

As previously said - patches welcome. Point 3 is already done, even without any helper. If i have mplayer 32025-1 compiled from abs and the version in [extra] is updated to 32026-1, it will automatically be updated (without notifying me explicitly). Bauerbill can automatically rebuild it from abs with patches you specify, when its updated).

sitquietly · 2010-09-30 06:54:59

I loved Gentoo some years ago (before my trip to netbsd and pkgsrc) :-D

ArchLinux may have the best of all worlds. I'll describe the work flow I'm using that I think accomplishes at least a couple of your goals.

Do an initial install of Arch from the binary repositories, e.g. the netinstall CD. Then create a directory for maintaining all future additions and upgrades, all to be build from source (I use /var/pkgsrc). Create a directory for catching PKGBUILDs of packages that need to be updated (I use /var/pkgsrc/UPDATES).

The common Arch tools are all that I seem to need: clyde, pactree (from pacman-contrib), pbget, and makepkg (from pacman). For example, to do an update from source:

* open three terminal windows (works especially well with a tiling window manager -- XMonad rules)

* in one window check to see what updates are available from the repos you have enabled (BTW I've had no trouble with "testing").

- clyde -Syu # do not actually do the updates, say "no -- I'll update from source code thank you"
- just keep this window open for reference to the list of pending updates and their version numbers

* in the second window I do the updates from source:
- cd /var/pkgsrc/UPDATES
- optional: grab some or all of the needed PKGBUILDs by "pbget --abs --aur --upgradable"

* in the third window use pactree to see the order in which you should do the updates; this process is not automated but I think that working with simple tools and using a human brain makes for a smooth process, I even seem to do a little learning each time.

* having selected the package lowest in the dependency tree, or several trees, that you can see in the second terminal, make sure that you have the PKGBUILD directory for that package in your UPDATES folder, doing "pbget --abs <package>", or "pbget --aur <package>" (these will probably already be present because of the previous "pbget --abs --aur --upgradable", unless there are new dependencies needed by some package (which will be shown in the first window, in clyde's list :-)

* build and install the selected package

- cd <package>

- important! read the PKGBUILD to make sure that the package version it is building is the same as shown in clyde's list.
If it is not you have two options: wait until the "abs" is updated (after midnight) and the new PKGBUILD becomes available,
or grab the latest PKGBUILD from the trunk by "pbget <package>" -- this will probably be the PKGBUILD corresponding to
the binary package in the repositories but if the developer is working fast and hot she may have a yet newer PKGBUILD in
the subversion trunk and YOU COULD HURT YOUR SYSTEM AND FIND THE PROBLEM ONLY MUCH LATER. You _should_ be
OK if the package version and revision level given in the retrieved PKGBUILD are the same as you see in clyde's list. Yeah.

- makepkg --install --log --noconfirm # for a simple package

- makepkg --install --log --noconfirm --pkg <package> # for a split package

- MAKEFLAGS="-j1" makepkg --install --log --noconfirm # for a package that just won't build with your "-j5" flag from makepkg.conf

- move the package's folder into /var/pkgsrc (for me it's just "mv <package> ..")

So the workflow is really just "pbget --abs --aur --upgradable" and "makepkg --install" in each of those folders.

I find it easiest to always install a new abs package from the repositories and then to build it from source if desired --- I get to optimize for my system (CFLAGS="-march=atom -O2 -msse3 -mfpmath=sse -pipe", for my Zotac IONITX boards with Intel Atom 330 and the ION Nvidia gpu) and edit the PKGBUILD, or even the source code, to customize the configuration options.

This workflow allows new packages to be added _very_ quickly (pacman / clyde), optimized and customized later (pbget, edit, makepkg). It gets you very familiar with the dependencies of packages (pactree) :-| It leaves the source code and build logs in a single place for your later reading enjoyment.

Note: a thoughtless "pbget <package>" can draw down a world of hurt on you! Remember that pbget without "--abs" gets the latest PKGBUILD that may not have been released to the world yet, not as a binary package, not as a testing package, not in abs. For example, today you can't find gtk2-2.22.0 in the binary repositories or even find a log entry for it in the subversion repository. But if you do a "pbget gtk2" you will get a pkgbuild for it and probably run into trouble -- for example this gtk2-2.22.0 from head needs a new package, gdk-pixbuf2, which depends on an updated glib2-2.25.15.....

Don't hurt yourself but have a good time. Take time to sit quietly :-)

Arch Linux

#1 2010-09-28 16:42:17

Thoughts/ Maintaining an ArchLinux System.

#2 2010-09-28 16:57:46

Re: Thoughts/ Maintaining an ArchLinux System.

#3 2010-09-28 21:17:09

Re: Thoughts/ Maintaining an ArchLinux System.

#4 2010-09-28 23:03:49

Re: Thoughts/ Maintaining an ArchLinux System.

#5 2010-09-30 06:54:59

Re: Thoughts/ Maintaining an ArchLinux System.

Board footer