Vpacman - let me know what you think

fdservices · 2018-02-27 14:07:10

I offer you Vpacman.

A programme to easily view and modify the pacman database.

For my part I prefer a GUI interface to pacman, and I used pacmanxg unitl it stopped being developed. So this is a functionally similar, hopefully much faster, written in tcl tk.

Pacman is always used to install, update, delete and synchronize the pacman packages and database. Therefore the entries in the pacman configuration file will always be respected.

Features
• View available packages
• View installed packages
• View packages not installed
• View packages with updates available
• Install and delete packages
• Synchronize with the Pacman database
• View AUR and local packages
• View AUR packages with updates availabe
• Update and delete AUR packages
• Delete local package
• View detailed information and file lists for packages
• Check installation of packages
• Check for updated configuration files
• Clean Pacman package cache
• Read Arch news
• ... and more

I would very much like to hear both positive and negative criticism, and also suggestions for added functionality.

Enjoy

Andrew

Scimmia · 2018-02-27 14:18:47

First impressions:

Package installs things to /opt/local/. No
No public code repo so I can check it out. No
Screenshots on Sourceforge show the readme recommending to run a GUI program with su or sudo. Hell no.

I didn't get any further than that. Goes on my "do NOT recommend list"

Trilby · 2018-02-27 14:47:54

Scimmia, there is this comment in the code:

# tried gksu as an alternative, but a) it is just a front end to su and sudo and b) it does not play well with complex pacman commands like -Syu
# kdesu is no longer available
# and other gui su commands are not mainstream

I do agree the suggestion/requirement to use sudo or su is bad. If your code does not work with gksu/kdesu you may want to figure out what is wrong with your code (blaming pacman is certainly not correct).

But really, I'm much more concerned about the use of `pacman -Sy`, e.g., on 2722.

This shebang, while harmless, is rather silly:

#! /bin/sh
# the next line restarts using wish \
exec wish "$0" "$@"

That should just be

#!/bin/wish

Or to be safe

#!/bin/env wish

Scimmia · 2018-02-27 14:56:23

My issue isn't su/sudo vs gksu, but the suggestion to run a GUI program as root at all. Bad idea all around.

fdservices · 2018-02-27 16:50:20

Thanks for the feed back

/opt/local was the location for optional local packages install in Unix. I cannot think of any reason why it should not be installed there.

The source is on sourceforge and can be downloaded and unpacked from there if you want to read through it. It si written in tcl tk and heavily commented so you should be able to make it out

I tend to agree about running programmes with root privileges, however, the alternative is to enter the root password frequently. Using gksu, as explained in the code, is simply a front end to su and/or sudo, so no real advantage, and kdesu has been discontinued. You can run vpacman without using su/sudo if you prefer.

The start code may be silly, but it is the recommended way to start a tcl tk programme. I cannot say why.

Pacman -Sy is not destructive, simply updates the database and. since this is a GUI programme, allows you to scan the updated results. It is clearly stated the a Full System Update is the recommended way to update, and that option appears first in all the menus.

Andrew

Scimmia · 2018-02-27 17:03:21

And with that, I think this thread is dead.

ewaller · 2018-02-27 17:05:28

fdservices wrote:

Pacman -Sy is not destructive, simply updates the database and. since this is a GUI programme, allows you to scan the updated results.

*Headdesk*

Edit: Trying to figure out what to do with this thread. Don't want to kill it. Don't really want to move it to TGN.
You did ask for feedback, which is a good learning experience. But doing a pacman -Sy without requiring an update is a poor design. Sorry.

Last edited by ewaller (2018-02-27 17:08:05)

Trilby · 2018-02-27 17:47:35

fdservices wrote:

I tend to agree about running programmes with root privileges, however, the alternative is to enter the root password frequently

Incorrect. See `man sudo` for the '-v' flag

fdservices wrote:

Pacman -Sy is not destructive

In a very strict sense, this may be true. Like it is true that giving a small child a very sharp knife is not destructive. But what happens next very likely will be.

eschwartz · 2018-02-27 19:50:17

fdservices wrote:

Thanks for the feed back
/opt/local was the location for optional local packages install in Unix. I cannot think of any reason why it should not be installed there.

And if you genuinely think this is a Unix operating system according to the Unix filesystem hierarchy, then I'm not even sure how to respond to that. A very basic, core concept of Linux distributions is that /opt is where you shove software that literally cannot work using the /usr/{bin,lib,share} hierarchy, possibly due to it being written with hardcoded relative paths, mot likely because it is some horrible proprietary blob.

I'm going to pretend you didn't say that, for the sake of my sanity.

...

