- Pacman-dev - lists.archlinux.org

[pacman-dev] pacman and perl
by Charles Mauch 12 Oct '06

12 Oct '06

I just joined this list to ask a few questions about perl modules in arch, and to explain (whine) about some of the workarounds I've tried to keep my own modules up to date with the CPAN archives. First, I'd like to say that for the most part, the perl modules provided by the arch devs for the most part work fine. But there always seems to one or two that are out of date. This isn't a problem unique to arch, I run a couple of debian boxes and run across the same situation all the time. There are simply so *many* possbile modules it can be an impossible situation to keep current. Because I can't live without the latest and greatest, over time I've come up with a few workarounds that I'd love to eliminate. First, I use pacman.conf to block the installation of a few modules, and keep my own copies maintained. Some packages simply INSIST on being managed by pacman, so in that case - I usually let arch have it's way an download and install what packages I want newer versions of into a ~/perl directory. By setting the PERL5LIB variable, I can ensure my local copy gets used instead. Unfortuatly, my ~/perl directory is growing at a rapid clip in arch. So here are some suggestions I think would make perl hacking in arch easier. 1. Dump whatever perl-module naming scheme (if there is one) for arch perl modules and simply use the CPAN module name. I don't know how many times I'll lookfor Foo::Bar, only to discover pacman's named it perl-bar-foo or some other nonesense. Is there a current naming scheme for modules? 2. I dont know how reasonable this is, but I would *love* to manage all my packages with the cpan tool. Maybe pacman could act as a wrapper to the cpan command? Or as an alterative, maybe provide an option to install cpan modules instead of packages into some other directory. Yes, I know the implications of something like this on PKGBUILD's might be horrendous. :) 2a. Yes, cpan is horrible at times. An alternative might be cpanplus. 3. Another idea would be to create a small tool which creates pacman style tarball bundles out of *all* the cpan modules once every few weeks, and stores them on a repo somewhere. Something like http://rpmpan.sourceforge.net/ for arch. This would eliminate the need for cpan at all. When i dicovered http://perl.arix.com/cpan2rpm/ I just about sh*t myself the idea was so cool too :) I do not have a webhost that could host or build this kind of repo, but I'd be happy to help maintain/run such a system. Anyway, some ideas. Thoughts? Am I just spinning my wheels? -- Take it easy, Charles FSF Apologist, WikiNut, Concrete Analyst, etc. :: Playing "Hang Tough" by Fluke (Puppy)

5 5

[pacman-dev] $ARCH suffix on packages
by Aaron Griffin 11 Oct '06

11 Oct '06

So I actually expected someone to start this, as I was curious. I know frugalware uses the architecture suffix on packages, and Xentac thinks this is a good idea. I'd like to hear reasons. I don't really feel that "RPM and DEB do it" is a good enough reason. I mean, if that reason was good enough, we'd be using RPM/DEB in place of pacman packages. The way I see it, I don't think pacman needs to know the architecture it's running on. Installing "pkg-foo" should be no different on i686 or PPC. Therefore, I think that adding the architecture suffix is extra information that's not really needed. What is gained by having this suffix?

9 29

[pacman-dev] Documentation
by Aaron Griffin 09 Oct '06

09 Oct '06

I have merged all the changes from frugalware, and all pactests work (except for sync898 which VMiklos and I already talked about). Now, I'm on to the documentation. $ grep -ir "frugal" | grep -ve "@frugalware.com" | wc -l 385 That's without email addresses. So yeah, I didn't pay attention to the documentation patches. Most of these changes are PKGBUILD -> FrugalBuild. I think I caught all the pkg.tar.gz -> fpm and db.tar.gz -> fdb changes before patching. I'd like to see if we can some up with a decent way to allow for us to use the same documentation base, as sedding this stuff on merge seems like a waste of time. The simplest solution is to just make them all .in files and set autoconf variables like: BUILD_SCRIPT_NAME = PKGBUILD PKG_EXT = pkg.tar.gz #already discussed in the TODO etc etc Does this sound worthwhile? Are there other ideas? I'm trying to open up discussion here and look for any and all suggestions. Thanks in advance, Aaron

