Vpacman - let me know what you think

Alad · 2018-02-28 20:08:12

https://wiki.archlinux.org/index.php/Sy … nsupported

Concrete examples include when major libraries like openssl or readline are upgraded. For example, if you did pacman -Sy on openssl 1.0, for the purpose of subsequent package installations (-S) you're using openssl 1.1 even if you're not. So if you did pacman -S pacman, pacman would immediately stop working as openssl 1.1 is not available on disk, requiring manual recovery. These are things you often see happening on the forums.

While Arch Linux does not support partial upgrades, pacman may be used by other projects that do support it (in particular projects that include more version information in their dependencies than Arch does) so the flag remains valid. For Arch usage, you can use checkupdates which does an -Sy on a temporary database in a temporary directory using fakeroot. The other TCL pacman GUI (tkpacman) has similar behaviour to display updates.

Last edited by Alad (2018-02-28 20:09:11)

fdservices · 2018-02-28 20:53:13

Thank you for the prompt reply

I think I understand

Can you explain what checkupdates actually does? Does it give a list of programes in need of updating as the name suggests or does it give a full list of changes to the downloaded database?

pacman -Syu performs a database update/sync and then performs the upgrades. If you answer No to the upgrades does that also leave the database in an inconsistent state?

Andrew

Trilby · 2018-02-28 21:07:16

fdservices wrote:

Can you explain what checkupdates actually does? Does it give a list of programes in need of updating as the name suggests or does it give a full list of changes to the downloaded database?

Neither ... Both. It will directly provide a list of packages with updates available. It also provides a new set of databases with the changes (not a list of changes).

fdservices wrote:

If you answer No to the upgrades does that also leave the database in an inconsistent state?

Yes

eschwartz · 2018-02-28 23:03:20

It is perhaps particularly worth noting that while Arch Linux does not support partial upgrades and tools which do so by default are things we don't like, a tool that only performs partial upgrades if you use non-default options or send SIGINT after syncing the databases, that is on the user to *recover* from, but that isn't a tool which does partial updates.

As for checkupdates, it's just a bash wrapper script to run pacman -Sy and pacman -Qu while using a --dbpath pointed at a copy of the database which was cp'ed from /var/lib/pacman to /tmp

So more generally, any tool can use a copy of the database there and do upgrade checks however they like.

(You will have to use fakeroot in order to do the sync.)

fdservices · 2018-03-01 10:26:16

I understand the dangers of partial upgrades, and why they are not supported. What I have not yet understood is why it is important to keep the contents of the sync database unchanged since the last system upgrade. There must be a very good reason, otherwise checkupdates would not be needed.

Allan · 2018-03-01 10:55:11

Say you change your database with -Sy, then install a package foo which has been updated since your last system update. The foo package might need a new version of openssl and pulls that update in. Now pacman is broken, ssh is broken, ... in fact your system is screwed. If you had not done the -Sy first, you would just get an error downloading the foo package, done a -Syu to get fully up to date then installed it.

fdservices · 2018-03-01 11:16:24

Right - got it. I will rewrite vpacman to use a copy of the database.

Thank you, everyone, for your patience.

Trilby · 2018-03-01 12:32:17

Thanks for contibuting and accepting critique.

I'd encourage you to consider also how consistency and correctness even in little details does impact many hackers' overall impression of a bit of code. Sometimes the important bits aren't as obvious, but I - at least, and I suspect many others - am worried when we see what might look a bit sloppy in the less important but obvious parts of a bit of software. If you don't have a rigorous approach to consistency and correctness in the simple things, should we trust your code with important things.

A concrete example: I've looked it over several times, and I haven't the foggiest idea why you need that shell script that launches the tcl script (especially since the tcl script is really a shell script with tickle code embeded). It looks like all the shell script does is check whether a parameter with 'h' in it was passed. The shell script just prints the help and exits unless debug was also passed then it prints the help and continues. Certainly you can do this in tcl code.

But more on point of consistency and correctness, your little shell script is really disorganized and flip-flops between using '[' and '[[' for no apparent reason. Further, checking parameters by just checking for whether there is an 'h' or a 'd' anywhere in them is messy, there are any number of things other than -h --help -d --debug that could be passed that would trigger behavior that would be surprising to the user. Why not just check for -h --help -d and --debug, that's trivial in a case statement, or just use getopt(s). (Or much better yet, just do it in tcl).

I suspect the harshness of some of the previous critiques may have been influenced by the perception of sloppiness. If you write a sloppy haphazzard script, we can just provide feedback on it. If you write a sloppy haphazzard script that starts messing with the pacman databases which could do significant damage to the systems of anyone who uses vpacman, then we get a bit more picky.

Last edited by Trilby (2018-03-01 12:35:33)

fdservices · 2018-03-01 14:52:29

I start from the assumption that -d or --debug and -h or --help are pretty much universally used for debug and help arguments

Unfortunately tk grabs -d and -h, or any cntractions of them, from any arguments passed before the application can use them, so I needed another method of invoking them.

The [[ ]] is a bash enhancement to test, which allows for globbing.

So the script first checks for a d or an h in the arguments passed to it, then if d is found it set the variable string, to pass on, to "debug" which is allowed. If h is found it prints a help message. If help is called on its own it will then exit. If both variables exist then it prints the help message and asks whether or not to run the programme (in debug mode). If the answer is to do so, then it runs vpacman with debug as the variable. This section of the code uses simple [ ] tests.

You are correct in that if the user enters "vpacman howdy" then the script will print help and offer to run vpacman - in debug mode - but that may not be a bad thing!

One final point, if you use your suggested case statement it would actually miss the -dh or -hd options. Getops would handle these, but not --debug or --help I think.

Andrew

eschwartz · 2018-03-01 15:02:32

GNU getopt supports short and long options...

But there's an even better solution if you are already insisting on using bash to parse options. pacman comes with makepkg, and makepkg supplies /usr/share/makepkg/util/parseopts.sh for "exploding" short options like -dh into -d -h.

It is perfectly legitimate for a tool which depends on pacman, to also depend on makepkg's library functions.

Trilby · 2018-03-02 14:18:33

drcouzelis wrote:

...as for hosting it on Sourceforge, it's not a problem. Many, many, many packages used in Arch Linux are hosted on Sourceforge.

Yes, and it is a recurring PITA.

Last edited by Trilby (2018-03-02 14:19:11)

Arch Linux

#26 2018-02-28 20:08:12

Re: Vpacman - let me know what you think

#27 2018-02-28 20:53:13

Re: Vpacman - let me know what you think

#28 2018-02-28 21:07:16

Re: Vpacman - let me know what you think

#29 2018-02-28 23:03:20

Re: Vpacman - let me know what you think

#30 2018-03-01 10:26:16

Re: Vpacman - let me know what you think

#31 2018-03-01 10:55:11

Re: Vpacman - let me know what you think

#32 2018-03-01 11:16:24

Re: Vpacman - let me know what you think

#33 2018-03-01 12:32:17

Re: Vpacman - let me know what you think

#34 2018-03-01 14:52:29

Re: Vpacman - let me know what you think

#35 2018-03-01 15:02:32

Re: Vpacman - let me know what you think

#36 2018-03-02 14:18:33

Re: Vpacman - let me know what you think

Board footer