LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   GUI frontend to slackpkg ? (https://www.linuxquestions.org/questions/slackware-14/gui-frontend-to-slackpkg-4175467679/)

kikinovak 06-28-2013 01:10 AM

GUI frontend to slackpkg ?
 
Hello everybody,

I wonder if there's some sort of Synaptic-like graphical frontend to slackpkg. You may wonder what on earth got into me for asking this. Here goes.

More often than not, my clients have the odd exotic requirement. They all use my beefed-up MLED desktop, which is a one-size-fits-all desktop filling most requirements. But it rarely stops here. One client needs an application to revise movie scripts, another needs to access his iPod, another one wants to read his ebooks or have some basic touch-typing training. Or use AMule. Etc.

Now thanks to the slackpkg+ plugin I can setup my own MLED repository, integrate new apps nicely into the repo for 32-bit and 64-bit machines, and then fetch them via slackpkg.

http://www.microlinux.fr/slackware/M...0-32bit/extra/

A simple 'slackpkg search microlinux' shows me the "status" of the client's desktop, e. g. which apps are installed, which are not installed, which can be updated, etc.

Now a graphical frontend to all this would be nice, because this would allow some of my clients to perform a few basic tasks like upgrading or installing the odd extra application by themselves.

I doubt that such an application exists. But hey, I'll just ask anyway.

Didier Spaier 06-28-2013 01:40 AM

Hello Nicolas,

I don't know of any but it shouldn't be difficult to write one yourself, with either 'dialog' (heavily used by Slackware's installer and many Slackware tools and also BTW by slint's toolbox) or 'Xdialog', which is a GTK+ application, intended to be a drop-in replacement of 'dialog' and for which a SlackBuild is available @ slackbuilds.org.

Lenard Spencer 06-28-2013 04:11 PM

The problem I see with a Slackpkg GUI is if any of the X packages need updated (kde/, xfce, x/, xap/ among possibly others), X cannot be running.

volkerdi 06-28-2013 04:22 PM

Quote:

Originally Posted by Lenard Spencer (Post 4980449)
The problem I see with a Slackpkg GUI is if any of the X packages need updated (kde/, xfce, x/, xap/ among possibly others), X cannot be running.

X can be running while X packages are upgraded. Any shared libraries that are in use but get removed will remain mapped in memory until nothing is using them any longer.

That said, I don't see how a GUI would improve slackpkg much.

Didier Spaier 06-28-2013 04:25 PM

Quote:

Originally Posted by Lenard Spencer (Post 4980449)
The problem I see with a Slackpkg GUI is if any of the X packages need updated (kde/, xfce, x/, xap/ among possibly others), X cannot be running.

Are you sure? let's say xorg-server is updated, for instance: the new version won't be used till next (re)start of the server, so I don't see a problem here. Same for DEs and applications. More generally, a new version of a software is not used as soon as installed. And even if removed from the hard disk I think that the old version will continue to work, as long as it stays in RAM. Of course there can be exceptions.

EDIT Pat was faster. Slow typer I was, slow typer I stay :(

vdemuth 06-29-2013 02:11 AM

Quote:

Originally Posted by volkerdi (Post 4980454)
I don't see how a GUI would improve slackpkg much.

Not for most users that's for certain, but the new generation of 'pointy, clicky, touchy' users might not get the advantage of the cli. Might hurt their pinkys having to do all that typing. :D

glorsplitz 06-29-2013 12:41 PM

'pointy, clicky, touchy' from sysadmin side that is not slackware

kikinovak 06-29-2013 01:09 PM

Quote:

Originally Posted by volkerdi (Post 4980454)
That said, I don't see how a GUI would improve slackpkg much.

Me, I'll always prefer the command-line. But let's say a client who lives 40 miles from here - and whose machine I can't access remotely - wants a certain app not included in Slackware. I'll just try to integrate it nicely, add it to my repo... and then tell the client to just perform a few clicks. That's the general idea.

T3slider 06-29-2013 02:43 PM

Check out QTGZManager (there is a SlackBuild at slackbuilds.org). It is an interface to pkgtools (installpkg/upgradepkg/removepkg) and not slackpkg, but it does support patch updates from a Slackware mirror. I haven't tried it but it looks very nice. Of course, it requires Qt (but not KDE?), but I see your MLED tagfiles include Qt so it may work out of the box. As far as I know, it does not support additional repositories, so it wouldn't be a total solution. A script using Xdialog to call slackpkg may be your best bet if you can't find anything else (though Xdialog is obviously fairly limited in looks and functionality).

vdemuth 06-30-2013 12:13 AM

Quote:

Originally Posted by glorsplitz (Post 4980830)
'pointy, clicky, touchy' from sysadmin side that is not slackware


Not everyone wants to be a sysadmin. Some people like to actually do real work:twocents:

bartgymnast 06-30-2013 03:31 AM

eugene is working with packagekit dev to integrate slackpkg with packagekit.
this might be intresting to following.

Lenard Spencer 07-03-2013 02:06 PM

Quote:

Originally Posted by volkerdi (Post 4980454)
X can be running while X packages are upgraded. Any shared libraries that are in use but get removed will remain mapped in memory until nothing is using them any longer.

That said, I don't see how a GUI would improve slackpkg much.

Thanks for the clarification. As you, I don't see a benefit of a GUI, either. I don't know about others, but I'm MUCH more comfortable running it from the command line.

zerouno 07-03-2013 02:52 PM

A small patch to use kdialog instead dialog.

Code:

--- dialog-functions.sh.tmp 2010-05-02 01:10:33.000000000 +0200
+++ dialog-functions.sh        2013-07-02 09:15:31.418427035 +0200
@@ -47,13 +47,14 @@
                        awk '{ NF=3 ; print $0 }' $TMPDIR/dialog2.tmp > $TMPDIR/dialog.tmp
                        HINT=""
                fi
-              cat $TMPDIR/dialog.tmp|xargs dialog --title $2 --backtitle "slackpkg $VERSION" $HINT --checklist "Choose packages to $2:" 19 70 13 2>$TMPDIR/dialog.out
+              cat $TMPDIR/dialog.tmp|awk '{print $1,$1,$3}'|xargs kdialog --title $2 --checklist "Choose packages to $2:" >$TMPDIR/dialog.out
+              #cat $TMPDIR/dialog.tmp|xargs dialog --title $2 --backtitle "slackpkg $VERSION" $HINT --checklist "Choose packages to $2:" 19 70 13 2>$TMPDIR/dialog.out
                case "$?" in
                        0|123)
-                              dialog --clear
+                              #dialog --clear
                        ;;
                        1|124|125|126|127)
