2007/8/22, Xavier :

Anyway, I also think pacman would benefit from a rewrite, but for it to be really helpful, a deep understanding of the code and its current flaws is needed. And I think I would need 10 years for getting to this point.. But you are probably able to do a nice cleanup :)

On the other hand - taking part in a complete rewrite from prototyping stages to working implementation makes involvement more people in coding alot easier IMHO, because newcomers won't have to dig through the complete code with its workarounds and hacks trying to understand WTH is going there. -- Roman Kyrylych (Роман Кирилич)

On Thu, Aug 23, 2007 at 02:53:28PM +0200, Nagy Gabor wrote:

...

And Nagy as well : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009082.html One more argument for universal transactions: Now it's not easy to replace a package "by hand". For example if I want to replace mplayer with mplayer-svn I can do pacman -Rd mplayer then pacman -S mplayer-svn, but I might have broken some deps. (Cascade remove doesn't help here either.). With universal transaction this would be easy.

Since mplayer-svn provides/conflicts with mplayer, what's the problem with just doing : pacman -S mplayer-svn ?

3) Files extraction

maybe using suffix like dpkg does : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009139.html

Being able to cleanly rollback when an error comes up would be pretty neat. Maybe this could also helps limiting the number of times the archive is read: http://www.archlinux.org/pipermail/pacman-dev/2007-July/008751.html

It's possible to test these problems with pactest files? If yes, I would provide some exotic tests... Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

On Wed, Sep 19, 2007 at 04:23:33PM +0200, Xavier wrote:

On Wed, Sep 19, 2007 at 04:00:30PM +0200, Nagy Gabor wrote:

...

...

3) Files extraction

maybe using suffix like dpkg does : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009139.html

Being able to cleanly rollback when an error comes up would be pretty neat. Maybe this could also helps limiting the number of times the archive is read: http://www.archlinux.org/pipermail/pacman-dev/2007-July/008751.html

It's possible to test these problems with pactest files? If yes, I would provide some exotic tests...

I believe Dan hoped someone could extend pactest so that it would be possible. I never took the time to look at pactest though, There are always other things to look at :)

Dan already made a step in the direction though : http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=19f66083f0aef92af... but there is a TODO left :p

Hmm, I'm really confused about this... TODO: add the ability to add different types of files (eg links) via the test package building framework, and add the ability to change the modes on files. But from pactest README : 198 It is possible to create directories by appending a slash "/" to the name and 199 to create symlinks by appending an arrow followed by a filename " -> target". So it looks like the first part was already implemented, doesn't it? Nagy, what kind of pactest did you want to write?

On Mon, Oct 08, 2007 at 07:46:31PM +0200, Nagy Gabor wrote:

I want to write pactest files for the 2 problematic cases I mentioned here: http://www.archlinux.org/pipermail/pacman-dev/2007-August/009055.html If lp.files = ["symdir/ -> dir/"] worked, I could do this easily; but that doesn't work. And I have no other idea. Anyway, thx for your note, I didn't know the symlink feature earlier.

Hm, that's strange, I also had problems by trying to put files on the first level. But putting them inside a directory, like in the README, seems to work better. Attaching a sample.

