- Arch-projects - lists.archlinux.org

[arch-projects] Pluggable wrapper
by Jason Chu 01 Sep '04

01 Sep '04

There are two conflicting schools of thought with respect to adding features to pacman: - everything should be written into pacman, because there's less to worry about that way - everything should be a wrapper, because it complicates pacman less For the most part, I believe the latter. There are some things that would benefit everyone if they were added to pacman, but most things would just add unnecessary complexity that's only used by a subset of all the users. There is a related issue to wrappers though: if you have more than one wrapper that do complimentary things, shouldn't you be able to run both of them at the same time? Enter the pluggable wrapper script. It would be event based, interfacing (almost) seamlessly with pacman, and allow you to enabled and disable wrapper functionality, such as srcpac. My two example cases were srcpac and rollbacks. Rollbacks could be implementable through such a system, but I'm already told it'll be going right into pacman itself. Another example is regular expression searching. What does everyone think of this idea? Is there enough demand for different functionalities that would be nice for some people but annoying, problematic or just stupid to add to pacman? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

4 9

[arch-projects] pacbuild
by Jason Chu 29 Aug '04

29 Aug '04

Here is my explanation and my current status with respect to pacbuild. I've been toying with the idea of an autobuilder for a while now, but only implemented it in the last 4 months. As it stands, I use it to keep i586 relatively up to date. Right now it uses python, postgresql, and user mode linux (UML). It's broken into three parts: 1) waka 2) catchup 2) checkbuilds Waka is the actual building daemon. It starts UML sessions using copy on write (COW) files, so that I can just throw away the build session after it's done. Catchup scans /var/abs looking for builds that are newer than the ones in the currently defined repo. Checkbuilds gives you the logs from built packages so they can be reviewed and marked as correct or not. If they are incorrect, they are marked in the db as incorrect and there is no attempt at building the same version again. If they are correct, they're added to the repo, old packages are removed and the db is updated. Rarely do I have to mark a build as incorrect, because most of them actually fail and are detected as such. As it stands, I have run into a few limitations of my current implementation: - distributed building with multiple wakas on remote machines - provides support - no support for extra scripts (such as a generated packages.txt needed for the current repo) Just glancing at the code, I might actually be able to add provides support fairly easily, to the catchup script. I'd have more trouble getting proper provides working within waka and makepkg. Distributed building is more difficult. My initial implementation uses the filesystem to store builds and pass around files and whatnot. I really don't know if I want to go to a db-storage solution or something else entirely. I would have to abstract the building and the managing aspects a bit more to make it work better. This will be something that needs a lot of thinking and designing. The extra scripts support will probably come along when I actually implement support for multiple repos. In my first version, only one repo is supported, that's one of the reasons only current is being built. I'm not exactly sure why I'm explaining this, I don't know exactly what you people could do without a lot more explanation... Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

2 2

[arch-projects] Configuration Management
by Paul Mattal 29 Aug '04

29 Aug '04

It would be nice to have a system within Arch to manage configuration files. I'd really like to be able to express my Arch Linux systems setups as a set of installed packages and a number of configuration sets and then not have to back up all the system files. This allows a sysadmin to create another Arch box just like the one he's already got in minutes. This system would allow one to easily package up configurations and deploy them to multiple machines. For instance, I set up each desktop user box in my office for printing in the same way, and I set up nfs to mount the same filesystems, and even enscript to use letter rather than A4 paper. It would be nice to be able to point each box at a "config repo" with configurations associated with packages, and then have pacman automatically pick up those configurations when I install the corresponding packages. I'd like to hear people's input on how to make this work best in Arch and whether or not they'd think it useful. I can describe something I've worked on for the arch-toaster by way of example of the kind of thing I'm talking about, which led me to desire a more general-purpose tool. For the toaster, I have an "arch-toaster" package which contains a lot of dependencies on packages the toaster needs, plus default configuration files and a fairly reusable perl script which had 2 main purposes: 1) to deploy the "default" configuration files to "current" locations (if there's no "current" version already) where they can be further customized, if desired 2) to deploy the "current" configuration files to their real "field" locations on the filesystem after editing, or after updating the system (since configuration files must in some cases replace package files), making backups as it does so to avoid ever destroying any intended changes made directly in the field Additionally, I added a third function to the script, useful in development: to roll the configuration files from the field back into "current" and store them in a tar.gz which I could then roll back into my package build as I refined the arch-toaster package. This was my means of collecting my changes as I went along. Then all I had to continue to maintain was the list of files that would be under control of my configuration management system, and it handled the rest. Anyhow, I'm mostly curious if people think this is a good idea, or if they think there is a better way, or both. This would be a sizeable project, but not that awfully complex, I don't think. - P

1 0

[arch-projects] Debian menu program
by Jason Chu 29 Aug '04

29 Aug '04