-                              dialog --clear
+                              #dialog --clear
                                echo -e "DIALOG ERROR:\n-------------" >> $TMPDIR/error.log
                                cat $TMPDIR/dialog.out >> $TMPDIR/error.log
                                echo -e "-------------

(apply it to /usr/libexec/slackpkg/functions.d)


Is not a real "GUI", but you will have a "window" :)

Didier Spaier 07-03-2013 02:58 PM

Isn't this patch a bit awkish? Nevermind, I like awk too :-)

rkfb 07-03-2013 03:26 PM

I could certainly see a use for a GUI front end. I installed Slackware as a dual-boot on my sister-in-law's computer after Windows fell over again and again. They now use Slackware almost all the time but with me being 250 miles away sysadmin is tricky. So far I have to dropboxed packages to her that become required after building them here and providing detailed installation instructions via email (for instance Google Chrome was needed when the kids discovered that Club Penguin had added a new section not supported by or working in Firefox).

A slackpkg GUI would undoubtedly make the process a whole lot easier for them, especially if I could add the Dropbox folder as a repository. She could also do a quick updates check herself once a week too.

I know a GUI isn't the slackware way and I'm certainly not advocating a road to ubuntuisation. Just the odd GUI in the right area may help some users.

- thinking about it, wasn't someone building somethinglike this a couple of years ago? I'm sure I remember reading a thread in here where some sort of GUI package manager was being developed.

kimdino 01-14-2015 04:43 PM

Hi folks,
I realise that this is an old thread, and that the OP has probably not looking anymore, but I have been trying and google still makes finding such difficult. Hence I am posting here as this post was easy to find.

I found it good by sidestepping the problem and forgetting 'slackpkg' for 'slapt-get'. This package manager can be used from a GUI fron end called 'GSlapt'.


'slapt-get' can be downloaded from http://software.jaos.org/ Just click on the link to the version you want to download it. Then change to the directory it was downloaded to.

As root or su:-
bash# installpkg slapt-get-[version].tgz ;To install 'slapt-get'
bash# slapt-get -u ;To update the package list.
bash# slapt-get -i gslapt ;To install the GUI.

You will then find 'GSlapt' in you desktops System menu.

I hope this will save many from running away from a lovely distro because they are don't like CLIs. Slackware is a lovely, simple & very robust distro that has managed to remain lightweight even while running a very powerful Desktop. It is unfortunately fading into the background and we mustn't let super-geeks scare us away from it, there is no need. I can use a CLI but have come into the 21st century and realise that GUI tools allow all the functionality most users need but are much easier to get to grips with. A distro doesn't need to be bloated and flimsy to be easy to use.