Hi! The first problem can be fixed using realpath(). However, the second (rare, but very difficult to fix) pactest shows that this is not enough :-( fileconflict001.py: =================== self.description = "Fileconflict with symlinks" lp = pmpkg("dummy") lp.files = ["dir/realdir/", "dir/symdir -> realdir" ] self.addpkg2db("local", lp) p1 = pmpkg("pkg1") p1.files = ["dir/realdir/file"] self.addpkg(p1) p2 = pmpkg("pkg2") p2.files = ["dir/symdir/file"] self.addpkg(p2) self.args = "-A %s" % " ".join([p.filename() for p in p1, p2]) self.addrule("PACMAN_RETCODE=1") self.addrule("!PKG_EXIST=pkg1") self.addrule("!PKG_EXIST=pkg2") ------- fileconflict002.py: =================== self.description = "Fileconflict with symlinks (2)" p1 = pmpkg("pkg1") p1.files = ["dir/realdir/file", "dir/symdir -> realdir"] self.addpkg(p1) p2 = pmpkg("pkg2") p2.files = ["dir/symdir/file"] self.addpkg(p2) self.args = "-A %s" % " ".join([p.filename() for p in p1, p2]) self.addrule("PACMAN_RETCODE=1") self.addrule("!PKG_EXIST=pkg1") self.addrule("!PKG_EXIST=pkg2") ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

How about simplifying file backend storage structure: eliminate the $repo/$pkgname-$pkgver-$pkgrel/{desc,depends} tree and use simple $repo/$pkgname-$pkgver-$pkgrel where info desc and depends is stored. This was discussed some time ago and AFAIR there were no objections. Well, IMHO this is useful for sync repos only... And for sync repos I can imagine better read-only optimized storing (one file, dbms ...), but the devels probably don't want to write 2 different backends (for sync and local repos)

I also think, that the current backend structure is quite inefficient (I also suggested some modifications earlier...). The main problem, that the local repo structure cannot be modified easily (I would prefer an extension of the current structure with symlinks for example...): we cannot implement it slowly, because users don't want to convert their localdbs too often ;-) Personally, I don't like the fact that localdb stores implicit pkg-pkg relations (requiredby foo, depends providedfoo) instead of storing the _dependencies_ properly <- we need to compute them from these implicit informations all the time (pkgcache has the same limitation here). Group storing is also really inefficient (the slowest set implementation...), grpcache helps a bit here. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

On Sat, Aug 25, 2007 at 12:56:47AM -0400, Travis Willard wrote:

One area I can see much improvement in is configuration. I've noticed, poking around the code, that parsing the configuration file and applying the configuration once parsed is all left up to the front-end. Why is this?

Looking at pacman.conf, the single configuration option that's front-end-specific would be ILoveCandy. Everything else - repo locations, holdpkg, ignorepkg, noextract, and so on - seem to be options that users would want to persist no matter what front-end they're using. If they launch the command-line pacman, or a KDE front-end, or a Gnome front-end, the repos, ignored packages, held packages, and so on should all be the same - in 99% of the cases, I'd be willing to be the user would expect pacman to fetch from the same repos no matter which front-end they used, for example. This means that every front-end will be parsing the same configuration files, using their own code to do so, and will be re-inventing the wheel many times over.

That's .. interesting :) http://archlinux.org/pipermail/pacman-dev/2007-June/008645.html

Another improvement in the config area would be a better way to specify repositories. This has been brought up before - there's a lot of copied info between the files in /etc/pacman.d and it can be annoying to need to change 3-4 files if you want to change your mirror. While I'm not sure of how the syntax would look, specifying a base URL for the mirror combined with which repos that mirror contains would probably be the best bet.

Anyway, there's my two cents.

Did you have a look at pacman 3.1 ? There is just one file left, but not sure if it's done the way you wanted : http://archlinux.org/pipermail/pacman-dev/2007-July/008941.html

On Sat, Aug 25, 2007 at 09:13:50AM -0400, Travis Willard wrote:

lmao - looks like I'm a little late into this discussion, aren't I? Oh, well, if you guys really think it belongs in the frontend, I guess that's where it's going to stay.

I don't really have any strong opinion on this. But now vmiklos got some backup :p Considering it has just recently been moved back to the frontend, where it originally was, I don't see it moving again any time soon though. So I'm afraid you are a bit late indeed. But maybe just wait for Dan's answer on your concerns :)

DAMNIT - foiled again. Yeah, that's a great way to do the mirror list, although it lacks the capability of saying "Mirror X supports only current and extra" - I suppose if there's a fallback mechanism to the next mirror on the list if the first fails, then it's handled on its own.

That's what is supposed to happen indeed.

Hello, Na Sat, Aug 25, 2007 at 03:25:33PM +0200, Xavier pisal(a):

I don't really have any strong opinion on this. But now vmiklos got some backup :p

:P having the config parser in the frontend is a very very bad idea imho, just i don't want to flame on this list all the day ;) - VMiklos

On Fri, 31 Aug 2007 13:27:29 -0700, eliott wrote

On 8/31/07, VMiklos wrote:

...

having the config parser in the frontend is a very very bad idea imho, just i don't want to flame on this list all the day ;)

