You are not logged in.

#1 2005-03-18 13:41:30

goldfrapper
Member
From: Belgium
Registered: 2005-03-18
Posts: 8

Pacman architecture + searching packages via interface

I am aware of the long discussions on GUI's for pacman. But we have to focus on the aspect of usefullness when talking about software development.

Pacman is a package installer etc.. and thus the link between a user and installing applications. Pacman is a very usefull tool/system: It is fast (using the wget option), doesn't breaks easily on dependencies, etc... . But pacman lacks on one big feature: searching!.

If I need to search for a application I will have to use the archlinux website! (using grep and pipe the output is not an option).
Of course I could use the pacman -Ss search-term command but then I could get a long list of unstructured results.

Also if i would like to batch some packages I have to type all of them at once -> this is not a preferable way of working. Whenever I like to install a number of packages at once I have to type all the names. Selecting them in a list is conveniance.

The kde application kpackage is perhaps the best way to implement this functionality. I found a lot of posts on a kpackage plugin but none very informative on the matther of existance.

I am not interested in a real GUI for pacman, but more specific information on pacmans architecture and possibilies to be implemented inside automatisation applications like kpackage.

Offline

#2 2005-03-18 13:58:02

arooaroo
Member
From: London, UK
Registered: 2005-01-13
Posts: 1,268
Website

Re: Pacman architecture + searching packages via interface

This is simply not the case.

pacman -Ss p2p
extra/amule 2.0.0rc8-1
    aMule is a eMule-like client for ed2k p2p network
extra/gift 0.11.8.1-1
    A bridge between P2P protocols and front-ends.
extra/napshare 1.3-1
    A complete, fully featured Gnutella P2P client
extra/xmule 1.9.5-1
    An easy to use, multi-platform clone of the eMule P2P filesharing client

pacman -Ss p2p ftp

current/bftpd 1.0.24-2
    A very configurable (and secure) Linux FTP server
current/gftp 2.0.18-1
    A multithreaded ftp client for X Windows
current/lftp 3.1.0-1
    Sophisticated command line based FTP client
current/netkit-ftp 0.17-3
    Commandline ftp client
current/netkit-tftp 0.17-3
    This is netkit-tftp for Linux
current/proftpd 1.2.10-2
    A high-performance, scalable FTP server
current/rssh 2.2.2-1
    A restricted shell for use with OpenSSH, allowing only scp and/or sftp
current/snarf 7.0-2
    Command-line URL retrieval tool (http/ftp/gopher)
current/vsftpd 2.0.2-1
    Very Secure FTP daemon
extra/amule 2.0.0rc8-1
    aMule is a eMule-like client for ed2k p2p network
extra/gift 0.11.8.1-1
    A bridge between P2P protocols and front-ends.
extra/napshare 1.3-1
    A complete, fully featured Gnutella P2P client
extra/xmule 1.9.5-1
    An easy to use, multi-platform clone of the eMule P2P filesharing client
extra/kbear 2.1-2
    A graphical ftp client for KDE
extra/ncftp 3.1.8-1
    A set of free application programs implementing FTP
extra/pure-ftpd 1.0.20-2
    Pure FTP Server is a fast, production quality, standards-conformant FTP
    server
extra/sitecopy 0.14.3-1
    Synchronize local and remote web site via FTP or WebDAV
extra/tftp-hpa 0.40-2
    official tftp server
extra/weex 2.6.1.5-1
    With weex, the maintainer of a web site or archive that must be administered
    through FTP interaction can largely ignore that process
extra/wput 0.5-1
    A command line tool to upload files to FTP site, the opposite to wget

searching for "p2p" gave me all the packages with p2p in their name/desc. Seaching for "p2p ftp" gave me all the ftp OR p2p pacakges.

Is that not what you want?

Offline

#3 2005-03-18 14:56:17

Mith
Member
From: out there
Registered: 2004-10-05
Posts: 163

Re: Pacman architecture + searching packages via interface

I think one of the main things goldfrapper wants is the chance to "deselect" certain packages when running an update. Same here since I use a custom kernel and everytime I run "pacman -Syu" it wants to update the kernel.. so I cancel and then type in the packages that I still want to update.. except for the kernel of course...


ArchLinux (x86_64) w/ kdemod

Offline

#4 2005-03-18 15:20:31