qweasd 01-14-2015 05:05 PM

Quote:

Originally Posted by kikinovak (Post 4980842)
Me, I'll always prefer the command-line. But let's say a client who lives 40 miles from here - and whose machine I can't access remotely - wants a certain app not included in Slackware. I'll just try to integrate it nicely, add it to my repo... and then tell the client to just perform a few clicks. That's the general idea.

I am not saying you don't have a point, not at all; to each user his or her own. But you could also have them copy-and-paste something into the root prompt. Besides starting an elevated X terminal, that's double-click to copy, single click to paste, and enter, 4 clicks total. If you make sure your bash line does not ask for any input, many users may actually find it better than screwing around with yet another system management tool, GUI or not. Even if it's more involved, you will find it much easier to give step-by-step instructions, no screenshots required.

And just for the sake of being technically correct, konsole is as GUI as it gets. ;)

Edit: more info, formatting.

ReaperX7 01-14-2015 05:09 PM

We used to have a GUI front end that used pkgtools as a backend with KDE-3.x, but that utility has since been discontinued in support of pkgtools. Gslapt is your best bet honestly, but Gslapt works best if you have a depedency listing added into the packages like SalixOS or Slacky uses.

gapan 01-15-2015 03:00 AM

Quote:

Originally Posted by ReaperX7 (Post 5301040)
Gslapt works best if you have a depedency listing added into the packages like SalixOS or Slacky uses.

No. Gslapt doesn't care if you have a dependency list or not. It will use it if it's there, otherwise it will work exactly like slackpkg.

ReaperX7 01-15-2015 03:47 AM

I never said it was required. I said it works best if you have it in the packages so it has more functionality, otherwise it simply duplicates existing functionality. In some situations this can be useful, like sbotools uses the info files for dependency listings to incorporate, but again it's a beneficial extra that's optional.

gapan 01-15-2015 04:15 AM

True, but in this case we're talking about functionality that slackpkg lacks anyway, so it doesn't matter. Gslapt is the GUI that the OP is looking for. It works just fine with the slackware repos that have no dependency information.

ReaperX7 01-15-2015 06:10 AM

I'm not suggesting it be done, but even if slackpkg doesn't support dependency resolution natively, adding the extra text file to list dependencies in native Slackware packages would be mildly interesting to see, as well as serve as a low level guidebook to people rebuilding packages or minimalist installs that want to expand from a core custom system, outwards. Natively it would just be a "you need to install this first", while with gslapt and slapt-get it could serve to help pull in requirement packages as needed.

It probably won't happen, but its a thought nonetheless.

Didier Spaier 01-15-2015 06:53 AM

Quote:

Originally Posted by ReaperX7 (Post 5301229)
It probably won't happen, but its a thought nonetheless.

Hum... maybe you didn't have a look here yet ;)

Oh, and just in case you didn't know that already, gapan aka George Vlahavas is Salix maintainer, and as such knows more about package management in general and package management tools in particular than you (probably) and me (certainly).

He is also the author of maybe more Slackware compatible packages than anyone but Patrick Volkerding.

kimdino 01-15-2015 08:39 PM

Quote:

Originally Posted by qweasd (Post 5301039)
I am not saying you don't have a point, not at all; to each user his or her own. But you could also have them copy-and-paste something into the root prompt.

Very true.

Right now I'm trying to get Samba to work between two Slackware boxes and would give my right arm for a really good GUI with parameter checking. I've spent days on the CLI, wearing out google, tweaking this, then trying that, and screaming at my PC. Something that MS-Windows, with it's really good GUI, makes simple and painless.

When trying to get your head around doing something unfamiliar a GUI is the way to go. Whereas, when trying to give instruction to someone who can't see the same screen as you, then the CLI is much better. That is one of the real beauties of Linux, the choice of options to suit the situation. Hmmmm... except for *?&**ng Samba :banghead:.

Also, I often find a GUI useful to get something working, then use the CLI for fine tuning too delicate for the GUI.

kimdino 01-15-2015 08:59 PM

Quote:

Originally Posted by Didier Spaier (Post 5301244)
.... gapan ... knows more about package management in general and package management tools in particular than you (probably) and me (certainly).

Hi gapan,
I find that 'slackpkg' and 'slapt-get' each have differing advantages and would like to be able to use both. However, I have broken the package management on many systems in my time, so I am now very wary of using 'slackpkg' now that I have migrated my boxes to 'slapt-get'. Is it possible to get them to share the same setup and data files so that each is aware of changes made by, or to, the other?

Thanks in advance, Kimdino

brianL 01-16-2015 04:09 AM

