You are not logged in.
This is mostly just something that I did because I had never written a wrapper for pacman before and wanted to see if it worked with the current pacman feature set.
It's 1:30ish in the morning, so my eyes are a little blurry.
The wrapper is called srcpac. It's version 0.1 at this point
The code is quite ugly because I threw it together in the past 3 hours, but my inital tests have been successes.
Now, for the pitch. Imagine if you could use pacman to install binary packages as well as build those same packages from source (with your own optimizations). Not only that, but upgrades remembered which packages were precompiled and which were compiled on the spot.
Now, imagine that pacman didn't actually handle that, because the hard-core KISS people would complain too much and you wouldn't be able to think while you watch gcc output flash by. Imagine instead a wrapper around pacman that handled it for you.
Enter srcpac. Lights brighten, music comes to a peak, close up!
srcpac acts exactly the same as pacman (well, it should anyway), except you get this little extra flag -b (or --build) tacked on to -S (--sync) to build from source instead of install from a binary package.
Let's see an example:
srcpac -Sb w3m
will compile w3m, install it, and remember that it was compiled
srcpac -Sybu
will upgrade all the packages that need upgrading by building them and remember that they were compiled (be careful with this one, it will include packages that weren't previously compiled).
srcpac -Syu
will upgrade all binary packages by installing binaries and upgrade all source packages by compiling from source.
srcpac -Qi w3m adds an extra line too, "Source", with a simple yes or no.
Which packages are source and which aren't are stored in /var/lib/srcpac just as files. If the file exists, then the package was a source package (so it's easy to fix it if srcpac gets confused, also it doesn't touch anything pacman uses).
While I can guarantee that this wrapper won't break your packages (because it uses pacman and makepkg to do all of it's package related stuff), I can't guarantee it'll work 100% correctly (it's 1:45 now!).
If anyone is interested, the script is available here: http://xentac.net/svn/arch-tools/srcpac/tags/0.1/srcpac
Yes, it's in bash.
Feel free to tell me problems you run into using this tool. Remember, if you use pacman instead of using srcpac, then all the packages will continue installing as binary packages.
BEWARE: the -r option isn't fully implemented and may install to / in some cases, I'm pretty sure I don't ever write to / when -r is specified, but I can't be sure.
.:edit - changed title to show srcpac name - dibble:.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
If this proves popular ... could this feature be added to pacman in future versions... --build option :?:
Get some sleep
Mr Green....
Mr Green I like Landuke!
Offline
Offline
If this proves popular ... could this feature be added to pacman in furture versions... --build option :?:
Get some sleep
Mr Green....
If it proves popular, why not just leave it the way it is? The design works fine the way it is.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
me & my big mouth.....
Mr Green I like Landuke!
Offline
Wow.
Bows to Xentac with great respect.
Offline
I've been talking to contrasutra about support for custom package configuration changes. So that your gaim package can be compiled with spell support, for example. As long as the PKGBUILD format doesn't change a lot, it'll keep working across upgrades.
I'll probably implement this sometime when school isn't so overbearing.
It'll use sed, so you'll have to have basic knowledge about how a sed substitute works.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
So...I'm assuming that by what you're saying, we could just host source tar.gz files in a repository, and the command could download it and configure it, like a PKGBUILD? That's what I'm getting out of it... :?
So, if the above was true...it'd be like a Pacman/ABS type-system integrated into one, with the ability to use binary packages or source packages with ease...that's be sweet.
"Technically, you would only need one time traveler convention."
Offline
So...I'm assuming that by what you're saying, we could just host source tar.gz files in a repository, and the command could download it and configure it, like a PKGBUILD? That's what I'm getting out of it... :?
So, if the above was true...it'd be like a Pacman/ABS type-system integrated into one, with the ability to use binary packages or source packages with ease...that's be sweet.
No... more like, you store how you want the official PKGBUILD to change so that it's configured the way you want it to. Before building, the PKGBUILD is updated to reflect your changes. No source .tar.gz files.
srcpkg only works with abs right now. It'll need a bunch of re-thinking to work with other repositories.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
For building packages from source, there is a magnificent distribution named Gentoo. For a distro based on binaries, we have the magnificent Arch. Heaven would be a (meta) distribution using Gentoo if one wanted to build from source and Arch if one wanted to use binaries. Yes, one can use binaries with Gentoo, but it is nowhere near as nice as Arch. Seems like something of an afterthought. I reserve judgment on building packages from source in Arch (other than the old fashioned way in /usr/local).
Final thought. I couldn't image using Arch with non-broadband access, just too slow to download. With broadband, downloading is no longer a problem. However compiling still is with one box. My box requires over a day to build KDE. However, if you have several boxes, distcc could be the white knight. If one could build KDE in an hour......
"Es gibt nichts mehr praktish als theorie" L. Boltzmann
Offline
For building packages from source, there is a magnificent distribution named Gentoo. For a distro based on binaries, we have the magnificent Arch. Heaven would be a (meta) distribution using Gentoo if one wanted to build from source and Arch if one wanted to use binaries. Yes, one can use binaries with Gentoo, but it is nowhere near as nice as Arch. Seems like something of an afterthought. I reserve judgment on building packages from source in Arch (other than the old fashioned way in /usr/local).
Final thought. I couldn't image using Arch with non-broadband access, just too slow to download. With broadband, downloading is no longer a problem. However compiling still is with one box. My box requires over a day to build KDE. However, if you have several boxes, distcc could be the white knight. If one could build KDE in an hour......
That's.... uhhhh... great...
How it relates to srcpac, I'm not quite sure.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
Xentac, aside from his mention his compiling sluggishness (I know of that, too :cry: ), I think what's he's saying is that a combination of a Gentoo-type system and an Arch type system with the full features of both into one would be great...but as a "meta" distro, whcih I assume he's defining as "popular".
"Technically, you would only need one time traveler convention."
Offline
For building packages from source, there is a magnificent distribution named Gentoo. For a distro based on binaries, we have the magnificent Arch.
Bull. Arch is both binary oriented (pacman) and source oriented (ABS). Most people use binary only, a few people do it source only. People that need unavailable packages use both methods.
I reserve judgment on building packages from source in Arch (other than the old fashioned way in /usr/local).
in other words you don't know about, or don't like ABS and its simplicity??? :-$
Final thought. I couldn't image using Arch with non-broadband access, just too slow to download.
So funny, I never had any problem with it. I complain about dialup a lot, but I'm having no trouble with Arch on 33kbps.
Dusty
Offline
Xentac, aside from his mention his compiling sluggishness (I know of that, too :cry: ), I think what's he's saying is that a combination of a Gentoo-type system and an Arch type system with the full features of both into one would be great...but as a "meta" distro, whcih I assume he's defining as "popular".
Uh... excellent summary? why not just say "me too"?
Offline
Zephirias wrote:Xentac, aside from his mention his compiling sluggishness (I know of that, too :cry: ), I think what's he's saying is that a combination of a Gentoo-type system and an Arch type system with the full features of both into one would be great...but as a "meta" distro, whcih I assume he's defining as "popular".
Uh... excellent summary? why not just say "me too"?
Bah, I'm sorry that I analyze things.
"Technically, you would only need one time traveler convention."
Offline
First, one definition of meta is beyond, transcending, higher as in metaphysics (although I seriously doubt metaphysics transcends physics in reality.) Anyway, that was my rational for using "meta" distribution.
My reference to the /usr/local method was the sequence download-untar/unzip-configure-make make install. That is a fine methodology as long as nothing bombs in the configure or make stages that you can't diagnose. Perhaps it is "child's play" for all you CS types.
ABS is fine, but unless I am mistaken, it does nothing to ensure the configure and make stages go smoothly. It is a good way to integrate "home-rolled" packages into the Arch system.
Regards, Rick
"Es gibt nichts mehr praktish als theorie" L. Boltzmann
Offline
ABS is fine, but unless I am mistaken, it does nothing to ensure the configure and make stages go smoothly. It is a good way to integrate "home-rolled" packages into the Arch system.
hmmmm... I could be wrong because I've never used Gentoo, but if you make a package that doesn't already exist for Gentoo, does it do anything to make sure the compilation goes smoothly? If the package exists, then there is a way to build the package that has been tested by somebody else. This is how ABS works too; if a PKGBUILD exists, you can be reasonably sure it will work.
I can't imagine a program that can automatically fix or recover from compiler or Makefile errors. If it does, then... wow.
I assume that Gentoo has a larger package base than Arch, but let's not get into that discussiong again!
Xentacs script is basically designed to allow you to choose whether you are going to install from source or binary. Assuming the PKGBUILDS are in order (which for arch repository programs they are, because the binaries were built from them!), this should work as flawlessly as installing from binaries.
Dusty
Offline
To the best of my knowledge, if you want a package not in the Gentoo repository you are on your own. If it is in the repository, customization/fine-tuning is easy. Perhaps it is easy with srcpac.
"Es gibt nichts mehr praktish als theorie" L. Boltzmann
Offline
hmmmm... I could be wrong because I've never used Gentoo, but if you make a package that doesn't already exist for Gentoo, does it do anything to make sure the compilation goes smoothly? If the package exists, then there is a way to build the package that has been tested by somebody else. This is how ABS works too; if a PKGBUILD exists, you can be reasonably sure it will work.
Dusty
When I removed Gentoo to try Arch, I had around 70 updates waiting because one shitty dependency wouldnt compile.
Offline
you had just 70 ... thats why I wiped it from my HD
Mr Green..
Mr Green I like Landuke!
Offline
What do you do with that script. If you need to install it how do you... Im new to arch as you can see... And ive always done binary packages.. Just hoping this will get kde to work for me by building it.
Offline
cant i do something like that using my repo with my tweaked PKGBUIDLS
and using makepkg -si ?
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU/ d- s: a- C L U P+ L+++ E--- W+
N 0+ K- W-- !O !M V-- PS+ PE- V++ PGP T 5 Z+ R* TV+ B+
DI-- D- G-- e-- h! r++ z+ z*
------END GEEK CODE BLOCK------
Offline
You could, but every upgrade, you'd have to tweak some more. This way should be more automatic.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
I actually created a package. Anyone who wants to use srcpac to actually manage source packages can install it.
I've also added the support for package configs. There's no documentation on it, but it uses sed and is decently easy to understand. Have a look at the example /etc/srcpac.conf entry. I know it works because that's what I used to test with
Version 0.2 also includes the -o option to -S. This will apply config changes and less the PKGBUILDs without doing any building. I figured this would be a good way to test configs without a lot of manual labour.
I'll get to a manpage sometime later, maybe in version 0.3.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
I've been using it, and I have to say that it's a wonderful app. I know that you don't want to put it in pacman, because KISS people would complain, but I say, screw them, this tool is the best. I say "Revolution.........."
And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.
Offline