Re: [pacman-dev] [PATCH v2] Swap alpm_db_update() implementation to multiplexed version

2020-05-11 Thread Allan McRae
On 12/5/20 12:27 am, guilla...@manjaro.org wrote: > Hi Allan, Hi Anatol, > > I was looking to this new multiplexed implementation and I found some > problems: > 1) This implementation can lead to download databases from different > servers, I think it can't be a problem if they are not synced As

Re: [pacman-dev] [PATCH v2] Swap alpm_db_update() implementation to multiplexed version

2020-05-11 Thread Allan McRae
On 12/5/20 3:14 am, guilla...@manjaro.org wrote: > Le 2020-05-11 17:10, Eli Schwartz a écrit : >> On 5/11/20 10:27 AM, guilla...@manjaro.org wrote: >>> Hi Allan, Hi Anatol, >>> >>> I was looking to this new multiplexed implementation and I found some >>> problems: >>> 1) This implementation can

Re: [pacman-dev] [PATCH v2] Swap alpm_db_update() implementation to multiplexed version

2020-05-11 Thread Anatol Pomozov
Hello Guillaume On Mon, May 11, 2020 at 7:51 AM wrote: > > Hi Allan, Hi Anatol, > > I was looking to this new multiplexed implementation and I found some > problems: > 1) This implementation can lead to download databases from different > servers, I think it can't be a problem if they are not

[pacman-dev] [PATCH] Cleanup the old sequential download code

2020-05-11 Thread Anatol Pomozov
All users of _alpm_download() have been refactored to the new API. It is time to remove the old _alpm_download() functionality now. This change also removes obsolete SIGPIPE signal handler functionality (this is a leftover from libfetch days). Signed-off-by: Anatol Pomozov ---

Re: [pacman-dev] [PATCH v2] Swap alpm_db_update() implementation to multiplexed version

2020-05-11 Thread Eli Schwartz
On 5/11/20 10:27 AM, guilla...@manjaro.org wrote: > Hi Allan, Hi Anatol, > > I was looking to this new multiplexed implementation and I found some > problems: > 1) This implementation can lead to download databases from different > servers, I think it can't be a problem if they are not synced

Re: [pacman-dev] [PATCH v2] Swap alpm_db_update() implementation to multiplexed version

2020-05-11 Thread guillaume
Hi Allan, Hi Anatol, I was looking to this new multiplexed implementation and I found some problems: 1) This implementation can lead to download databases from different servers, I think it can't be a problem if they are not synced 2) Differents download payloads are created for databases and

Re: [pacman-dev] [PATCH] Use absolute path for pacman and pacman-conf in makepkg

2020-05-11 Thread Eli Schwartz
On 5/11/20 9:01 AM, wwijs...@live.nl wrote: > Right now an unpatched pacman almost works for my use case, but there > still is one issue with building it. Currently ninja will install the > bash-completion scripts system wide, regardless of which user runs > ninja install or what the prefix is.

Re: [pacman-dev] [PATCH] Use absolute path for pacman and pacman-conf in makepkg

2020-05-11 Thread wwijsman
On Mon, 2020-05-11 at 12:42 +1000, Allan McRae wrote: > On 8/5/20 4:13 am, Wouter Wijsman wrote: > > Currently makepkg requires pacman and pacman-conf to be in the path > > of > > the user. Since these executables should never move, it should be > > safe > > to add the full paths to the scripts at

[pacman-dev] [PATCH] Convert '-U pkg1 pkg2' codepath to parallel download

2020-05-11 Thread Anatol Pomozov
Installing remote packages using its URL is an interesting case for ALPM API. Unlike package sync ('pacman -S pkg1 pkg2') '-U' does not deal with server mirror list. Thus _alpm_multi_download() should be able to handle file download for payloads that either have 'fileurl' field or pair of fields