I've recently been looking at the code and I may be intruding here, but here's my opinion nevertheless. If you feel the need to correct me or comment, go right ahead. On 1/8/06, VMiklos wrote:

hi

is there any reason why the download code is in pacman and not in the library? yes, i know, this way the frontends are not forced to use libftp, for example they can use curl, if you want. but i think this is not the same situation as the list handling functions / GList (ie. at a gtk frontend)

imho placing the old download code in pacman, and not in the library is a disadvantage, and not an advantage

The way I see it it is always an advantage, it's simpler this way. It's entirely up to the frontends to download the packages and the db's. One can implement a more exotic method of download, for instance, the frontend could retrieve the packages with the help of a bittorrent library. That would alleviate the burden on the main or the mirror's server. Or one could check the packages for viruses, but I'm really just dreaming here...

or we could allow to use NULL as the download cb function pointer, and then use the our own download code

This, in my opinion, would be better, by letting the frontend choose.

opinions? if i would implement this then theoratically you wouldn't have objections?

udv / greetings, VMiklos

Hope you don't mind the intrusion, Joao -- A mind all logic is like a knife all blade. It makes the hand bleed that uses it. -- Rabindranath Tagore (1861-1941)

On Mon, Jan 09, 2006 at 08:59:05PM +0100, Aurelien Foret wrote:

What's the idea behind this proposal?

to prevent code duplication - the duplication of download code in each frontend. writing a simple C funtion that does the same as "pacman -S foo" is currently means that every frontend is _forced_ to use its _own_ download code. for example if we add rsync support to pacman, and users start to use that protocoll in pacman.conf, then every frontend have to support that protocoll. if we would provide a default download code (see my previous mail, for example by allowing to pass NULL as the download callback function pointer), then the frontend are free to choose: to use or not to use the download code provided by the library udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

On Tue, Jan 10, 2006 at 01:13:37AM +0100, Mark Rosenstand wrote:

As a programmer who (unlike you) have contributed zarro to pacman, I think transfer protocol code, argv parsing etc. in the library would not only bloat alpm but also make the whole library split less meaningful.

you could set the protocol via alpm_set_option(), don't worry :) btw, here is an another example, maybe this one will be better probably after the library will have a stable api, we (the Frugalware devs) will: - create a graphical fronent which uses libalpm - replace our installer's ugly system() calls with proper libalpm calls the proble: pacman, the gui and the installer will contain the download code three times without any reason my proposal is to provide a default download code in the library, so that the frontends are free to choose if they want to use their own download code or the library's one advantages: - prevent code duplications - more freedom to the fronents: they can choose if they want to have their own download code or not (currently they're forced to have) disadvantages: - are there any? hth, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

On Tue, Jan 10, 2006 at 10:49:20PM +0100, Aurelien Foret wrote:

...

if we would provide a default download code (see my previous mail, for example by allowing to pass NULL as the download callback function pointer), then the frontend are free to choose: to use or not to use the download code provided by the library

I see your point, but all in all, I still consider that the download code must be kept away from the library.

even the integrity checks? udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

VMiklos wrote:

i mean that te integrity checks are done by the frontend currently but we could move that to the lib. you said no for the download code (in libalpm), you say no for the integrity checks in the lib, too?

Since the md5sum is an entry of sync databases, it can make sense to have the library checking it. There's currently only one place in the library code where it could fit: the beginning of the sync_commit function. But, I'm quite reluctant to add it there: that's absolutely not the purpose of this function. Anyway, the library already provides a way to get the md5sum entry from a sync package, and it also provides a function to compute the md5sum of a given file, so that there's almost nothing to do on the frontend side... -- Aurelien

Aurelien Foret wrote:

VMiklos wrote:

...

i mean that te integrity checks are done by the frontend currently but we could move that to the lib. you said no for the download code (in libalpm), you say no for the integrity checks in the lib, too?

Since the md5sum is an entry of sync databases, it can make sense to have the library checking it.

There's currently only one place in the library code where it could fit: the beginning of the sync_commit function. But, I'm quite reluctant to add it there: that's absolutely not the purpose of this function.

Anyway, the library already provides a way to get the md5sum entry from a sync package, and it also provides a function to compute the md5sum of a given file, so that there's almost nothing to do on the frontend side...

Eventually, I've moved the integrity checks from the frontend to the library by adding the "alpm_pkg_checkmd5sum" function. I didn't think of it at the time of this discussion, but in the end, it looks quite good to me... -- Aurelien