Does a GUI package manager exist?

User7

Active Member

Reaction score: 7
Messages: 123

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?
 

gofer_touch

Well-Known Member

Reaction score: 127
Messages: 253

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?
 

kpa

Beastie's Twin

Reaction score: 1,810
Messages: 6,318

I know, but I don't (and I'm not going) use PC-BSD.
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.
 

tobik@

Daemon
Developer

Reaction score: 1,382
Messages: 1,909

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.
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.
 

kpa

Beastie's Twin

Reaction score: 1,810
Messages: 6,318

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.
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.
 

Beastie7

Well-Known Member

Reaction score: 170
Messages: 414

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.
 

NewGuy

Well-Known Member

Reaction score: 73
Messages: 301

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.
 

Beastie7

Well-Known Member

Reaction score: 170
Messages: 414

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.
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.
 

protocelt

Daemon

Reaction score: 410
Messages: 1,253

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.
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?
 

Beastie7

Well-Known Member

Reaction score: 170
Messages: 414

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?
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
 

kpa

Beastie's Twin

Reaction score: 1,810
Messages: 6,318

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
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.
 

standard_nerd68k

New Member

Reaction score: 1
Messages: 7

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.
 

ANOKNUSA

Aspiring Daemon

Reaction score: 372
Messages: 675

All true, but this does not preclude us from having a GUI frontend for pkg as a port.
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.
 

Alexandre A Arnt

New Member

Reaction score: 6
Messages: 1

NewGuy

Well-Known Member

Reaction score: 73
Messages: 301

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:

ronaldlees

Aspiring Daemon

Reaction score: 321
Messages: 756

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 ...
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

Beastie's Twin

Reaction score: 1,810
Messages: 6,318

Also note that there is now an ncurses frontend for pkg(8) in development: https://github.com/culot/portal
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.
 

Oko

Daemon

Reaction score: 772
Messages: 1,620

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.
Maybe you guys should look at this code which is nothing more than an exercise in using SQLite database

https://rhaalovely.net/pkg_mgr/
 
Top