- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] _alpm_downloadfiles_forreal(): fix a buffer overrun
by VMiklos 23 Oct '06

23 Oct '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=2…; udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

2 3

[pacman-dev] Frugalware changes merged.
by Aaron Griffin 21 Oct '06

21 Oct '06

So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware). Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there. A few changes I made while testing this out: alpm_parse_config additional parameter for the current section. This allows for sections to be declared before include files (this is the way the arch configs currently work). I actually like this more, and it doesn't break anything. I moved the <repo>/<group>/<pkgname> <version> output to look like on of: <repo>/<pkgname> <version> (<group>) or <repo>/<pkgname> <version> This is because, unlike frugalware packages, not all arch packages are grouped, so there was alot of "current/(null)/foobar" output. Also, I think the fake pathing could potentially be confusing for some users. We could probably find a common solution to this here... lemme know if you guys have any suggestions that fit with both arch and frugalware. I also moved the ftplib progress info to the front of the bar, so that the progress bar aligns with the other progressbars. Other than those, I think the functionality is all there. There's some code cleanup I want to do too, but that's unimportant right now. Next on the list is doc cleanup.

6 26

[pacman-dev] [PATCH] alpm_db_update() fix up the level parameter
by VMiklos 19 Oct '06

19 Oct '06

http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=2… it was an inlogical implementation from me, currently 1 means false udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

2 1

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

19 Oct '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=2…; since most frontend will provde some kind of search functionality, i think this belongs to the library, too udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

2 3

[pacman-dev] perl module repo
by Charles Mauch 18 Oct '06

18 Oct '06

Just thought I'd drop a note in here. After quite a bit of hacking on cpan4pacman and my own perl scripts, I've finally been able to put together a repository of perl modules which solve many of the problems I mentioned earlier perl-module whine-o-rama. :) Shadowhand was gracious enough to allow me to host an external version of this repository on his box. http://wiki.archlinux.org/index.php/PerlCPAN_Repository The build process is fairly error-free at this point, though it took more than a week of hacking to get it error-free. :) The process works something like this.... 1. Every night my cpan modules list is updated via a cron job. 2. About 30 minutes later, I scrape the above url for modules to build. 3. If there is a difference between the cpan module version and the repo version, the module is built, and a build-report is generated. 4a. The next morning I commit any changes to the repo via svn. 4b. I have code ready to auto-commit changes to the repo, but I'd like let things run for a week or two before I allow the script to bypass the last vestiges of human control of the process. :) Before I make any real annoucements on the BBS, I was wondering if a few of you could subscribe to the repo and let me know that it seems to be working okay. It works fine *for me*, but that does not mean this process or the repo itself is robust enough for general use. I need beta testers! It will be great to see cpan or cpanplus integrated into pacman, but I think this works as a great near-term solution or a long-term alternative. -- Take it easy, Charles FSF Apologist, WikiNut, Concrete Analyst, etc. JABBER: cmauch(a)gmail.com GIZMO: charlesmauch AIM: cmauch5 :: C isn't that hard: void (*(*f[])())() defines f as an array of unspecified size, of pointers to functions that return pointers to functions that return void.

3 4

[pacman-dev] Things to iron out
by Aaron Griffin 17 Oct '06

17 Oct '06

There are some differences of opinion on some of these things - I'd like to hear developer opinions (especially judd) on the following topics, so we can get a few of these things out of the way: ** -$ARCH package name suffix - do we want this? How should we handle backwards compatability if we do move to this scheme? ** SHA1 vs MD5 - opinions/views on this? I know frugalware seems to like sha1, but md5 is the defacto file-validation mechanism (if only for checking if the download is uncorrupted). As Juergen brought up on the arch-dev ML: md5 may be easy to collide when dealing with something like ps files that contain hidden data, but binary files, like .gz files, are very difficult to find collisions for. ** Version number - Frugalware is currently at 3.4.X, while we haven't released a single 3.0 release - how should we handle this? Jump right into 3.5 ? ** Anything else? I'd like to hear any outstanding issues the Frugalware peeps have. Thanks, Aaron

6 5

[pacman-dev] RC delay
by Aaron Griffin 13 Oct '06

13 Oct '06

Just wanted to let anyone interested know that I haven't had time over the past 3 days to do anything worthwhile with pacman... I had planned on pushing an RC out, but won't be able to do it until early next week... currently everything works except the actual downloading and haven't had a chance to determine the exact issue... Side note though, _alpm_downloadfiles_forreal doesn't use the PM_ERR_* error codes, and returns 1 on error, which happens to be "Out of memory".

2 2

[pacman-dev] What about managing optional dependencies?
by Alessio 'mOLOk' Bolognino 13 Oct '06

13 Oct '06

I'm not (yet :) a good C programmer, so it's just a hint, and I don't know if it's easily implementable in pacman, but sometimes there is software that works even without another one, but having this installed let you perform other functions (probably this sentence is bad written, hope you all know what an "optionale dependency" is ;) . As you know there is no way in pacman to handle this kind of dependency except writing a warning message in the .install . I think would be useful to have (at least) an array where to put this type of deps. Am I just a fool? -- Alessio 'mOLOk' Bolognino

6 10

[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