Why not use /usr/share for its intended purpose? Why not make vpacman.tcl the main entry point, rather than doing... whatever that bash script does... and move the icons to where they belong in /usr/share/icons thereby allowing the user to theme it? At least, I assume any reasonable programming language has or can install an interface to the system icon themes.

The source is on sourceforge and can be downloaded and unpacked from there if you want to read through it. It si written in tcl tk and heavily commented so you should be able to make it out

Wait, this is the 21st century, right? Why are people registering new projects on sourceforge???

Their interface is terrible, their new owners "probably" will fix their deserved reputation as being a source of spamware, malware, adware, and broken Windows systems, and may even fix the fact that while sourceforge has always been prone to service outage, they've only gotten worse since the past couple months under new management.

But hey, even though they *offer* version control hosting, you're not using it, so it is difficult to really get an idea of how this code is designed.

It's not like you've never learned how version control systems work, you had to use git in order to upload the package to the AUR...

I tend to agree about running programmes with root privileges, however, the alternative is to enter the root password frequently. Using gksu, as explained in the code, is simply a front end to su and/or sudo, so no real advantage, and kdesu has been discontinued. You can run vpacman without using su/sudo if you prefer.

The fact that you haven't tried to figure out how to correctly use something like polkit, tells me this was hacked together without any proper plan.

The start code may be silly, but it is the recommended way to start a tcl tk programme. I cannot say why.

You don't even know why the programming language you use recommends something, but you use it anyway? Do I want to trust your code if even you don't really understand what it is doing or why?

Pacman -Sy is not destructive, simply updates the database and. since this is a GUI programme, allows you to scan the updated results. It is clearly stated the a Full System Update is the recommended way to update, and that option appears first in all the menus.
Andrew

recommended way only supported way

Last edited by eschwartz (2018-02-27 19:52:45)

Trilby · 2018-02-27 20:01:27

fdservices wrote:

The start code may be silly, but it is the recommended way to start a tcl tk programme. I cannot say why.

I can say why it is recommended. And I can do so because I took 30 seconds to do a web search:
https://www.tcl.tk/man/tcl/UserCmd/wish.htm#M23

wish documentation wrote:

[using a wish shebang] assumes that wish has been installed in the default location in /usr/local/bin; if it is installed somewhere else then you will have to modify the above line to match. Many UNIX systems do not allow the #! line to exceed about 30 characters in length, so be sure that the wish executable can be accessed with a short file name...
[using a shell exec] has three advantages over the approach in the previous paragraph. First, the location of the wish binary does not have to be hard-wired into the script: it can be anywhere in your shell search path. Second, it gets around the 30-character file name limit in the previous approach. Third, this approach will work even if wish is itself a shell script (this is done on some systems in order to handle multiple architectures or operating systems: the wish script selects one of several binaries to run). The three lines cause both sh and wish to process the script, but the exec is only executed by sh. sh processes the script first; it treats the second line as a comment and executes the third line. The exec statement cause the shell to stop processing and instead to start up wish to reprocess the entire script. When wish starts up, it treats all three lines as comments, since the backslash at the end of the second line causes the third line to be treated as part of the comment on the second line.

The first is covered by covered by env. The second is silly - I am very much an reactionary advocate of strong portability where practical, but how about citing a source: which currently available unix has a 30-character file name limit*? The third is just nonsense: a script can itself be the interpreter listed in a shebang line so long as it reads from stdin (which any wish wrapper would).

* 30 character limit was for early versions of research unix at bell labs (before AT&T Unix even). So as long as you don't intend to distribute your vpacman tool via DeLorean to the early 80s, this is not relevant. More importantly, pacman didn't exist until *decades* after this restriction was lifted: so a gui wrapper for pacman that honors this restriction is absolutely absurd.

Last edited by Trilby (2018-02-27 20:05:55)

drcouzelis · 2018-02-28 14:29:05

Thank you for your work on making a GUI for pacman.

It should be easy to make a PKGBUILD file install vpacman in the standard location, in"/usr/bin".

I don't know the best option for the "sudo" issue...

Why do you use "pacman -Sy"? Is it to get a list of available updates? You can consider using the "checkupdates" program that comes with pacman. It is a safe program.

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

eschwartz · 2018-02-28 15:22:53

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.

Most of which are useful but old projects that were never migrated when places like github became a better hosting environment. Their authors, some of whom can no longer be contacted and may not even be alive anymore, cannot be blamed for making what *at the time* seemed to be the correct choice. After all, back then sourceforge did not yet modify downloads in order to add spamware to windows installers, they did not have shady ads, and CVS was considered bleeding-edge version control.

Speaking as a packager I feel somewhat resentful when having to deal with sourceforge.

fdservices · 2018-02-28 16:52:08

