[pacman-dev] Future pacman development (3.2/4.0)
Here is a little email to get ideas flowing on what will follow the 3.1 release in pacman development. I might as well start it off with a bang by saying I think pacman (and especially libalpm) would be best if it got a full cleansing and rewrite. This is one of those things that is just tough to do, but I think all of us can see the benefits in doing it. We've seen where our current interface is a bit lacking, and we could find many ways to improve on that. There would also be the ability to rewrite pacman to be much more efficient in some of the operations that are currently the bottlenecks (namely lists). Lists could be replaced by hash tables in a few places (package caches?), and in other places we could simply use better list structures in order to navigate them more efficiently. I really like the idea of using a kernel list implementation to do this, as it would enforce typing. However, the details of that may need to be reasonably well hidden inside the library. If we were to do a rewrite, I think the best way would be to do it slowly and one piece at a time. Start with the backend interface and slowly build from there, setting interfaces at each level. Much of the code could be gleaned from the existing codebase, but scrutinized a bit to ensure it is of good quality and doing things the way we want to. Other code would end up in some burning inferno somewhere never to be seen again, which would make me more than happy. If we don't do a full rewrite, something that really needs looking at is the list data structures we use. alpm_list_last (called by alpm_list_add) is a huge bottleneck, consuming 40% of the time in a pacman -Su operation from start to when you are presented with the package list to install. That is pretty pathetic. A pacman -Qo operation is another great example of the inefficiency of the existing list structure. Thoughts and comments welcome. -Dan
On Wed, Aug 22, 2007 at 12:10:20AM -0400, Dan McGee wrote:
Lists could be replaced by hash tables in a few places (package caches?), and in other places we could simply use better list structures in order to navigate them more efficiently. I really like the idea of using a kernel list implementation to do this, as it would enforce typing. However, the details of that may need to be reasonably well hidden inside the library.
Yes, I see three important points where a rewrite would help : 1) More adapted and efficient structures A better list implentation looks indeed interesting, same for using hash tables where it's adapted. But what about trees / graphs ? http://www.archlinux.org/pipermail/pacman-dev/2007-June/008519.html 2) Transaction model You had some ideas about reworking transactions : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008544.html And Nagy as well : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009082.html It's probably important to take into consideration from the beginning that a basic install operation might induce a removal because of a conflict. Because in the current codebase, it looks like the removal operation was hacked on top of the code. Same for the upgrade operation. It's basically a remove + install, but the remove is a special one. For example, the files in backup array have to stay in place, instead of being removed, or move to .pacsave . 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 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 :)
2007/8/22, Xavier <shiningxc@gmail.com>:
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 (Роман Кирилич)
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. Bye, ngaba
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
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 ?
Since mplayer-svn provides/conflicts with mplayer, what's the problem with just doing : pacman -S mplayer-svn ? Hm, you are right. But conlict resolution works for -S only (not for -U). And fileconflicts cannot be resolved either...: Anyway, for pkglist<->pkglist fileconflict check+resolution we could use your check_conflict function (just using does_fileconflict as the "atomic" comparison (parameter)); and for pkg<->filesystem conflict we could use -Qo to determine the owner of the conflicting local file and may resolve the conflict by removing the owner. Bye, ngaba
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
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: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
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?
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? 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. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
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.
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.
Hm. Strange. Then I will send my working pactest files tomorrow (I'm on a Windows machine now), thx. But you can figure them out from the e-mail above ;-) Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
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/
2007/8/22, Dan McGee <dpmcgee@gmail.com>:
Here is a little email to get ideas flowing on what will follow the 3.1 release in pacman development.
[skipped]
Thoughts and comments welcome.
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. -- Roman Kyrylych (Роман Кирилич)
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 Wed, 22 Aug 2007 00:10:20 -0400 "Dan McGee" <dpmcgee@gmail.com> wrote:
Here is a little email to get ideas flowing on what will follow the 3.1 release in pacman development.
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. Along those lines, I think the back-end should handle configuration like this, however it could also provide an API to add repos or change these options permanently in the config file, so that GUI front-ends could implement a GUI configuration too for example. That wouldn't be entirely necessary though, but it would be a nice interface. 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. -- Travis
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, 25 Aug 2007 11:04:59 +0200 Xavier <shiningxc@gmail.com> wrote:
That's .. interesting :) http://archlinux.org/pipermail/pacman-dev/2007-June/008645.html
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.
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
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. Thanks Xavier, looks like I was beaten to the punch in both of my thoughts. -- Travis
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.
On Sat, 25 Aug 2007 15:25:33 +0200 Xavier <shiningxc@gmail.com> wrote:
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 :)
I suppose. It came up for me looking at writing a pacman PackageKit back-end. I realized I'd have to parse the config file, which really boiled down to nearly copying the parsing code directly out of the pacman code and pasting it into whatever I was doing. It occurred to me that this is probably going to happen in nearly every front-end that gets written, so that people can use command-line and GUI front-ends with the same config file, because seriously, who expects the front-end you're using to change which repos etc. you connect to? In any case, my coder's instinct kicked in and said "hey, if this code is going to be reused everywhere, why not put it in a common place, ie. libalpm?" I've read through the thread where VMiklos argued about the download code existing in libalpm. I agree with many of his arguments, actually - have the library provide a default download implementation and use a callback mechanism for frontends to override it. The same would also hold for configuration - one of the counter-arguments was "pacman.conf is pacman's configuration file, other frontends would be wise to use their own config file" and it's silly - you expect users or software maintainers to reconfigure umpteen config files to point to the same repositories. What if Arch gets some new official repos? Then everyone who decides to write a frontend needs to add it to their configs - the duplication of work is totally unnecessary. I say split out the frontend's configuration options from the backend's configuration options, and make two config files, each handled by their respective place in the code. That makes it easier on everyone, IMO, and is smarter all around. -- Travis
Hello, Na Sat, Aug 25, 2007 at 03:25:33PM +0200, Xavier <shiningxc@gmail.com> 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 8/31/07, VMiklos <vmiklos@frugalware.org> wrote:
Hello,
Na Sat, Aug 25, 2007 at 03:25:33PM +0200, Xavier <shiningxc@gmail.com> 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 ;)
Actually, the config parser SHOULD be in the frontend. 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. 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.
On Fri, 31 Aug 2007 13:27:29 -0700, eliott wrote
On 8/31/07, VMiklos <vmiklos@frugalware.org> 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
Hello, Na Fri, Aug 31, 2007 at 04:42:18PM -0400, Travis Willard <travis@archlinux.org> pisal(a):
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.
just revert some idiotic commits or see what's in pacman-g2, i already did this work almost a year ago. 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.. thanks, - VMiklos
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...
Hello, Na Fri, Aug 31, 2007 at 05:50:22PM -0700, eliott <eliott@cactuswax.net> pisal(a):
Open source is beautiful isn't it.
sure
Usually though, when people fork a project, they rename it.
is this some hint?
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.
correct. but pulling in a lot of change from pacman to pacman-g2 would gave back archlinux users their localized manpages, etc? i don't think so
I looked at the AUTHORS file in the frugal version of the sources...
if you think we removed anybody from the AUTHORS file then you're wrong - VMiklos
Bringing this back up (don't want any in-fighting here guys). On 8/31/07, Travis Willard <travis@archlinux.org> 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
On Wed, 19 Sep 2007 00:42:42 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Bringing this back up (don't want any in-fighting here guys).
On 8/31/07, Travis Willard <travis@archlinux.org> 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....
I finished the "library outside libalpm" which I called libalpm_config - I based it off a SAX parser, kind-of - and threw a git repo in my public_html folder on al.org with the branch - Dan grabbed that as a remote repo, but I don't think he's done anything with it since. http://www.archlinux.org/~travis/git/pacman.git is the repo. Don't have any fancy web-git set up for it tho. -- Travis
Hello, Na Fri, Aug 31, 2007 at 01:27:29PM -0700, eliott <eliott@cactuswax.net> 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
On 8/31/07, VMiklos <vmiklos@frugalware.org> wrote:
Hello,
Na Fri, Aug 31, 2007 at 01:27:29PM -0700, eliott <eliott@cactuswax.net> 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
Its great that your shortcut is working out for you. However, I wouldn't want to see an ugly shortcut become standard.
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
I said 'generally', and you pick out one library. Well done. Does libcurl have a conf file that it parses?
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
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.
Hello, Na Fri, Aug 31, 2007 at 05:44:01PM -0700, eliott <eliott@cactuswax.net> 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
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?
Ahh. Thanks for the background. Indeed, I did not know the history. Also, sorry if I came off a bit 'pissy'. I reread what I wrote and it wasn't as 'conversational' as it probably should have been. I do think (this is my opinion) that the parser and download code should be external to the libalpm library, in libraries of their own if need be, which pacman (and other front ends) can easily utilize. I suppose it is a bit of 'bikeshedding', talking about where I think the api should live....
participants (8)
-
Aaron Griffin
-
Dan McGee
-
eliott
-
Nagy Gabor
-
Roman Kyrylych
-
Travis Willard
-
VMiklos
-
Xavier