Actually, the config parser SHOULD be in the frontend.

Well, maybe it's better to say the config parser SHOULDN'T be in libalpm - where it SHOULD be is still up for debate. (leading up to your comment below)

libalpm is a library. Libraries don't generally parse configs. They receive config values through the api, at run time.

pacman is effectively a front end for libalpm. Thus, pacman should parse the pacman.conf config file.

Thinking about it further, I do agree with you - libalpm is not the place for config parsing. However, I still think that there are too many options in pacman.conf that shouldn't be tied directly into the 'pacman' frontend for libalpm - splitting up configuration files into 'pacman' specific stuff and generic stuff (like mirror lists, servers, and so on) should still be a must. (leading up to your comment below some more)

There could certainly be a configuration parsing library, that front-ends can share, but it doesn't need to be tied into libalpm. That should just handle package management.

Now this, I think, is a cool idea. Keep libalpm pure, but still provide a way for multiple front-ends to share the configuration data that, IMO, _needs_ to be shared between front-ends. Something like... "libalpm-config" because I'm creative that way. I'm not sure if it should be a generic config-file-reader or if it should specifically be designed to load only the backend-config options, such as servers, and pass the necessary info into libalpm. So, my points are: 1) Backend configuration should be split into a different file from frontend configuration. 2) A library outside libalpm should be responsible for parsing, at least, the backend configuration file and feeding that into libaplm, to maximize code re-use. Please comment and help me flesh this out - I think we're on the right track here. If we can get a solid idea of what would be the best way to handle this, I'll start hacking it together. -- Travis

just revert some idiotic commits or see what's in pacman-g2, i already did this work almost a year ago.

Open source is beautiful isn't it. Usually though, when people fork a project, they rename it.

unfortunatelly it's a rule that after more or less time everything (bindings, localized manpages, now the config parser move) gets reverted which was originally done by krix or me before the fork..

I guess you haven't synced the trees in a long time then. I looked at the AUTHORS file in the frugal version of the sources...

Bringing this back up (don't want any in-fighting here guys). On 8/31/07, Travis Willard wrote:

So, my points are:

1) Backend configuration should be split into a different file from frontend configuration. 2) A library outside libalpm should be responsible for parsing, at least, the backend configuration file and feeding that into libaplm, to maximize code re-use.

Please comment and help me flesh this out - I think we're on the right track here. If we can get a solid idea of what would be the best way to handle this, I'll start hacking it together.

Travis, what's the status on this? I'm still really on the fence about this - both sides have very strong points, and I really don't know where to go with it.... - Aaron

Hello, Na Fri, Aug 31, 2007 at 01:27:29PM -0700, eliott pisal(a):

Actually, the config parser SHOULD be in the frontend.

wrong. for example we have gfpm, a graphical frontend. having only a signle parser in libpacman to parser the configured repos is great, and i think all the users would be unhappy if they would have to always update gfpm's config accordingly

libalpm is a library. Libraries don't generally parse configs. They receive config values through the api, at run time.

really? just think of libsasl's /usr/lib/sasl2/smtpd.conf

pacman is effectively a front end for libalpm. Thus, pacman should parse the pacman.conf config file.

There could certainly be a configuration parsing library, that front-ends can share, but it doesn't need to be tied into libalpm. That should just handle package management.

yes, of course. then please remove -ldownload from libalpm's LDFLAGS thanks, - VMiklos

Hello, Na Fri, Aug 31, 2007 at 05:44:01PM -0700, eliott pisal(a):

I said 'generally', and you pick out one library. Well done. Does libcurl have a conf file that it parses?

yes, inetrc

I actually *do* think that libdownload should be in its own library.

You sure do have a snarky way of carrying on a discussion VMiklos.

i think this is related. okay, probably you are not familiar with the not-so-recent history of libalpm. i wanted the download code to be in the lib, but when i submitted the patch then Aurel rejected it. then later Aaron merged it. i mentioned this because we're talking about what should be in libalpm and what not. originally Aurel said no for both the download code and the config parser. later Aaron merged both. now it seems that the config parser move is reverted. how mentioning the 'revert of the download code move' is unrelated? thanks, - VMiklos