I thought I'd better continue this conversation in another thread, rather than under the Announcement heading.
even so, take the person's pkgbuild and adapt it (update the pkgversion, for example) instead of creating a new one. Adapting existing ones is easier than starting from scratch when you are first starting out. Admire your enthusiasm. :-)
Thanks, Dusty.... although I wish I had a bit more "common knowledge" in this sort of thing. Oh well, maybe by next year this time, hey?
Well, I finished my "version" of the SuperKaramba package and compared that to what was already on the AUR. From the looks of it, the .tar.gz from the AUR site contains simply the PKGBUILD script (just a couple of bits in size).
Now, the .pkg.tar.gz I just made contains a bit more... 270K in size. Which brings up another question in my mind. When I started, the source .tar.gz was just over 1MB in size. Does this sound "typical"?
I'd compare it to the existing Superkaramba package in AUR, but, like I said, it only seems to contain the PKBUILD script.
Maybe I'm going about this wrong. Maybe I should try building a "trusted" pkg file from AUR for myself and see if I come out with something similar.
It's not critical for me to learn how to do this, but I'd feel better if I could contribute something back into the Arch community. And since I'd be installing some of these obscure apps on my system anyway, I might as well try and make them available for others, don't you think?
That's basically how it works. I think you're a bit confused about some things though. I'll try to clarify.
First, we have ArchLinux packages. These are tarballs containing files and instructions that allow pacman to manage those files.
Second, we have source tarballs. These are the files that a program developer puts on his site so that you can compile them yourself. You can create arch packages using these sources.
Third, we have PKGBUILDs. These are basically like "instructions" or recipes that allow you to create arch packages out of other stuff, such as source tarballs, or even binaries. The makepkg program takes a PKGBUILD as input and creates an arch package.
Fourth, we have repositories. These are collections of Arch packages (eg: [current], [extra], and [community]). pacman.conf can be configured such that pacman can get arch packages from them directly.
Sixth, we have user repositories. These are repositories such as the official ones, but are unofficial. The problem with them is if you don't trust the person who maintains the repository, you can't install packages from it because they may have included viruses, trojans, spyware, etc in it.
Seventh, we have AUR. This is a place where people can post PKGBUILDs they have created for other people to build using makepkg. This is secure because you can double check that the PKGBUILD doesn't include some virus in it or something.
Eighth, we have Trusted Users. This is a group of people that basically trust each other, and are repected in the community, such that we generally trust them too. They take the more popular packages from AUR unsupported and put them in AUR community. The difference is community is a repository, so it can be synced directly using pacman. TUs also verify the packages other users submit to ensure they can be trusted.
Ninth, we have aurbuild. This is a neat script Penguin wrote that automatically grabs packages from aur and builds them, giving you a chance to look at the PKGBUILD to ensure it is safe. aurbuild is, itself available from AUR. :-)
Now, having said all that, I would hope you don't want to have your own repository anymore, as in spite of your enthusiasm, I doubt anybody would trust you when they use it (no offense intended -- look at it this way, you're new at this, so you might make a mistake we don't want to duplicate :-)). However, you may be interested in this wiki: Custom_local_repository_with_ABS_and_gensync
Now, for this specific case, I would suggest contacting the maintainer of the package and see if he's not interested in it anymore. If not, he can orphan the package in AUR and you can adopt it. This will make you the maintainer, so you can update the PKGBUILD when new versions of the package come out.
And since I'd be installing some of these obscure apps on my system anyway, I might as well try and make them available for others, don't you think?
BTW This is the exact purpose of AUR. :-) It allows people to contribute PKGBUILD's for obscure packages only one or two others might be interested in, but at least then those people no longer have to figure out how to build it themselves. This is especially important with difficult packages that might need patching or additional sources, etc.
Thanks, once again, Dusty. Coming from the world of Debian and RPM, I admittedly was confused as to the whole AUR / PKGBUILD thing.
So, if I'm understanding you correctly, what I've built would be considered an arch package rather than an AUR PKGBUILD. Although it contains the application, it's considered an untrustworthy resource, as anything could have been built into the package.
A PKGBUILD is a better method, as it's simply a list of instructions for Pacman to go and obtain it's own source files and build them to work on an Arch system... along with any necessary dependency files. Is this correct?
Again, coming from the Debian world, I'm used to dealing in pre-built "packages", hence my unnecessary asphyxiation on providing compiled packages.... where PKGBUILDS are more than adequate.
a pkgbuild is the info passed to makepkg to build a pacman compatible package
Ah ha.... now all of the pieces are falling into place.
And, I'm assuming it's better to install packages this way, rather than simply doing configure / make / install from a source tarball as Pacman keeps "track" of the installed packages on the system.
I want to install Skype. So, I download the Skype PKGBUILD from AUR, run makepkg, then pacman the .pkg.tar.gz that makepkg as created for me. Right?
by jove I think he's got it........;)
Yes mate spot on, this way pacman always has control of what is on your system....
making it far easier to remove unused items, or update them ...
all the things a good package manager should do.
I must say it is really nice to see someone so keen, you should do well here
I'm here to learn..... and I'll drive you all crazy in order to do it, too!
but your asking the right type of questions, as opposed to stuff that is documented everywhere and warned of during updates.....
every post youv'e made states what you have tried and describes the problem quite well, then asks about something else...
this is good, but then you've come from debian....
ever visit the irc ther :shock:
Well, I'm glad to know that and do appreciate the guidance.
No, I've never visited the Debian IRC. Only been on the Kanotix IRC and forums, as that is the distro. I've been running on our "main" PC. The IRC and forums there are helpful and Kanotix is great, but I'm at the level now where I'd like to learn "why" as well "how" to do things with my Linux box.
Arch seems much better for that task than Kanotix. I find much of Debian to be quite "unreachable", at least for someone of my hacking skills. Arch seems much more open and "reachable" to me. The architecture, like rc.conf, seem much more logical in its set-up to me.
As I learn more about Arch, I'm taking notes for the transition of it onto our main PC. From all indications, I think maintaining an Arch system will be much easier than Debian, SID or otherwise. The recent issues with Debian and KDE related packages left a sour taste in my mouth; which is what lead me to Arch in the first place.
I'm also looking forward to the further development of Archie.
AH HAH! You can run, Judland, but you can't hide!
Cool - I'm glad I found this thread! I've been trying to figure this stuff out too since last weekend.
Unthinking respect for authority is the greatest enemy of truth.
Yup. I just finished setting up my main workstation. I'm not sure what to do with my lappy at this point, or how much work would be involved with setting it up with wifi drivers, sleep/hibernate, etc so I'm leaving it alone until I have more time to fool with it.
Unthinking respect for authority is the greatest enemy of truth.