@drcouzelis Thanks for the response. As you say the install location can be anywhere suitable, however it is necessary to run the tcl code from a shell script. That is why the shell script is located in /usr/bin and the tcl code is located in /opt. I suppose it could be placed in /usr/share, but does it really matter?

I, too, am not sure about the "sudo" issue. I think it has been assumed that it is necessary to run vpacman with elevated priveleges, which is not the case. Vpacman can be run as a normal user, the only time elevated priveleges are need are to make changes to the system.

It is advised that running pacman -Sy is wrong, since it is normally run from the command line and only updates the databases without running a full system upgrade. While this is not strictly an unsupported partial upgrade, it has no visible effect and is therefore frowned on. Vpacman is a GUI front end to view, and manage, the pacman database. So when the databases are resynced any changes can immediately be viewed and inspected within the programme. In vpacman it is recommended to always do a Full System Upgrade to update the system.

as for hosting in sourceforge....

@ Eschwartz

back then sourceforge did not yet modify downloads in order to add spamware to windows installers, they did not have shady ads

I did not know any of that. Do you recommend github then? Any other candidates?

Andrew

Head_on_a_Stick · 2018-02-28 16:54:50

Disclaimer: I haven't looked at the code.

drcouzelis wrote:

I don't know the best option for the "sudo" issue...

As Eschwartz intimates, polkit is a more "correct" approach, although it's probably still a bad idea.

For example, Arch's thunar package installs /usr/share/polkit-1/actions/org.xfce.thunar.policy which allows it to be run as root. EDIT: with `pkexec`

Last edited by Head_on_a_Stick (2018-02-28 16:55:27)

Alad · 2018-02-28 17:19:28

So when the databases are resynced any changes can immediately be viewed and inspected within the programme. In vpacman it is recommended to always do a Full System Upgrade to update the system.

You're still missing the point that you're leaving the pacman db in an inconsistent state for no reason at all since you can just use "checkupdates" like anyone else.

eschwartz · 2018-02-28 17:27:42

fdservices wrote:

as for hosting in sourceforge....
@ Eschwartz
back then sourceforge did not yet modify downloads in order to add spamware to windows installers, they did not have shady ads
I did not know any of that. Do you recommend github then? Any other candidates?

Github is pretty nice and popular, https://gitlab.com/ is often used by people who prefer an open-source website to host their open-source data. https://bitbucket.org is another alternative that offers both git and mercurial hosting. All offer forking and pull request models, as well as lightweight "Issues".

https://savannah.nongnu.org/ is run by the FSF / gnu.org to provide hosting even for non GNU projects -- they offer most version control systems as well as mailing lists and a bugtracker.

https://launchpad.net/ is operated by Ubuntu and provides git and bazaar hosting, as well as a bugtracker.

Head_on_a_Stick wrote:

Disclaimer: I haven't looked at the code.
drcouzelis wrote:
I don't know the best option for the "sudo" issue...
As Eschwartz intimates, polkit is a more "correct" approach, although it's probably still a bad idea.
For example, Arch's thunar package installs /usr/share/polkit-1/actions/org.xfce.thunar.policy which allows it to be run as root. EDIT: with `pkexec`

Why do you suggest it would be a bad idea?

Last edited by eschwartz (2018-02-28 17:28:54)

drcouzelis · 2018-02-28 17:35:14

fdservices wrote:

As you say the install location can be anywhere suitable, however it is necessary to run the tcl code from a shell script. That is why the shell script is located in /usr/bin and the tcl code is located in /opt. I suppose it could be placed in /usr/share, but does it really matter?

I don't know... It seemed natural to me that you would organize your package like this:

/usr/bin/vpacman
/usr/share/vpacman/vpacman.tcl
/usr/share/applications/vpacman.desktop
/usr/share/pixmap/vpacman.png

...but I don't have a justification for why. The Filesystem Hierarchy Standard has some information, but there are many exceptions nowadays.

In my mind, the general rule is "If pacman does the install, put it in '/usr'. If the program uses its own installer, put it in '/opt'."

fdservice wrote:

Do you recommend github then? Any other candidates?

GitHub is nice. A few years ago I transferred all of my projects from Sourcforge to GitHub. It's hard for me to explain why it's better... Here's one example: On GitHub, I can click a button to delete one of my projects. It's so easy! But on Sourcforge, I need to submit a ticket to Sourceforge asking a Sourceforge administrator to delete one of my projects.

eschwartz · 2018-02-28 17:42:30

drcouzelis, this assumes that sourceforge is not having a service outage at that time and is therefore completely inaccessible.

Oh, speaking of which I notice that *.sourceforge.net domains are finally, after a very long time, no longer hanging when you try to visit them...

...

As for the Filesystem Hierarchy Standard, "/opt is reserved for the installation of add-on application software packages."

