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