Does a GUI package manager exist?

U

User7

I search any GUI package manager. I want have all installed package on the one place, where I can easy remove or add package. Does something like that exist?
 
If I am not mistaken GhostBSD has/had one. I don't know if they switched to the commandline with GhostBSD version 4.0.

The commandline package manager on FreeBSD works exceedingly well IMO. It is very powerful. Is there some reason why you would prefer not to use it?
 
User7 said:
I know, but I don't (and I'm not going) use PC-BSD.
Click to expand...

If you really have a need for a GUI package manager you should look into other variants of FreeBSD such as PC-BSD, basic FreeBSD doesn't quite cater well to people who want graphical "easy" solutions. FreeBSD is a DiY system for enthusiasts and professionals who like to tinker with the OS and make it do what they want.
 
kpa said:
If you really have a need for a GUI package manager you should look into other variants of FreeBSD such as PC-BSD, basic FreeBSD doesn't quite cater well to people who want graphical "easy" solutions. FreeBSD is a DiY system for enthusiasts and professionals who like to tinker with the OS and make it do what they want.
Click to expand...
All true, but this does not preclude us from having a GUI frontend for pkg as a port. After a quick glance at libpkg's API (which looks pretty sweet) there is even less reason for not having such a frontend.

Personally I'd really like to have a curses-based frontend.
 
tobik said:
All true, but this does not preclude us from having a GUI frontend for pkg as a port. After a quick glance at libpkg's API (which looks pretty sweet) there is even less reason for not having such a frontend.

Personally I'd really like to have a curses-based frontend.
Click to expand...

Yes of course. It just happens that the expertise and the willingness to create such tools tends to gravitate away from FreeBSD towards the more desktop oriented FreeBSD offshoots. Ideally we should be able to use the PC-BSD offerings directly on basic FreeBSD but it hasn't been that simple so far.
 
There are some cases where the CLI is kind of limited for administration. Like sysctl values and kernel modules. Often times you want to plan your infrastructure for a client and just quickly deploy it. Sorting through the hundreds of values and modules FreeBSD has is kind of pain where nCurses could be very useful, like selecting multiples and tuning in a concurrent fashion.

I wouldn't mind an ncurses front-end to package/ports either. There was a guy on the mailing lists (forgot which one) experimenting with para-ports (parallel installs of ports) for FreeBSD. That with ncurses would be extremely useful for many cases.

I see ncurses as a non-GUI compromise for us CLI guys.
 
Use can use AppCafe from FreeBSD. Just set up FreeBSD as you usually would, then install the PC-BSD desktop utilities from ports. You'll get a GUI package manager while maintiaining your FreeBSD base.
 
NewGuy said:
Use can use AppCafe from FreeBSD. Just set up FreeBSD as you usually would, then install the PC-BSD desktop utilities from ports. You'll get a GUI package manager while maintiaining your FreeBSD base.
Click to expand...

The problem with that is that you have to switch the underlying repositories over and install the PBI wrapper for AppCafe. As kpa mentioned, it isn't simple. There's yet to exist a generic GUI front-end for just plain vanilla pkgng, kind of like synaptic.
 
Beastie7 said:
I wouldn't mind an ncurses front-end to package/ports either. There was a guy on the mailing lists (forgot which one) experimenting with para-ports (parallel installs of ports) for FreeBSD. That with ncurses would be extremely useful for many cases.
Click to expand...
ports-mgmt/poudriere already does this, although, of course without a curses frontend.

Edit: Oops, now that I look at that again, I realize it said parallel installs, not parallel builds. Parallel installs would indeed be neat. Is that even really possible?
 
protocelt said:
ports-mgmt/poudriere already does this, although, of course without a curses frontend.

Edit: Oops, now that I look at that again, I realize it said parallel installs, not parallel builds. Parallel installs would indeed be neat. Is that even really possible?
Click to expand...

Here we go.

https://lists.freebsd.org/pipermail/freebsd-hackers/2015-April/047563.html

Apparently is it possible. He even has a pretty cool working demo of his project:

http://www.starforce.biz/paraports.mp4
 
Beastie7 said:
Here we go.

https://lists.freebsd.org/pipermail/freebsd-hackers/2015-April/047563.html

Apparently is it possible. He even has a pretty cool working demo of his project:

http://www.starforce.biz/paraports.mp4
Click to expand...

The video didn't work for me (or would have taken ages to load) so I may have missed something but here we go. It looks like he is trying to solve the same problem as ports-mgmt/poudriere + ports-mgmt/pkg in pkg-upgrade(8) mode but coming from a different angle. With poudriere the dependencies are solved at build time resulting in dependency graph and a build order that guarantees the correct order and rebuilding of everything that needs rebuilding. The result of the builds is a set of packages that can be then used with pkg-upgrade(8). What he is doing apparently is parallelization of make install processes for multiple ports and guaranteeing the same dependency order but not using the builds to create a set of packages, he is just letting the ports system do its thing with make install for every individual port.

I have to say it's interesting approach but we already have a better solution that exploits the opportunities for parallelization as much as it's possible with the current ports tree and its limitations. Parallel installs sounds like a neat idea but quite frankly what pkg-upgrade(8) offers with its dependency solver is much more powerful and robust solution.

Also, what this paraports system would have to do as well is building ports in a clean environment to be considered useful.
 
I'm talking about Debian, not BSD, but I find GUI and CLI both have places. If I want a program to do some random task, but don't know what is available, it is easier to search in a GUI. If I know exactly what program I want, CLI is quicker.
 
tobik said:
All true, but this does not preclude us from having a GUI frontend for pkg as a port.
Click to expand...

Speaking strictly from my years of experience with Arch Linux: the "Where's the graphical interface?" conversation rarely gets beyond "it's possible," because there's a significant gulf between those who want one and those who could make one. The people who want a graphical package manager lack the skill to make one and the desire to learn; the people with the skill to make one don't want to spend their time and energy on it when good tools already exist. The few people in the middle willing to actually create a graphical front-end to the package manager have invariably abandoned their projects.
 
Has anyone submitted OctoPkg as a port yet? I think this would be quite useful to many FreeBSD desktop users.

Update: I'm in the process of working on a port for OctoPkg. At the moment it builds and installs, but does not de-install cleanly. Would love to get some people to test this port and make suggestions on how to improve it.

http://torrent.resonatingmedia.com/octopkg.txt

Second update: This port has been cleaned up and submitted to the Ports team for review and hopefuly inclusion. You can track its progress or test the port here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201358
 
Last edited:
Have tried octopkg, and like it! A few observations:

1 - Depends on Qt5 - a whopper that might not appeal to CLI crowd.
2 - Out of the box, responds with:
There are no means to get administrator's credentials.
You'll need to install gksu or ...
Click to expand...

3 - Installing gksu brings in Nautilus and Gtk3 (ouch)

But! Once I did all that it looks to work pretty well. I installed some stuff, and the GUI seems to do what you'd think it should do in terms of a point and click style installer, upgrader, etc. It's all nicely formatted as well, and is color syntax coordinated. Flashy! It's new, so I would want to test it quite a bit more than I have before turning it loose ...

But, won't do the testing because I am probably still looking for that ncurses front end for myself ...
 
Last edited:
kpa said:
I hope it gets further than that. At minimum a GUI package manager (be it ncurses or full X11 GUI) should offer a changeset based display of which packages are to be updated, installed or removed compared to the present state of installed packages.
Click to expand...
Maybe you guys should look at this code which is nothing more than an exercise in using SQLite database

https://rhaalovely.net/pkg_mgr/
 
You must log in or register to reply here.
Back
Top