You are not logged in.
Oh, I also want to apologize if I've offended anyone. I didn't think this would become such a long winded discussion. :oops:
some people like to debate 8)
Offline
shadowhand wrote:Oh, I also want to apologize if I've offended anyone. I didn't think this would become such a long winded discussion. :oops:
some people like to debate 8)
Yeah, I'm one of them. :oops:
Anyways, I'm very happy the forums are active and the members of the community stand up for and contribute to Arch so much. ![]()
·¬»· i am shadowhand, powered by webfaction
Offline
I must say that my biggest grievance with pacman is that I can't get it to show only specific pacakges installed (or I don't know how)
i.e. you can't do a "pacman -Q *kde*" to show only the packages with kde in the name. You can only do a pacman -Q and show every package installed on the system...
I'd love it if when removing packages it would take out all the dependant packages not needed by anything else as well... Maybe it already does this but when it came time to remove some stuff I had a hard time.
In NO WAY am I saying a GUI is needed... While I'm no coder and I'm still by all means a *nix newb I found that pacman could be improved upon... but KISS and keep it CLI.
Offline
i.e. you can't do a "pacman -Q *kde*" to show only the packages with kde in the name. You can only do a pacman -Q and show every package installed on the system...
pacman -Q | grep -i kdeOffline
First off, LONGHORNEXTREME: Try this:
pacman -Q | grep kde
That will list all packages with kde in the name.
Anyway...I'm really writing just to say that the great thing about Linux is that you can get whatever you want. A pacman GUI will not be forced on you, but if you want one...make it. Get a project started, ya know?
You're right (whoever said it), Linux DOESN'T have to be popular. That not my goal. But if it IS someone's goal to make Linux popular, what's the harm?
What I'm trying to say is: Linux and OSS is all about letting go of control and ownership of software. So...let it go. You'll always be able to get exactly what you want out of Linux, as long as there's someone out there willing to put the time into it.
Offline
You're right (whoever said it), Linux DOESN'T have to be popular. That not my goal. But if it IS someone's goal to make Linux popular, what's the harm?
What I'm trying to say is: Linux and OSS is all about letting go of control and ownership of software. So...let it go. You'll always be able to get exactly what you want out of Linux, as long as there's someone out there willing to put the time into it.
Well said.
·¬»· i am shadowhand, powered by webfaction
Offline
i admit, that i didn't read all postings in this thread ... but non-the-matter, i want to add some comments ... normally, this is not the rule (not reading everything in detail and then commenting) but some posts are repetitions and i hope to have read everything important to be able to comment without being contradictorly or wrong or repeating in any way
1) does pacman need a GUI:
-------------------------------
if you feel needing a GUI for pacman, feel free to use one of the products of projects who agreed with your idea ... kpacman and others ... if you want them better or need another one, feel free to write one
open-source software is very often NOT built to be the most popular software around, but to be the best suitable one for the author and the people who share the same idea. a software that all users like is crap, per definition! why? because there are always different ways of thinking about something and doing things ... if there is only ONE thing (that all like), this ONE thing is maybe for the mass acceptable (the mass calls it cool), but the interesting people do not like it. it's average, but it is usefull for average tasks ... not for great tasks ... because it follows the masses --- BE UNIQUE! THINK! /* if you feel that some parts sound political, sorry for that */
2) libilizing of pacman
------------------------
libraries are usefull only to be usefull to other apps. if you have a look at pacman (i mean the core of it), then you will realize, that it is itself "nothing special". most concepts used inside are used in other tools/libs too ... it's the CONCEPT, that makes pacman great! it's like playing with "LEGO" (i mean the classical LEGO)... you put things together and if your idea is great, the product looks great. in LEGO, you don't make a library of a bigger structure or the product you made ... it is per se great ... but if you start doing mass-production of this same part, it starts to get boring. ok, what has LEGO to do with pacman? maybe nothing, but i wanted to explain, why i don't think that having a library will make it easier for GUI's. the concept of a library is to be reused a lots of times in different software. the current GUI's work perfectly (some do not yet use all functions of pacman) and this without librarisation. | this was about librarisation being usefull for GUI | pacman works perfectly as-is, and the easiest way to make a GUI is to make a wrapper to pacman
librarisation can make sense on other approaches. it is often so, that when you start grouping things and making library out of blackbox-binary, you start thinking on rewriting parts of code to be 1) more efficient, 2) faster, 3) cleaner, 4) better .... this can maybe speedup pacman
librarisation of pacman would be very nice-to-have, but it is not essential and also not important
The impossible missions are the only ones which succeed.
Offline
Well, I suppose that sums it all up.. I personally believe there can be other advantages of libidizing pacman. For example, it's easier to (by misstake or oversight) break compatibility with a wrapper than with something that is using a well thought out API. Also, I think that a library would more easily be extended to better fulfil the (possibly) extended needs of GUI-users (or heck, embedded users that use a network frontend), but I can understand that such extensions arn't desirable. Binding pacman by the KISS principle might be a good idea. *shrug*
I'm just a little bit allergic to thinking that is locked within a certain spectra, and by taking those "locked" statements and following them to the extreme I hope to show the errors in the logic. I suppose that sometimes it just gets a bit obsurd and even contra productive. Sorry if that happened now without me noticing. :?
Just a small word on popularity... I don't think it implies pushing linux on others, I think that popularity is something that becomes inherent in a good product. (atleast when it's noticed by others)
kth5: I think the lizard in me was more influenced by the expression on your avatar than your smilies, giving your post a harsher wording than was intended... forum newbie as I am :-/ Just a warning though, others might fall in the same trap
shadowhand: thanks for sticking your head out in the first place, I think I learnt quite a bit from this debate. God luck with that xfce live-cd.
Over and out.
Offline
kth5 was not saying that he doesn't want linux to go anywhere, in fact there is nothing like that in here at all. He was just stating an OPINION.
I just want to point out the irony of rebutting an opinion with the statement that the statement is rebutting is opinion. It makes no sense. Even what you said is an opinion. Most "facts" we as humans talk about are opinions.
But here's the fact of the matter:
There's nothing wrong with Arch Linux staying its current course. I like its current course. In the past when I've had suggestions--which I worded too aggressively, because that's one thing I tend to do--I've found that people rebut my suggestion instead of stating what their position is and letting there be two points of view.
I think a GUI front-end for pacman will be a boon for the Arch Linux community. But I think pacman itself should stay the same, lightweight and strong.
fffft!
Offline
i too had my share of creating a gui pacman frontend. and the problem with a wrapper to pacman is to diagnose its result messages and act accordingly. if we were to have a libidized pacman, those problems should be solved, and a frontend will be able to actually get the un/successfull result from the pacman function without the need to guess it upon a text result (as currently pacman provides).
and as phrakture stated already, i dont think a libidized pacman should be too much work - maybe some minor hacks. to someone who is familiar with the code already (wink wink) this should be a breeze.
Offline
Well, this seems like a good place to drop an update on the pacman library.
Wombat (dubbed "the release that never comes" by we devs) is pretty much ready. As most of you know, "ready" in an Arch sense just means that the Current repo and the kernels are in a stable state to be packaged into an ISO. There are no new grand features in the 0.7 installer or anything, just updated packages and a few improvements here n' there.
As for the library, it's all Aurelien's fault. He's defined a very nice and robust API around pacman, and once we coerce some of the more complex parts of pacman into the API, we should be good to go. Don't hold your breath yet, though. It will still be a while before the library is ready for public consumption.
btw, I quite like reading these debates when they stay constructive and objective (well, as objective as we humans can get
). It gives a good image of how the community sees Arch and its potential. Gracias.
Offline
There are no new grand features in the 0.7 installer or anything, just updated packages and a few improvements here n' there.
.
Please be sure you at least add support for PPPOE on install. ITt. is very annoying not to have it available on install discs.
AKA uknowme
I am not your friend
Offline
sarah31: Why don't you want Arch to get bigger?
STOP putting words in my mouth. I NEVER said I didn't want arch to get bigger... personally I don't care if it does or doesn't. "Bigger" does not mean better. I would like Arch if it was small or gigantic.
If you want me to be brutally honest though Arch is not ready for "bigger". The devs do not have the resources to work full time on it and there are simply not enough of them to support bigger. The more people that use it the more you see the small problems become an open sore.
Besides making Arch more user-friendly is not the only answer to making it bigger. If you think that is the limiting factor you would be wrong.
Arch is a wonderful distro heading in more and more great directions all the time. I installed Arch for the first time in early 2004 and couldn't figure it out (I was coming from Knoppix and using point-click.) After using 2 source based distros (Lunar and Gentoo) I decided to give Arch another go, and I've been nothing but happy.
I honestly believe that Arch can be better than any of the "big 4" (Debian, RH flavors, SuSe, Mandrake) if it becomes possible to make Arch user friendly. However, I am completely against Arch itself doing this. Instead, I think the Arch developers should allow for the option (making a pacman lib for instance) and let the community build a user friendly meta. I never intended to suggest that Arch itself becomes GUI-fyied.
IMO it is better. Otherwise I would not have used it for nearly three years. IF i ever go back to using PCs i will use it again.
Also, calling users dumbasses doesn't really help anything. I've been careful to explain myself and so have you. Perhaps Algol wasn't as careful, but there are several ways to interpret what you said. I understand you have your idea of what Arch should be, and I have mine. I think it would be nice to allow for our ideas to co-exist.
I gave up caring about hurting feelings when it became obvious that the open source community is a spiteful bunch that has little regard for those that have truly made an effort to help people expand their computer experience.
How I interpretted Algol's comments was that I was some wet behind the ears n00b that does a lot of barking but never bites. Well I have and you know what? Whether I am nice or not people still take pot shots at me. It hurts no matter how much I try and thicken my skin. So you know what? I DON"T CARE ANY MORE.
I will continue to help people when I can and I will express and defend my POV. You don't like you can either tell me off like Algol did or you can opt to just look the other way and let others deal with me.
No matter what I do I know whatever I say that is "bad" is what people remember the most. Nobody bothers to look at the support I have given.
TO conclude I never opposed libidizing pacman since I knew that it was/is happening and it is benefit for more than those GUI types out there. As far as I am concerned though libidizing pacman and GUIfying Arch should be low on the list right now. There are many more important things to work on such as:
better packageing standards
training of new maintainers
increasing the size of the development team
paying the development team
getting the new user contributed packaging system in place
a roadmap
....etc
The QC and dev team need to be strong before Arch goes anywhere.
AKA uknowme
I am not your friend
Offline
why does a gui front-end require a library?
Does pacman not return a proper exit value on failure?
Call it shortsightedness on my part, but could someone explain why pacman needs to be broken down into libraries? It seems that a small program doing the "right" things would be a simpler solution than a set of libraries serving the same purpose. Maybe there is some "down the road" goal being aimed for...
just curious about the motivations, as I am always interested to see other people's viewpoints on software development.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
why does a gui front-end require a library?
Does pacman not return a proper exit value on failure?Call it shortsightedness on my part, but could someone explain why pacman needs to be broken down into libraries? It seems that a small program doing the "right" things would be a simpler solution than a set of libraries serving the same purpose. Maybe there is some "down the road" goal being aimed for...
just curious about the motivations, as I am always interested to see other people's viewpoints on software development.
it is extremely awkward to send input and output to pacman through a program. and all it takes is a small change in the output of pacman to break a frontend.
whereas with a library, its much much easier and much more practical to work with. and librarializing pacman wouldnt take much work either.
iphitus
Offline
if you have library you doesn't have to pipe the pacman cli frontend, instead you run the library functions directly,
you can play around with this if you want,
pkgname=pacman-pygtk
pkgver=0.1pre
pkgrel=1
pkgdesc="GUI frontend for libpacman"
url=""
depends=('pygtk')
source=(http://xerxes2.1go.dk/pacman-pygtk-0.1pre.tar.gz)
md5sums=('e4938df07c8c6b88f7a00150d378dec9')
build() {
cd $startdir/src/$pkgname-$pkgver
mkdir -p $startdir/pkg/usr/bin
mkdir -p $startdir/pkg/usr/share/pacman-pygtk
mkdir -p $startdir/pkg/usr/lib/python2.4/site-packages/pacman_pygtk
install -m 755 pacman-pygtk $startdir/pkg/usr/bin
install -m 644 rc $startdir/pkg/usr/share/pacman-pygtk
install -m 755 *.py $startdir/pkg/usr/lib/python2.4/site-packages/pacman_pygtk
}if you look at the code you see what I mean, even if are a Ruby zealot,
try "Read DB" in the "Options" menu and you see how it can be done even if this reads the files directly now,
arch + gentoo + initng + python = enlisy
Offline
....whereas with a library, its much much easier and much more practical to work with. and librarializing pacman wouldnt take much work either.
For my information, in software development what does a "library" do? ... some kind of pre-made codes??? When libidizing pacman what's the difference from the current version?
Markku
Offline
a library is an importable library of functions.
in my code (im a python programmer, i realise the pacman lib is C), i could do,
import pacman
or
#include <pacman.h>
to load it up, whatever language you use....
return = pacman.install("totem")
and it will install totem, i can check the return value to see if it worked, failed, etc.
however, without a lib version, i have to write a LOT more code, code that starts pacman, sends messages to pacman, gets the output of pacman and then filters through it to see if it works, etc. It takes a *lot* more work to do, and it's a *lot* harder and would require substantially more code. And all this effort could also be broken if pacman changes it's output text even by a character.
iphitus
Offline
For the interrested, here is quite a good read on shared libraries:
http://www-106.ibm.com/developerworks/l … 3SharedLib
While not completely related to a libidized pacman, it might be fun to know ![]()
Offline
hmmm..so basically you are creating a pacman library, and a "gui frontend" isn't really a frontend to pacman then. It is another version of pacman, built using the shared libraries.
I think this is where my confusion was laying. With the "front-end" terminology.
As for new versions of pacman breaking compatability, it would be a simple fix most of the time. If you had changes in the library, you would have the same types of issues.
I think you should clarify the language used when speaking of libridization. You are basically creating a core package interaction library, of which pacman will utilize. You are then freeing people up to create their own "pacmans", be they gui or otherwise.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I'm too lazy to read all the goofy flames and half-formed opinions in this thread (and its numerous clones from previous months), but I was wondering if anybody has made a comprehensive list of the GUI pacman frontends currently available or partly available... with links and stuff. There could be a wiki page linking to the various options or something.
Trying to search the forum for 'GUI pacman' doesn't give a very concise list of what's available. ![]()
I've heard of kpacman, pakman (are these the same??) archibald, and rumors of a gtk based pacman. Does anybody have links, or perhaps a comparison for each of these?
Dusty
Offline
and has anyone thought of collaboratring and having one GUI instead of ... lots? Too much choice confuses the users you so desparately want.
AKA uknowme
I am not your friend
Offline
That's one of the reasons I was asking; if people knew what was available, they could do some collaboration... but first step is to know what's available.
Dusty
Offline
hmmm..so basically you are creating a pacman library, and a "gui frontend" isn't really a frontend to pacman then. It is another version of pacman, built using the shared libraries. .
exactly! like lego! if you build something from pieces, it is quite always a new product! Viva la (r)evolution! ;-)
The impossible missions are the only ones which succeed.
Offline
That's one of the reasons I was asking; if people knew what was available, they could do some collaboration... but first step is to know what's available.
Dusty
we have forums, we have wiki ... we need people to use them to do _c_o_l_l_a_b_o_r_a_t_i_o_n_, eh? ;-)
The impossible missions are the only ones which succeed.
Offline