Many people have suggested a universal menu system (one that can keep every WMs menu up to date with all the packages installed on the system). People say that the freedesktop standard will do that for us and all we have to do is wait for WMs to support it. Personally, I think it'll be a while before all the WMs support the freedesktop standard and I'm not sure if we really should wait. Debian had a solution to this problem in the form of its menu program. The menu program consisted of a directory called /usr/share/menu that you stored a menu file in (the menu file describes categories, command names, and titles of programs; each package gets one but can describe multiple programs in a single file), definitions to create menus for each WM, and an update-menus script. The update-menus script would scan all the files in /usr/share/menu and generate menus for all the installed packages. This was done automatically by the dpkg program. My original idea was to port the Debian menu program (version 2) to Arch and add it as an optional service. Someone who has the menu package installed can run update-menus at any time and it would update all the menus for all WMs on the system. The purpose of this system was not to make stupider users but to simplify administration of systems. If I'm a sys admin for a box that has 4 users (let's say it's a family computer) and one user wants me to install freeciv so ge* can play it, do I want to help ger* to add a menu item as well? What if other people in the house want to play freeciv as well? Will I help all of them add these items to their menus? In this way, it simplifies administration, isn't mandatory, and doesn't hide anything. I did a little bit of research into using Debian's menu program, the problem is that depnends on Debian's dpkg. To make this work, someone would have to patch the menu program to work with pacman. Is anyone interested? Jason *ge/gis/ger are the newly proposed third person singular gender-neutral pronouns. Ge is similar to he, gis to his, and ger to him. -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

2 2

Re: [arch-projects] Proposal for additional gcc packages
by Paul Mattal 29 Aug '04

29 Aug '04

This is a good idea for other languages.. also for other platforms. Awhile ago I had to do some cross-compiling for arm, and I think I created a nice set of retargetable packages for compiling cross-compiler packages. I should dig these out and get them into the general consciousness. I keep meaning to eventually try the cross-compiled stuff on the old Intrinsyc cubes I used to use as dns/dhcp servers. At the time, I was cross-compiling for other purposes, but the cross-compiler worked great. - P

1 0

[arch-projects] Status update on the gcc packages
by Jason Chu 29 Aug '04

29 Aug '04

I was able to build f77 and java packages for this but I ran into a snag: they both share a file that isn't available in the original gcc package (/usr/lib/gcc/i686-pc-linux-gnu/3.4.1/include/nessus/net/bpf.h). I wouldn't want to make one of them depend on the other, but making a gcc-added-compat package is also probably a bad idea. Any suggestions to get around this problem? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

1 0

[arch-projects] Pacman improvement
by Tim Goff 25 Aug '04

25 Aug '04

this as probably been posted before but here's my idea: Instead of current [################] 100% 38K 14.2K/s 00:00:02 extra [################] 100% 147K 14.8K/s 00:00:10 We should change pacman to Instead of current [C...............] 0% 38K 14.2K/s 00:00:02 Instead of current [ C........] 50% 38K 14.2K/s 00:00:02 current [ C...] 75% 147K 14.8K/s 00:00:10 Current [ C] 100% 147K 14.8K/s 00:00:10 Just to reflect the name. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

4 11

[arch-projects] Proposal for additional gcc packages
by Jason Chu 25 Aug '04

25 Aug '04

This is something I've been kicking around for a bit. Having other gcc packages like gcc-f77 and gcc-java would be helpful, 1) to shut people like this up (http://bbs.archlinux.org/viewtopic.php?t=6376) and 2) for people who actually need a f77 compiler (or a java compiler or whatever). My idea goes something like this. Don't touch the gcc package. Instead, make a similar PKGBUILD that just compiles the additional languages. Compare that package's file list to the gcc package's file list and cull out the duplicates. As long as the existing gcc package doesn't store a list of compiled languages, then it should work. I've already built a gcc-f77 package based around this idea and gcc-java will soon follow. I do lack the skills to properly test the gcc-f77 package, though it is available here: http://xentac.net/~jchu/gcc-f77-3.4.1-2.pkg.tar.gz The way I've explained it so far, you may be wondering about gcc upgrades. The gcc-f77 package depends on gcc=$pkgver, so if gcc is upgraded before gcc-f77, pacman will complain. In that way, you'll never have conflicting package versions installed at the same time. The only drawback to this approach that I've found is that you compile gcc multiple times. The only solution to that is make a method to build multiple packages from one PKGBUILD. This goes against the KISS design philosophy and would break a lot of stuff for only a few benefits (a few packages). Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

3 6

[arch-projects] Initial Announcement
by Jason Chu 24 Aug '04

24 Aug '04

Hello to all, This will be my first email with my new gpg key... now, on to business. This mailing list was originally created because people finally were interested in helping out with interesting things in Arch. Up until that point, most of the drive for interesting things came directly from me, so I kept a lot of my ideas to myself. Now that other people have shown interest, we (the Arch Linux elite) have started this mailing list to propose, discuss, and plan interesting technology enhancements for Arch Linux. So that people don't have to ask a lot of the same questions about an idea when it is first proposed, I will put forward a format for all proposals to follow. Not so much a layout format, but at least an informational content format. All proposals should contain a description of the idea, an explaination of how it will help improve Arch, thoughts about how you came to that conclusion (goes with the explaination), and proposed technologies. The proposed technologies are optional; some ideas need a lot of research or the proposer lacks the necessary skill set. After something is proposed, discussion will commence. Remember to be courteous and professional. I don't want to be putting out flame wars just because two people don't like each other's mothers. This list will be *the* place to find dedicated, smart, and hard working people interested in solving interesting problems to help better Arch. I don't want this list to become another hey-I've-got-a-really-great-idea-to-make-things-really-really-super-awesome-who-wants-to-do-all-the-work list. People with ideas like that can go to the arch mailing list. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.

1 0