You are not logged in.
I want to write scripts that will take me through the post-install process, to go from a bare install to an Arch Linux system fully populated as per my needs, my knowledge, and my desires. But I do not want to reinvent the wheel. Many users, and more competent ones than me, must already have addressed this issue. I would like to hear them and learn from them.
You could say, "Why don't you populate your system just once, and then just do regular upgrades---and clone your populated system if you wish to run the same environment on different hosts?" Fact is, my preferred system make-up is a moving target, and is crafted interactively, with a lot of experimenting, false starts, dead ends, reading of documentation,
and even a bit of serendipity. I would like to maintain a script that codifies the RESULTS I came up with, not all the trials and errors.
Such a script, if well crafted and commented, would also constitute a live and up-to-date documentation of what it is that I actually want in my Arch Linux system.
This script would consist of a long list of pacman 'download and install' command, occasionally interspersed by package-specific
mini-scripts for configuring and customizing specific applications. My concern is how best to delegate to the script the interaction with
pacman. For most packages in the pacman/AUR repositories, the only interaction that is needed is answering YES or NO to a (Y/n) query,
and in this case one can use the --noconfirm option, thus implicitly accepting the choice suggested as default by the query.
But occasionally one has to give a numerical or other answers (which languages do you want your LibreOffice to handle? which parts of a multipiece suite do you need to install?), and in certain cases one would want to answer NO rather than YES. To handle the queries (for instance, using Expect or Expect-lite) in a robust fashion, it would be nice to know BEFOREHAND what kind of queries one is going to be confronted with.
In sum, I would like to populate my system in a Literate Programming fashion (cf. Donald Knuth), and have scripts that best capture
and document my (evolving) understanding and wishes as well as the required conversation with pacman..
Beside suggestions from pacman "power users', I would love to get ideas from the pacman development team. Couldn't every package
be accompanied by a description (in some standard, automatically processable format) of the interaction that is expected and of the
meaning of the choices, so that with the help of this documentation pacman users could write robust scripts by "blind reckoning',
without having first to carry out by hand the installation of each package and record what kind of dialog seems to accompany it?
Please let me know what you think of all this, who can help, and how I can help. Thanks.
Offline
It takes only 20 mins to do a fresh install with all the setup I need. But each one of the Arch Linux users will want a different setup. Using pacman with --noconfirm is not the best of the ideas while using Arch Linux.
Last edited by hadrons123 (2012-12-06 16:35:07)
LENOVO Y 580 IVYBRIDGE 660M NVIDIA
Unix is user-friendly. It just isn't promiscuous about which users it's friendly with. - Steven King
Offline
Maybe this useful for you:
https://wiki.archlinux.org/index.php/Pa … d_packages
Offline
I would love to get ideas from the pacman development team. Couldn't every package
be accompanied by a description (in some standard, automatically processable format) of the interaction that is expected and of the
meaning of the choices, so that with the help of this documentation pacman users could write robust scripts by "blind reckoning',
without having first to carry out by hand the installation of each package and record what kind of dialog seems to accompany it?
If you want to get in touch with the pacman devs, use the pacman-dev mailing list. If the above constitutes a feature request, an accompanying patch or patchset would be a better way to get their attention.
Offline