arooaroo
Member
From: London, UK
Registered: 2005-01-13
Posts: 1,268
Website

Re: Pacman architecture + searching packages via interface

Mith wrote:

I think one of the main things goldfrapper wants is the chance to "deselect" certain packages when running an update. Same here since I use a custom kernel and everytime I run "pacman -Syu" it wants to update the kernel.. so I cancel and then type in the packages that I still want to update.. except for the kernel of course...

man pacman tells you that you can add:

IgnorePkg = kernel26

in /etc/pacman.conf. Although it could be any package (or indeed a list of packages.

Offline

#5 2005-03-18 16:39:38

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Pacman architecture + searching packages via interface

man, arooaroo's on the ball with this one... you responded exactly as I would have...

Offline

#6 2005-03-18 16:43:18

goldfrapper
Member
From: Belgium
Registered: 2005-03-18
Posts: 8

Re: Pacman architecture + searching packages via interface

What I want is an easy way to search for packages when I dont know there name. And an easy way to select/deselect/order packages according to personal needs. (A bit like the webinterface on the archlinux homepage).

This is what I like to call software or package management. I think pacman is genius anough (at least it's structure) to deliver that, but thatfor it will need a different approach.

For example: I can download and install the package kde-base but is their a reliable way for me to know what this package includes? This is one of the possitive parts of kpackage(when using rpm's or deb packages) : not only does it gife a brief description, it also lists to output files and applications that are contained.

Try pacman -S kdm or even pacman -Ss kdm!

At the end you'll have to google for it to find out it's locked up inside the kde-base package.

What we need is a way to make pacman packages more transparent and browsable / searchable.

Offline

#7 2005-03-18 17:40:20

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Pacman architecture + searching packages via interface

goldfrapper wrote:

Try pacman -S kdm or even pacman -Ss kdm

I think a plan to allow "pacman -Sl pkg" or something of the sort is in the works....

for locally installed files, you can use "pacman -Ql pkg" to list files... combine that with a simple grep and you got it...

# pacman -Ql | grep kdm

Offline

#8 2005-03-18 18:09:09

goldfrapper
Member
From: Belgium
Registered: 2005-03-18
Posts: 8

Re: Pacman architecture + searching packages via interface

I was more thinking of something like a: this package installs (you get a list of files or a list of sub-packages if the package is a container). And a this package requires (another list).

# pacman -Ql | grep kdm

This is, as I said before, not a prefferable way to determine the existance of a package inside a tree. What tou get with this command is a long list of files inwhich the string "kdm" occours at least once. A logical consequence is the appearance of results like:

/opt/kde/share/icons/crystalsvg/64x64/apps/kdmconfig.png

In worse cases, like when searching for "dict". The grep command would display the words "predict" "kdict" "dictionary" equaly for they all have a perfect occurance of "dict".

There would have to be a trigger to define wether I want to search inside the packages name, desciption, files, dependecies, etc...

That would mean transparancy!

Offline

#9 2005-03-18 19:19:41

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Pacman architecture + searching packages via interface

I think you're totally, 100%, missing the point of pacman.  Pacman is simple.  It's supposed to be.  People have suggested adding SQL backends and things like this to it, but that defeats the point of simplicity.

sure "pacman -Ql | grep kdm" isn't going to work exactly, but if you understood *simple* regular expressions, it's not too hard to extend ("/kdm$") to list kdm itself.

In addition, pacman -Qo /opt/kde/bin/kdm (is this the right path??) will list what package it is contained in.

kdm, however, is a stupid example.  no one would do:

# pacman -S kdm

if they didn't already have:

# pacman -S kde

and in that case, they would realise they already have kdm

you keep talking about a notion of "packages inside packages", but you're missing the point... you're looking for files within packages...
do you know who controls that? the developers...
look here: http://docs.kde.org/ it lists all programs in each kde package...
arch packages are nothing more that packages as the developers intended

hmmm kdm is part of kdebase... try a "pacman -Ss kdebase"

Offline

#10 2005-03-18 19:20:54

arooaroo
Member
From: London, UK
Registered: 2005-01-13
Posts: 1,268
Website

Re: Pacman architecture + searching packages via interface

phrakture wrote:

you responded exactly as I would have...

Long lost twins, perhaps? tongue

Offline

#11 2005-03-19 14:08:50

goldfrapper
Member
From: Belgium
Registered: 2005-03-18
Posts: 8

Re: Pacman architecture + searching packages via interface

Pacman is simple.

Absolutly, I admire pacman for that reason. But I wanted to put simplicity into contrast: Consider a list of known packages you would like to install, You would have to type all of them at command line which is affordable but can be easily done by pre-selections (package groups etc...) or a selection interface.

People have suggested adding SQL backends

I have seen those posts on the forum. Indeed that would only make the system slow and more difficult to work with (at developers side).

pacman -Qo /opt/kde/bin/kdm

I am trying to state an example here: kdm is also used outside kde (as the WM), but always together with files from within the kdebase package. Using regular expressions to find out wether or not a package is included inside a certain package, leave alone wether a application (and thus file(s) ) is installed on your system can be time consuming and creates a difficulty level.
Regular expressions can be easy to use, true annough, but they don't make it anymore simple do they?

When you say "pacman is meant to be simple" I understood "simple" as in easy, fast and flexible in use seen from the users view.

Offline

#12 2005-03-19 17:12:34

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: Pacman architecture + searching packages via interface

I would say this is more a problem with how KDE is packaged than how pacman works. No matter how much searching there is, there could always be more. If you can search pacman for which files are installed in a package (which is, BTW, supposed to be possible via the web interface soon), somebody would probably say "yeah, but I want to search for files that contain the word 'GPL'".

In this case, it would be more sensible to package KDE with all the optional style packages like in separate packages. This would reduce the size of the core, substantially. This has been discussed before though, KDE is a pain to package when you're following the style the developers recommend, trying to split it up would be a nightmare, probably impossible.

Again, in this case, if I wanted kdm, I would have installed kde-base and then run 'locate' to see if kdm was installed. This is typical usage on a Linux machine.

This doesn't answer your query for the general case. Its not currently possible to search for one file in an existing package. It should be possible via the web interface, eventually. I don't think it will be possible via pacman because of the way the data is stored in the database; file lists are not stored. If they were, it would tak a lot longer to download the db every time and thus to refresh the system.

Dusty

PS: arooaroo.equals(phrakture)?... aaaaaaaaaaaaah!

Offline

#13 2005-03-19 18:22:10

goldfrapper
Member
From: Belgium
Registered: 2005-03-18
Posts: 8

Re: Pacman architecture + searching packages via interface

1. Searching

Ok lets take the webinterface for example: This is what i am talking about! Whenever I need to find a program of which I don't know the name I will go to the archlinux.org website to search because it has a readable output (well, html output ofcourse) It would be nice if something similar would exist localy (perhaps even without the need for an internet connection if  local package repositories). This makes searching / Browsing the repositories much nicer experiance.

2. Package Management.

I've learned the pacman man 'out of head'. So I am using it as method to maintain installed packages and repos etc... But this is not a prefferable way! Lets say I have about 500 packages installed (not much of an effort) the listings pacmans query functions would give are huge (definitly at command line) and I have to pipe them trough another program or cat them at standard output to file. Nicer would be a way to have an overview (perhaps in subcategories).
I found out that the command pacman -Qg displays a number of so called groups (categoriced packages like kde, gnome but also ladspa-plugins etc...).

Pacman could stay as simple as it is now, it only needs some kind of front-end or abstraction layer- like the archlinux website already does in a way - only locally and with package managemant added.

Offline

#14 2005-03-19 19:35:58

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Pacman architecture + searching packages via interface

sigh... I thought this was a search-functionality type post, but now it comes t another GUI pacman debate...
there's a hundred posts of this nature....

anyway, try out pacmenu from the user contrib. forum

Offline

#15 2005-03-19 19:49:08

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: Pacman architecture + searching packages via interface

You might also be interested in rasat's pkgsweeper script.

As far as GUI frontends to pacman go, there are dozens of them out there, in some form or another. Try one, or write a new one (most people seem to prefer to write new ones, I have no idea why). Most arch users are comfortable and satisfied with the command line tools; that's why we use them. I'll guarantee you that no Arch developer is going to create a GUI frontend to pacman. However, they are creating a library version of pacman to make it easier for 3rd party developers to create GUI versions. Also, as I said, there are already frontends out there; find them.

Dusty

Offline

Board footer

Powered by FluxBB