4 6

[pacman-dev] Problems with frugalware splitname changes
by Aaron Griffin 09 Oct '06

09 Oct '06

The changes to the alpm splitname function are fine and all, except they do not accomodate archlinux packages, which do not append the architecture to the end of the package name (instead we put them in directories based on the architecture). Could you please make these changes so that they can accomodate for either arch of frugalware? Currently, it directs pacman to install a foo-1.0-1-.pkg.tar.gz package. (note the trailing dash). I have a few more things to delve through, but I won't be back until late tonight, so I figured I could poke you guys to make the change (if you have time). Thanks, Aaron Griffin

6 21

[pacman-dev] [PATCH] Java bindings
by VMiklos 08 Oct '06

08 Oct '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=2… so finally after python and perl, java bindings arrived :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

2 1

[pacman-dev] Time for changes
by Aaron Griffin 07 Oct '06

07 Oct '06

Ok, I think it's about time I picked up pacman developement, seeing as we really have no one else doing it. I've been busy, so I was really hoping someone else would volunteer, but what the hell. If you frugalware guys could send me a full diff (here or offlist) of your repo compared to the trunk, that'd be great. I don't like applying patches without verifying them, so I'm going to step through each hunk (this is why I originally requested them as the seperate patches sent to the ML, but I can deal with it either way). One thing i plan on doing right off the bat: I want to enable a side-by-side install with the current pacman, so that we can get some real testing by those (like me) who don't want to overwrite the stable pacman. This is just informational, but it shouldn't affect the frugalware guys. To the furgalware team: you have more experience with this new pacman that I do... could you give me a brief "what's changed" - functionality wise. I mean, when actually using pacman3, what is done differently? What future directions are we going for? I'd like to get this stable as soon as possible, but once that's done, I have a handful of nifty features I wanted to add (those on the dev list: I want to add filesystem hooks first, then some more advanced output logging). There are also some potential changes to gensync and friends, depending on what direction we go with some svn changes... but that's off topic. Anyway, let me know. Aaron Griffin - phrakture -

12 50

[pacman-dev] [PATCH] support for mtime checking @ http database download
by Tino Reichardt 24 Sep '06

24 Sep '06

Hello list, I have done a small patch, which adds mtime checking for the database download on http archives... overview: - one new function called HttpGetMod() in ftplib.c - some new if's @ pacsync.c I think there may be a need for it ;) -- regards, TR

3 9

[pacman-dev] [PATCH] yesno(), cb_trans_evt(): print questions and events to stderr
by VMiklos 15 Sep '06

15 Sep '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=2… pacman's man says: -p --print-uris Print out URIs for each package that will be installed, including any dependencies that have yet to be installed. These can be piped to a file and downloaded at a later time, using a program like wget. so in yesno() and cb_trans_evt() we should print our additional messages to stderr udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

1 0

[pacman-dev] The state of Pacman 3, again...
by Roman Kyrylych 11 Sep '06

11 Sep '06

Hi all! I don't know is it OK for me to ask such question here, but where is Aurelien Foret? And who is going to continue Pacman 3 development? I know that phracture had such plans, but IIRC he is currently busy. IIRC dsa also was going to take a look at Pacman code. I didn't hear anything from Judd Vinet recently too. And AFAIK most other developers have vacations or exams. In the last newsletter there was a line about recruiting new developers, so maybe some of them will take a look at Pacman? VMiklos is sending patches from Frugalware's branch but there are nobody in Arch team who applies them. This is sad. I hope the situation will change in the next few months. -- Roman Kyrylych (Роман Кирилич)

4 8

[pacman-dev] [PATCH] db_search() -> alpm_db_search()
by VMiklos 06 Sep '06

06 Sep '06

hi this 2 patches move pacman's db_search() to libalpm since most frontends would have some search functionality http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=2… http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=2… ps: everybody on vacation? :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

1 0