A gooey - sorry, GUI - front-end for slackpkg!?!? Sacrilege!!! Get thee to Ubuntu!
What next? Talking paperclips? This ain't no user-friendly highway, this is the road to hell.
:)

hitest 01-16-2015 06:41 AM

Quote:

Originally Posted by brianl (Post 5301782)
this ain't no user-friendly highway

this is

kimdino 01-16-2015 12:09 PM

Quote:

Originally Posted by brianL (Post 5301782)
A gooey - sorry, GUI - front-end for slackpkg!?!? Sacrilege!!! Get thee to Ubuntu!
What next? Talking paperclips? This ain't no user-friendly highway, this is the road to hell.
:)

;) chuckle But I've got a lot of respect for Ubuntu users. I once heard Slackware described as admin-friendly as a rattlesnake, following that line Ubuntu is a hippopotamus. Taking into account that a rattlesnake is only dangerous when it feels threatened, which would you rather have to deal with?

But here's a little story for the many CLI fanatics out there.

; *** String data ***
0000: Slackwar ........................ 53 6C 61 63 6B 77 61 72
0008: e is for ........................... 65 20 68 73 20 66 6F 72
0010: wimps. ........................... 20 77 69 6D 70 73 2E

0017: LXI B, 0x17 .................... 01 17 00 .. ;Init BC as byte counter
001A: LXI D, [FORUM_POST] . 11 ?? ?? .. ;Point DE to output
001D: LXI H, 0x0000 ................ 21 00 00 .. ;Point HL to data source (String data)
; *** Loop point ***
002A: MOV M,A ...................... 77 ............ ;Copy byte pointed to by HL into Accumulator
002B: STAX D ......................... 12 ............ ;Copy accumulator contents to output
002C INX D ............................ 13 ............ ;Point DE to byte o/p point
002D INX H ............................ 23 ............ ;Point HL to next byte to be o/p
002E: DCX B .......................... OB ........... ;Decrement byte counter
002F: JR NZ, -5 ...................... 20 FA ....... ;If BC != 0 jump to Loop point
0031: RET .............................. C9 ........... ;else, all done.

Them were the days, when programmers were big (only fingers & brain got any exercise) and hairy (no time to shave). But was I ever glad to be able to move from an 8080 to a Z80 system as the clearer instruction set + extra instructions made coding so much simpler and easier to understand. Maybe I lost some big, hairy programmer cred but I got more done with less mistakes.

Now I've got an articial brain of power way beyond imagination compared to the days when I had to assemble by pencil. Why not let it do the grunt work of the thinking for me. After all, the point is to get the job done, not work out how to do it.

gapan 01-17-2015 12:49 PM

Quote:

Originally Posted by kimdino (Post 5301633)
Hi gapan,
I find that 'slackpkg' and 'slapt-get' each have differing advantages and would like to be able to use both. However, I have broken the package management on many systems in my time, so I am now very wary of using 'slackpkg' now that I have migrated my boxes to 'slapt-get'. Is it possible to get them to share the same setup and data files so that each is aware of changes made by, or to, the other?

We're getting off-topic, but I see nobody else cares so...

First of all, there's no real reason you should use both.

Anyway, if you only use slapt-get with official slackware repositories, there shouldn't be a problem and you could use both. You would still have to edit their respective settings files separately so you use the same repos and specify the same excludes/blacklists, and run "slackpkg update" and "slapt-get --update" separately, but that's about it. They both share the same package database so there shouldn't be any problems.

Add extra repos to slapt-get and that becomes a different story though. slackpkg is not able to cope with that as it was not written with extra repos in mind. slackpkg is a wonderful tool that does exactly what it was designed for, perfectly. But it was designed for interfacing with official slackware repos only, and nothing else. In this case, you will have problems and you should better stop using slackpkg.

I'm talking about the official slackpkg that comes with slackware here. If you swap that with the unofficial slackpkg+, you could set both slackpkg+ and slapt-get with any number of repos and there shouldn't be any problem. As long as you make sure their respective settings files point to the same repos and have similar settings in general and you update their respective package caches at the same time.

vito_spatafore 07-25-2016 08:06 AM

just what im looking for ...

Gerardo Zamudio 07-27-2016 10:14 AM

Now that the thread is revived I figured I'd post this : http://gernot-walzl.at/index.php?nav...e%2Fsbopkg_gui ( original thread https://www.linuxquestions.org/quest...qt-4175582701/ )

It's for sbopkg though, not slackpkg. May be helpful for anyone arriving here through a search engine.

vito_spatafore 07-27-2016 07:31 PM

nice nice very nice tool !


All times are GMT -5. The time now is 09:51 AM.