[pacman-dev] download code in pacman

VMiklos

8 Jan 2006 8 Jan '06

10:05 p.m.

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 or we could allow to use NULL as the download cb function pointer, and then use the our own download code opinions? if i would implement this then theoratically you wouldn't have objections? udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Show replies by date

Joao Estevao

9 Jan 9 Jan

12:44 a.m.

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)

Aurelien Foret

7:59 p.m.

Joao Estevao wrote:

...

...
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...

I second Joao's opinion: I can hardly think of a good reason to put the download code on the library side. The idea so far is to keep the library preporagatives to a simple set of opeartions relating to packages installation/removal. The file download is a high-level feature, let's say provided by the frontend for more conveniency. What's the idea behind this proposal? -- Aurelien

VMiklos

9:06 p.m.

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

Mark Rosenstand

10 Jan 10 Jan

12:13 a.m.

On Mon, 2006-01-09 at 22:06 +0100, VMiklos wrote:

...

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.

Isn't pacman.conf pacman's configuration file, i.e. not related to alpm? :-) 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. -- Mark Rosenstand ,;-, ,oOQ Arch Linux /_,K` (§§) Department of Footware ` ` `G

VMiklos

12:25 a.m.

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

Aurelien Foret

9:49 p.m.

VMiklos wrote:

...

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.

I don't think the code duplication is that important: the download code from pacman is big because we're depending on libftp, which is quite basic and limited as a transfer library. Achieving the same result with a decent library (e.g libcurl) would require far less code and efforts.

...

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.

pacman.conf is pacman's configuration file. If other frontends choose to use it, they will become tight to it and to pacman evolutions. A wise frontend should use its own configuration file. Anyway, if packages can be made available from FTP, HTTP, or rsync servers, the frontend remains free to choose whatever protocol it wants to support.

...

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. -- Aurelien

VMiklos

13 Jan 13 Jan

12:36 a.m.

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

14 Jan 14 Jan

8:13 p.m.

On Fri, Jan 13, 2006 at 01:36:03AM +0100, VMiklos wrote:

...

even the integrity checks?

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? udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aurelien Foret

15 Jan 15 Jan

9:54 p.m.

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

VMiklos

10:25 p.m.

On Sun, Jan 15, 2006 at 10:54:20PM +0100, Aurelien Foret wrote:

...

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...

ok, so then this is just yet another patch that will never hit the arch cvs ;) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aurelien Foret

5 Feb 5 Feb

10:14 a.m.

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

6654

Age (days ago)

6682

Last active (days ago)

List overview

Download

11 comments

4 participants

participants (4)

Aurelien Foret
Joao Estevao
Mark Rosenstand
VMiklos