Well, surely all applications are "add-on application software packages" not required by the OS itself. But only https://www.gobolinux.org/ actually does that sort of separation...

The FHS is confusing and unclear, like most specs written from a legalese perspective.

But, consider

The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software.

Last edited by eschwartz (2018-02-28 17:48:49)

Scimmia · 2018-02-28 17:46:05

drcouzelis wrote:

In my mind, the general rule is "If pacman does the install, put it in '/usr'. If the program uses its own installer, put it in '/opt'."

No, if it has it's own installer, it puts it in /usr/local/. Check what Eli said, things go to /opt when they simply don't fit into a *nix system.

fdservices wrote:

I, too, am not sure about the "sudo" issue. I think it has been assumed that it is necessary to run vpacman with elevated priveleges, which is not the case. Vpacman can be run as a normal user, the only time elevated priveleges are need are to make changes to the system.

Nobody is assuming that you have to run the GUI as root. The fact that you're suggesting it in the help file, along with your insistence in using pacman -Sy and your inexplicable use of /opt, shows that you don't understand how pacman works, how Arch works, or how X works. This is the major concern here, you're writing an AUR helper and pacman frontend without understanding how they should actually be used and managed

Last edited by Scimmia (2018-02-28 17:47:20)

Head_on_a_Stick · 2018-02-28 18:36:45

Eschwartz wrote:

Why do you suggest it would be a bad idea?

Running GUIs as root is bad, m'kay?

Anyway, Scimmia seems to agree, do you not?

eschwartz · 2018-02-28 18:47:13

Well, um, that's the whole point of polkit, you can run a GUI as not-root and request root permissions for specific things?

I mean, how else do you implement a GUI that can be run without root to inspect the installed package list, but requires root permissions in the specific case of selecting to perform a transaction?

Let's turn this around: what do *you* think polkit is?

Head_on_a_Stick · 2018-02-28 18:51:48

I know what it is, I just don't trust it enough, which may be part of the reason why pcmanfm & spacefm don't also ship polkit exception files.

I cannot think of a single reason to run a GUI as root, the practice should be thoroughly dicouraged as a matter of principle, IMO.

eschwartz · 2018-02-28 18:55:13

Let's try this again: polkit does not mean running the GUI as root.

Head_on_a_Stick · 2018-02-28 18:56:08

^ Yes, OK, whatever.

Sorry for the diversion OP

fdservices · 2018-02-28 19:54:04

@ Alad

You're still missing the point that you're leaving the pacman db in an inconsistent state

Please can you explain this comment further? Why does the command exist if it leaves the db in an inconsistent state? In what way is the db inconsistent?

Andrew

Arch Linux

#1 2018-02-27 14:07:10

Vpacman - let me know what you think

#2 2018-02-27 14:18:47

Re: Vpacman - let me know what you think

#3 2018-02-27 14:47:54

Re: Vpacman - let me know what you think

#4 2018-02-27 14:56:23

Re: Vpacman - let me know what you think

#5 2018-02-27 16:50:20

Re: Vpacman - let me know what you think

#6 2018-02-27 17:03:21

Re: Vpacman - let me know what you think

#7 2018-02-27 17:05:28

Re: Vpacman - let me know what you think

#8 2018-02-27 17:47:35

Re: Vpacman - let me know what you think

#9 2018-02-27 19:50:17

Re: Vpacman - let me know what you think

#10 2018-02-27 20:01:27

Re: Vpacman - let me know what you think

#11 2018-02-28 14:29:05

Re: Vpacman - let me know what you think

#12 2018-02-28 15:22:53

Re: Vpacman - let me know what you think

#13 2018-02-28 16:52:08

Re: Vpacman - let me know what you think

#14 2018-02-28 16:54:50

Re: Vpacman - let me know what you think

#15 2018-02-28 17:19:28

Re: Vpacman - let me know what you think

#16 2018-02-28 17:27:42

Re: Vpacman - let me know what you think

#17 2018-02-28 17:35:14

Re: Vpacman - let me know what you think

#18 2018-02-28 17:42:30

Re: Vpacman - let me know what you think

#19 2018-02-28 17:46:05

Re: Vpacman - let me know what you think

#20 2018-02-28 18:36:45

Re: Vpacman - let me know what you think

#21 2018-02-28 18:47:13

Re: Vpacman - let me know what you think

#22 2018-02-28 18:51:48

Re: Vpacman - let me know what you think

#23 2018-02-28 18:55:13

Re: Vpacman - let me know what you think

#24 2018-02-28 18:56:08

Re: Vpacman - let me know what you think

#25 2018-02-28 19:54:04

Re: Vpacman - let me know what you think

Board footer