[pacman-dev] [PATCH] FS#68355 go to the end of screen if 'printonly' mode enabled

[Anatol Pomozov]

At the end of download operation our code makes sure the cursor is moved
to the end of the drawing area. But 'printonly' mode has its own if() branch
that skips this cursor alignment. Add cursor_goto_end() to the 'printonly'
codepath to make sure it does not clobber previous output.

Signed-off-by: Anatol Pomozov 
---
 src/pacman/callback.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/pacman/callback.c b/src/pacman/callback.c
index 4240a779..53518101 100644
--- a/src/pacman/callback.c
+++ b/src/pacman/callback.c
@@ -226,6 +226,7 @@ static int number_length(size_t n)
 void cb_event(alpm_event_t *event)
 {
if(config->print) {
+   cursor_goto_end();
return;
}
switch(event->type) {
-- 
2.29.0

Re: [pacman-dev] [PATCH] Support parallel download with xfercommand

[lesto fante]

> So, you are just passing the full list of files to download to a
> download script.  Downloads are not managed by pacman at all?

Exactly, my understanding is that with XferCommand we delegate an
external command to manage the downloads.
The advantage of having a dedicated wait command/parameter for the
last packet to download is that this final command can act as a
collection of information.

The only reason I do not call XferCommand with a list of all the
packages, server, and other options like ParalleDownalods as parameter
is because i fear to hit the parameter limit on some supported
OS/kernel I am not aware of;
but i feel maybe this is the best option, give to the download program
all he has to known.

The idea of having a single command or a dedicate wait
command/parameter imho is very important as this will help to have a
decent output of the external program progress, as it will be managed
by the program itself

> Just add three more lines to your script:
>
> pacman -Sy
> pacman -Sup --noconfirm
> 
> pacman -Su

Yes, this is more or less what my actual script is doing.
I don't think it is the right solution as it became a multistage
process (error prone) or a pacman wrapper (don't like too much as this
is adding only a small modification, and will interfere with all the
other wrappers and possibly command line options) .

> I don't see the point of implementing parallel XferCommand like that
> within pacman at all.

Convenience and integration with other wrappers.

> Pacman currently monitors a single download in a portable way.  I see no
> reason it could not monitor more than one.  Then it could use
> ParallelDownloads and provided some consistency across download methods.

because I am not sure if tracking PID is portable and would require a
deeper modification of `fetchcb`, probably to return a PID handle.
Pacman could track every process alive/dead, but would not know any
other information like internal prograss.
If you think this is the best way, I will implement it.

> It does not...  I'd expect it would after an addition to XferCommand to
> support parallel downloads.

ok, so i can implement the tracking of the PID, but before writing any
more code I want to make sure this solution is acceptable;
and if it is, any implementation suggestion is welcome, if not, what
you think is the solution.

so to recap:

- solution 1 -
XferCommand called multiple times, non blocking, and a final
XferCommand with special parameter/XferLockCommand to wait for output.
We trust XferCommand to start only ParallelDownloads download.

- solution 2 -
We call XferCommand ParallelDownloads times, and wait for process to
complete before calling again

- solution 3 -
XferParallelCommand is added, it will be called with a list of all
packages, servers and options like ParallelDownloads.
We trust XferCommand to start only ParallelDownloads download.

[pacman-dev] [PATCH v2] libmakepkg: compress: fix tar extension

[Michael Straube]

With commit 74aacf44958e1343b910b3fbdcf753393857f070 creating uncompressed .tar
packages fails.

  -> Compressing package...
/usr/share/makepkg/util/compress.sh: line 70: COMPRESS.TAR[@]: invalid variable 
name
bsdtar: Write error

Empty the '$ext' variable for the '.tar' extension in get_compress_command() to
fix this. We would fallback to cat for 'tar' anyways.

Signed-off-by: Michael Straube 
---
v1 -> v2
Added a comment.

 scripts/libmakepkg/util/compress.sh.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/libmakepkg/util/compress.sh.in 
b/scripts/libmakepkg/util/compress.sh.in
index d35a01fa..b88d0c2f 100644
--- a/scripts/libmakepkg/util/compress.sh.in
+++ b/scripts/libmakepkg/util/compress.sh.in
@@ -65,6 +65,10 @@ get_compression_command() {
esac
 
ext=${ext#*.tar.}
+   # empty the variable for tar so we fallback to cat, otherwise we would
+   # have '.tar' and get an error in the next if block
+   ext=${ext#*.tar}
+
if [[ -n $ext ]]; then
extarray="COMPRESS${ext^^}[@]"
resolvecmd=("${!extarray}")
-- 
2.28.0