Arch package manager to see whats avaiable?

Ubuntu has synaptics and add/remove option  , what does arch have? Right now with pacman im just taking a stab in the dark , but how can i see what is available for me to install?
Need something similar to synaptics that shows the programs, and tells me what they are for

The pacman manual is all you need, provided you have read the various guides on the wiki.
If you want Add/Remove, maybe you should reconsider your choice of distro. I strongly suggest you read up before you ask basic questions like these. Pacman can display all the info you want - and the manual tells you how to do it. If that is not enough there are also graphical front-ends available for pacman.
If you have a problem that can't be tackled by personal initiative alone, open a topic. This one is done .

Similar Messages

  • Slackware user - Arch install process and package management questions

    I currently am using Slackware 12 with updates.  It has become increasingly cumbersome to compile new software given the number of dependencies that also have to be compiled, and have their own dependencies compiled, etc and so on. 
    Other than the fact that the adoption of new packages is somewhat glacial, and that there is no automatic dependency resolution, I really like Slackware.  Its fast, relatively easy to configure, and easy to use.  I'm conversant in commandline-ese.
    I've been led to understand based on the Arch wiki that Arch is very similar to Slackware in its layout, but with bleeding edge packages and dependency resolution, so I would think it would be about perfect.
    However, I also understand that the install is more difficult that Slackware.  How much more so is my question.  Is it impossibly confusing and unhelpful like Debian installation was, or just slightly more difficult than Slackware or FreeBSD (both of which have very smooth installation scripts)
    Also, for packages that have to be compiled from source, are dependancies easy to satisfy from the arch repository, or do dependencies for new software have to be compiled with their dependencies.
    I'd probably just be trashing everything but /home, and doing a clean reinstall.
    Is Arch the right distro for me, or am I better off staying with Slackware?  Like I said, I really like Slackware except for the package management issues.

    I've been led to understand based on the Arch wiki that Arch is very similar to Slackware in its layout, but with bleeding edge packages and dependency resolution, so I would think it would be about perfect.
    You are right about that.
    However, I also understand that the install is more difficult that Slackware.  How much more so is my question.  Is it impossibly confusing and unhelpful like Debian installation was, or just slightly more difficult than Slackware or FreeBSD (both of which have very smooth installation scripts)
    They are quite similar, but Slackware provides more help when doing tasks like - how can I partition my harddisk and so on. But If you're comfortable with Slack's install procedure then installing Arch is much easier, just read the install guide.
    I think Arch is good for you, because currently I have both - Slackware and Arch and both suit me fine for my needs.
    Also remove all *. entries in your /home

  • How can i look to see what is on icloud i would like to manage whats on it

    how can i look to see what is on icloud i would like to manage it. Erase things on there to make more room??

    Settings > iCloud > Storage & Backup > Manage Storage. Select your device. Each app should have an on/off switch, so you can choose which apps' data will be included in the next backup.

  • Unified Package Manager/Format

    I know that this topic is not a new one, but I thought it might be interesting to bring it up once again.
    The reason that I'm suddenly interested in a unified package manager/format, is that I just saw Bryan Lunduke rant about it, and I thought to my self: "Hey, that makes sense!"
    Bryan Lunduke is not someone I usually hold in high regard, but I was intrigued and started googling. To my surprise I found that there wasn't much interest in the subject.
    Now, to you that may make perfect sence, but to me it's absolutely mindboggling. After all, the only reason I'm still sticking with Arch Linux, is the ABS. Not that I don't care for Arch, I really do, but I spend far to much time configuring it, rather than using it.
    So what are the arguments for and against?
    The arguments against is easy if you ask me:
    PRIDE
    Yes I said it: "We're happy with out system and it works damn you!"
    So, it works... Well, so does a bike, but quite often you'd probably like to take your car instead. Maybe it's raining, maybe the distance is great. Who cares, the point is that the fact that it works, doesn't mean that it could not potentially work quite a lot better.
    Back on topic.
    Arguments for, is a bit harder, not least because I'm not as much of an expert on the subject as I'd like to be, but I think they're plentiful.
    I would assume that developers would appreciate this.
    If a set of tools, like the ABS, was included by default, that would indeed make me happy.
    Maintenance of packages for multiple platforms would become quite a lot easier, if not trouble free.
    And so on and so forth.
    I suspect you will be more than able to help filling out the list.
    In the end though, my biggest problem is that people ask for a reason to begin work on such a thing. My counter argument of course it: "Why the hell not?!" Arch Linux already provide the perfect foundation, i.e. pacman and ABS. Of course for cross platform compatibility, some work has to be done, but the greatest problem, I believe, is convincing the community that this is a worth while effort.
    Oh well, enough ranting I suppose. I really just wanted to revive this debate, as I personally find it rather important. I don't have all the answers, but I dare you to come up with a problem that I cannot provide a theoretical solution to. To me it all seem so simple, and it's a mystery that this feat has not been achieved many years ago.
    Best regards.
    NB:
    I'm not so arrogant that I do not appreciate that I may be entirely on the wrong track, but please, if that is indeed the case, do try to enlighten me rather than something uncomfortable.

    Trilby wrote:
    You beat me to that XKCD comic.  It's good for a chuckle, but hopefully that doesn't make anyone think that's all it's good for.  That comic captures the primary (and perhaps only) reason I'd never have any hope in such a cause.
    Just look at attempts an universal language.  You'd be hard pressed to find a handful of people in your day to day interactions who ever really learned esperanto, for example (I think I know one, but I haven't seen him in years).  Now we can set standards, though.  The arch linux forums have selected English as our default language - and in a sense we force speakers of other languages to use English ... in a sense, but not in another sense.  There are various arch linux online communities in other languages, where some other language is the default.  So one community can set a standard and try to enforce it, but that can't stop another community from springing up and using something different.
    So if we say Arch linux's package format is the one package format to rule them all, fine.  But then we have to convince others.  Even if we convinced a lot of debian and red hat people, for example, we'd probably have to compromise a bit and we'd end up with an arch-pm-deb package.  I'm sure some debian and redhat developers would fork their project or start new distros that continued to use .deb/.rpm, and some archers would conclude that this compromise was just a failure and they'd go on using pkg.tar.gz.  And then we have the exact situation of the XKCD comic.
    Sure, the world would be much simpler if one person could make an arbitrary decision based on their own preference and have everyone else in the world follow it.  But that's not our world - and I'm glad it's not.
    I'm usually not much for compromises (more on that on another occasion), but in this case I'm all for it, as long as it's sensible compromises. I have no illusions that the Arch way is the perfect way, and in any case, certain changes would need to be make to make it work.
    I would suggest that some may misunderstand my intentions. I see no reason my the average Debian, OpenSuse, Mint, *buntu, Fedora, Gentoo (etc.) user should experience any change. A Debian user would still use apt-get install package, or whatever graphical front end he or she desires, as with most other distributions, possibly excluding Gentoo and such.
    My interests are limited to the back end system end the tools that are provided by default, like something similar to ABS.
    Last edited by zacariaz (2013-08-17 15:09:31)

  • ABS as an universal package manager

    I've just had a rather interesting thought. I'm lately entertaining (and discussing) the idea of universal package management, self contained packages etc. As I've recently switched to Arch again, I thought about ABS as a system which actually reduces dependence on a single repository, a single rule-set so to speak and adds a great amount of flexibility. It may very well be the best way of utilizing the one universal packaging format that there currently is: source tarballs.
    What if other distros started packaging and maybe even pre-installing ABS, or something similar? Any user of any other distro would only need a tool like yaourt to check up a mirror of all PKGBUILD's available in the whole GNU/Linux universe and initiate an install where the system would just follow the instructions laid down in the PKGBUILD.
    Now, considering the flexibility of PKGBUILD's, you don't even need to have them all compile a given program on the user's computer. Instead of fetching a source tarball it could just fetch a binary tarball. The dependencies are still all pretty much the same (and stated and taken care of by the PKGBUILD instructions), the biggest difference is just that instead of compiling the user gets a pre-compiled package and the whole process is done much faster.
    Anyway, I wonder what you think and if anyone has discussed this before. I think the PKGBUILD's may very well contain one possible solution to coming up with universal package management system, at least as an add-on to a given distro's base packaging system. And even as an add on, and especially with the ability to install binary and not just source tarballs (much like pacman in fact) may add a great amount of flexibility to a given distro's user that they may currently be missing.
    Cheers
    Last edited by libervisco (2008-07-04 02:25:39)

    Stythys wrote:what's the point of having different distros if they all start trying to be the same?
    There's no point at all there because that's not my point. The idea of universal package management is merely meant to increase compatibility, to provide a way to easily install the same piece of software using the same process on any distro. Imagine the benefits this could have for newbie users once such an option was further developed and polished. You could tell someone how to install a given program and it would work no matter what distro you run. As it is right now you have specific instructions per distro, not to mention that one distro has some software which another just doesn't.
    It is not meant to replace the existing package management in these distros, just add a way to easily install software even without it, when it doesn't have what you need or when it's simply simpler for you to do it this way.
    Stythys wrote:Anyways I seriously doubt other distros are just gonna start using ABS if asked. If you want pacman/ABS on a different system, just compile it yourself
    Well, I agree they wont just adopt it. It would all be gradual. Someone starts compiling it for other distros and distributing it through a web site or where possible through community contributed repositories. If people like what they see they start using it more and more until some distros decide to include it by default. Depending on its success the extreme end result would be for it to be a common feature of *every* GNU/Linux system.
    But yes, it does start with someone compiling it.
    Stythys wrote:but then why not just use arch
    Why aren't all GNU/Linux users the users of Arch?
    ABS is by far not the only thing which differentiates Arch from others so it's not like putting ABS on other distros would result in them becoming exactly like Arch. That said, people have different preferences. Not everyone wants nor is knowledgeable enough to go through Arch's install process, for example.
    Cheers

  • Cheflex: a simple yet flexible package manager

    Cheflex is a package manager written in Bash. It is designed to be as simple as possible. I like the simplicity of makepkg and it inspired me a lot.
    Edit: I had to rename Chef to Cheflex. Thanks jasonwryan for mentioning the other chef
    PS: I don't see Cheflex as a replacement for Pacman. Cheflex is designed to build packages easily and locally and it doesn't require any server or repository. Pacman focuses on general and mainstream usage, while Cheflex begins with you and how you want things to be organized and built.
    Last edited by ahcaliskan (2013-05-05 07:36:14)

    Chef is not a replacement for Pacman. Pacman has many functionalities and it is extremely powerful. I see Chef as a secondary use case when using Arch. I developed three different package managers in different languages using Arch. What I was really avoiding was Bash despite the fact that I was not a beginner since I have used linux more than 10 years. Now when I understand Bash, it was fun thing to do an innovative project like this. Chef should be used if you want to learn more about packaging system and advance in scripting and programming languages, as packager and developer. But it might be fun to use as a regular user as well, who knows
    edit: grammar
    Last edited by ahcaliskan (2013-05-04 21:33:09)

  • A non-obsoleting multiversioning package management filesystem.

    I found this in another topic (http://bbs.archlinux.org/viewtopic.php?id=56108), and found it very interesting, since I have conspired to do the same thing myself. The question that has always kept my attention is, "how to eliminate packages from breaking others when being upgraded to versions other packages cannot use?
    Much of this seems to be answered by the approach taken by GoboLinux, where each package essentially becomes a self-contained filesystem. Given such a system, it would also be possible to compile one master binary, and make deltas against it for all successive versions. Doing this would eliminate the extra overhead that such a system would otherwise impose, by having so many versions of the same package on the system at once. But then using the approach as stated by Allen below, multiple versions could and would coexist all in the same directory; /$pkgname. I think that if such an approach were to be fully implemented, even the PKGBUILDs would have to be versioned as PKGBUILD.$pkgver.
    The next big question I have is how difficult would it be to have the binaries in packages patched live as they are running (or just before when called to run)? The idea is this. If we have a single master package upon which deltas are created for every successive version, it would be nice to patch the master package files as they are put into memory for execution.
    http://bbs.archlinux.org/viewtopic.php? … 23#p427323
    See section 6.3.2.3 on http://www.linuxfromscratch.org/lfs/vie … kgmgt.html
    This is very easy to do with Arch given the PKGBUILDs are all made to be put in $pkgdir anyway...  In fact you could adjust makepkg to make pkgdir=/usr/pkg/$pkgname/$pkgver and not tar everything up.  Then you would just need something to put the symlinks into the / hierarchy - there are tools floating around to do this.  Note this cause big problems for people who have a separate /usr partition... but that makes little sense under this scheme
    This was suggested as a method of dealing with the organization of PATHs in a system such as the one described here:
    # make_doinst
    # doinst.sh fragment:
    if ! [ `grep $NAME` /etc/$distribution/program-paths ] ; then
    echo "PATH=/programs-path:\$PATH" >> /etc/$distribution/program-paths
    fi
    # Then have your /etc/profile source the /etc/$distribution/program-paths file and then finally export the PATH:
    . /etc/$distribution/program-paths
    export PATH
    make_doinst                                        # Step 14
    This was meant to be used with another package building tool. But I think the principle applies to any the user chooses.
    I would like to hear some feedback on this to see what others can or have come up with since the original discussion was posed here in: What you think about Gobolinux's FS layout? (http://bbs.archlinux.org/viewtopic.php?id=56108)
    This is somewhat of a related topic (http://bbs.archlinux.org/viewtopic.php? … 36#p450436), at least for me. One of the things that I suggested to others would be the use of a community-wide distcc. The results of builds from the entire network of users would be distributed by deltas. The local ccache would be updated to the latest version of the master, providing new users the immediate benefit of ccache without having actually compiled any packages yet themselves. And using deltas would fundamentally eliminate the concern mentioned here:
    So with every package we update (and note there are many per day) the entire repo gets rebuilt and I assume pushed for users to download in order to keep there system in sync with the Arch repos.  Think of the number of packages on your system.  That would require you to download (probably) several gigabytes of updates every time a single package was updated....
    There would no longer be a need to download gigabytes to maintain each system in sync with the master. Of course this would also benefit from having the files of packages patched in memory as they were called. A live-patching system would really need to be created.
    I currently operate a liquid-cooled quad-socket server which I built especially for this purpose. Having an automatic build system is something that I see as a necessity, not an option. So I have decided to build and operate my own, offering it to others as they choose to participate.
    I guess there are other issues which would be detected and solved by such automatic build system. In the extreme case, after each new package committed to ABS, the whole set of packages should be recompiled to be sure that archlinux repositories are in a stable state. I know that this seems like a lot of work, but with many users contributing their spare CPU cycles (think: cloud computing, or Archlinux@Home) this would set archlinux to a higher level of quality.
    Here's an image of the project (http://www.teamnexgen.org/forum/hardwar … -ever.html) at completion:  http://www.teamnexgen.org/forum/attachm … 3x1600.jpg
    Xavian-Anderson Macpherson
    Shingoshi
    Last edited by Shingoshi (2009-02-01 20:32:52)

    ibendiben wrote:
    pedepy wrote:Then again, just getting everyone to agree & follow a standard hierarchy in the first place would also solve that problem.
    But it stops evolution in a way... It is like the bible telling you what to do, because it's THE (only) GO(o)D way to do it.
    We find 1000 years later that this standard is outdated and stump (well I do ). It makes people narrow minded, and keeps you from moving on.
    So... I like your idea...
    At least thinking about things and exploring the other possible ways makes you wiser... -> go on!
    This has nothing to do with any sort of absolute right/wrong or any evolution. It's about offering users a flexibility in one certain area that. The debate is about whether or not, realistically, they can benefit significantly from that choice, or if its better to standardize.
    Don't bring up your anti-religion complaints without warrant, please. No one's impressed that you're yet another person with a grudge against religion.
    Last edited by B-Con (2008-06-28 23:00:16)

  • Available APIs for process and package management

    Hello All and welcome to my Hello All:
    Welcome to my inaugural post. I am a complete noob to Solaris (although I have been using Linux for 5+ years) and am in the process of trying to get a handle on what local C/C++ APIs (if any) are available for management. Specifically, I am looking to find out about process and package management.
    For process management, basically I would like to know is there some kind of interface to the the prstat application (ie. Memory and CPU utilization). Does something like this exist?
    For package management, I am looking for the ability to add, remove, and query the package �database�. Correct me if I am wrong, but the Solaris package �database� seems similar to that of a Debian system (at least from the perspective that the informational files are stored as plain text in a well-defined directory [ie /var/sadm/pkg/]).
    I have installed Solaris 10 on an x86 machine with a full installation; however, of the installed development kits (listed below) nothing jumped out at me.
    -bash-3.00# ls -1d /var/sadm/pkg/*devel
    /var/sadm/pkg/SUNWaspell-devel
    /var/sadm/pkg/SUNWevolution-devel
    /var/sadm/pkg/SUNWevolution-libs-devel
    /var/sadm/pkg/SUNWgnome-a11y-base-devel
    /var/sadm/pkg/SUNWgnome-a11y-libs-devel
    /var/sadm/pkg/SUNWgnome-a11y-reader-devel
    /var/sadm/pkg/SUNWgnome-a11y-speech-devel
    /var/sadm/pkg/SUNWgnome-audio-devel
    /var/sadm/pkg/SUNWgnome-base-libs-devel
    /var/sadm/pkg/SUNWgnome-camera-devel
    /var/sadm/pkg/SUNWgnome-common-devel
    /var/sadm/pkg/SUNWgnome-component-devel
    /var/sadm/pkg/SUNWgnome-config-devel
    /var/sadm/pkg/SUNWgnome-desktop-prefs-devel
    /var/sadm/pkg/SUNWgnome-file-mgr-devel
    /var/sadm/pkg/SUNWgnome-hex-editor-devel
    /var/sadm/pkg/SUNWgnome-img-editor-devel
    /var/sadm/pkg/SUNWgnome-libs-devel
    /var/sadm/pkg/SUNWgnome-media-devel
    /var/sadm/pkg/SUNWgnome-panel-devel
    /var/sadm/pkg/SUNWgnome-pilot-devel
    /var/sadm/pkg/SUNWgnome-print-devel
    /var/sadm/pkg/SUNWgnome-project-devel
    /var/sadm/pkg/SUNWgnome-terminal-devel
    /var/sadm/pkg/SUNWgnome-text-editor-devel
    /var/sadm/pkg/SUNWgnome-vfs-devel
    /var/sadm/pkg/SUNWgnome-wm-devel
    /var/sadm/pkg/SUNWgnutls-devel
    /var/sadm/pkg/SUNWjpg-devel
    /var/sadm/pkg/SUNWlibexif-devel
    /var/sadm/pkg/SUNWlibgcrypt-devel
    /var/sadm/pkg/SUNWlibpopt-devel
    /var/sadm/pkg/SUNWmozilla-devel
    /var/sadm/pkg/SUNWmoznspr-devel
    /var/sadm/pkg/SUNWmoznss-devel
    /var/sadm/pkg/SUNWogg-vorbis-devel
    /var/sadm/pkg/SUNWopenjade-devel
    /var/sadm/pkg/SUNWopensp-devel
    /var/sadm/pkg/SUNWpcsclite-devel
    /var/sadm/pkg/SUNWpng-devel
    /var/sadm/pkg/SUNWpostgr-devel
    /var/sadm/pkg/SUNWPython-devel
    /var/sadm/pkg/SUNWTiff-devel
    I've placed orders for Solaris Internals and Solaris Performance & Tuning (that should arrive tomorrow), but I was hoping that someone could give me a gentle push (or perhaps a swift kick) in a general direction. :)
    Thanks.

    For process management, basically I would like to
    know is there some kind of interface to the the
    prstat application (ie. Memory and CPU utilization).
    Does something like this exist?Not prstat (although you could 'truss' it and see some of what it's doing to collect the information). kstat is available with a C interface and through perl/shell. It has several CPU fields. It's certainly useful for monitoring, but read-only. I'm not sure what you're looking for in terms of "management".
    Also 'dtrace' can provide tons of dynamic information, but that's not necessarily what you're looking for.
    For package management, I am looking for the ability
    to add, remove, and query the package �database�.
    Correct me if I am wrong, but the Solaris package
    �database� seems similar to that of a Debian system
    (at least from the perspective that the
    informational files are stored as plain text in a
    well-defined directory [ie /var/sadm/pkg/]).Yes, although it's based on the SysV packaging system. I don't believe there's any API for it outside of the 'pkg*' utilities.
    Darren

  • Package manager aka 'pacman'

    So, I am new to Linux operating systems. I did at one point mess around with Linux Mint && Peppermint (which probably explains why I love LXDE). I quickly grew bored...So, it was short lived and I reverted back to Windows. About 6 months ago I decided I wanted to further my knowledge in Linux...mostly because I had been rooting and messing around with ROM's on Android phones. I did my research around the internet and decided that I'd go Arch because I read somewhere that there's two approaches to learning Linux...'Slow and steady' or 'Here you go'...I think you learn quicker in a more volatile environment because you always second guess and of course read read read read read read (It's a good thing I like reading...thank you for the support in the forums as well as the wiki)....What I'm getting at is what makes Arch different to other distros? I know that pacman is a wonderful package manager but, I don't know how. What makes it different? Can you explain this to someone that has basically only ever used Arch?

    /dev/zero wrote:
    dazemc wrote:What I'm getting at is what makes Arch different to other distros?
    I came to Arch for several reasons:
    I noticed that every time I googled a Linux problem, the Arch Wiki came up as the top answer;
    As a bleeding edge distro with lots of packages in the AUR, Arch has the best support for new hardware - I could not get my laptops to work properly with other distros, but with Arch it was always a piece of cake;
    When I needed support, I found the forums friendly, useful and timely;
    I liked the hacker-friendly KISS philosophy.
    You mention the package manager, but that was never really high in my considerations. Overall, the deciding factor was necessity (to make hardware work and to have better access to newer software that I need); the active community and hacker-friendly philosophy were nice bonuses that convinced me to stick with Arch even when it's not really necessary to have such a bleeding edge distro.
    I have to agree in one way, "...the package manager, but that was never really high in my considerations..."
    I don't care about the package manger to be honest...The comunity behind Arch is the most complete and comperhensive I have seen yet...Coming from a 'newb' start...I find the wiki along with the AUR more helpful than any other distro I have found...I thank you all for that and I'm doing my best to return the favour...I.E. helping out in the forums

  • Suggestion for new package management scheme

    As was talked about in the INCOMING thread, Arch is growing and the devs are having trouble keeping up with maintaining packages. Arch is becoming disorganized and messy.
    Well, Xentac and I were discussing this for a while, and we both seem to like a voting system. Arch shouldn't try to maintain every package out there, it's simply a waste of effort. If only one or two people want a package, they can build it themselves, it's not hard with ABS.
    Arch devs should focus on keeping packages high quality, up to date, etc. They can't do this if there's 10,000 packages. So the solution would be that a package won't be included in the official repos (current, extra, unstable) unless it gets a certain number of votes, showing that lots of people really want the package, and it's "essential".
    I don't know how many votes a package would need, but that's a little thing. I would suggest all packages in Extra/Unstable initially go up for this voting (once we implement it) and we make the vote quota be a little lower for this initial slimming, and that'll cut down the repos right there. All those packages that no one uses (that wont even get one vote) can be cut away. People can always vote them back if they become popular.
    I don't want to have to do things like KDE, GNOME, etc myself, but I really don't mind maintaining my own little customizations, like Rhythmbox w/ XINE support (instead of Gstreamer). This vote system simply makes sure that a package is worth the developers time.
    This goes with my idea of Arch as the perfect "Base" distro. People can build what they want on top of it.
    This idea would also remove STAGING, as Arch wouldn't be accepting outside packages (though you're free to run your own repo or post PKGBUILDs on the forum). TESTING would be still used of course.
    Suggestions?

    beniro wrote:
    I haven't really seen a single post in this thread that is without some merit, or at least an attempt at input.
    The great thing about not being a larger distro is that the situation isn't as pressurized.  Still, though, we (meaning the community AND developers) still obviously want Arch to be the best it can be and that's what this thread is about.
    So...are any of the ideas mentioned here feasible?  What do you think would be the best solution to creating a package release system that can handle Arch's current growth?
    What about implementing a vote-based system for everything not in current?  Would this be done with a web-based interface by using "submitrequest/vote" or something...obviously only registered users should be voting, right?
    Anyway, I think a great job is being done and this thread is simply a positive indication of the vitality of the community.  I think most of us fully recognize the resources of our developers and are simply wanting to find a way for them to bring us the best possible product.  Arch rules!
    I agree. I think what we should do is just take this time that we have while Arch is still young and not as well known among the Linux community, and try to make it great, relieving the pressures that we'd get a lot of later (not to say that we wouldn't get any, just less, hopefully).
    As for the package setup, isn't there some way that we could write some system to do this? I had mentioned it before. And, I just came up with a small system. It would work like this:
    We get one main server, whose "job" would be to create and store packages, and users could download from that server to install, etc. Now, whenever someone on the package management team finds an updated version of a package, they could log in to a special area of the site meant specifically for those developers. Then, using the special program on the website/server, they could link to the .tar or .bz2 that contains the source and submit it, along with the file's information that would be included with the package when you install it (file name, version, etc.) into the web-based form. Then, they click submit, and the server processes that file after downloading it, runs a makepkg-type thing on it, and stores the produced package in a "Fresh" repository. Then, the developer can download the file and opt to test it. If they're sure that it's okay, then they can replace the new file over the old one.
    Just an idea, tell me what you think... :?

  • Package management

    As far as I can see, 5.10 does not provide any new package management tools besides pkgadd/pkgrm.
    This is an area where Solaris could really be improved.
    blastwave.org/pkg-get is ok, but I what if I want to update bundled packages like SUNWapch*?
    I may, for example, want to use the bundled packages for apache instead of csw, which installs everything under /opt, and is not compatible with the zones model which needs configuration state in /etc and data in /var
    The only way to get hold of freshly updated SUNW packages (unless I am missing something) is to download .iso images via Software Express and extract them manually.
    How about something similar to apt-get for native SUNW packages? Or at least the ability to wget the latest packages.
    Please tell me I am an ignorant ape and there exists just such a solution.... ;-)

    True ... the package management system "amazes" me.
    I'm looking to install a few standard packages on a remote server but don't have a cd in drive ... where else online can i find those packages (like SUNWppror, SUNWpprou, and SUNWppro-plugin-sunos-base needed for smpatch)
    Thank you.

  • Not a single package manager GUI?

    There is not a single package manager GUI for archlinux. The one provided in community repo jacman is quite unstable and the gtkpacman in aur can even search packages.
    How about porting http://www.packagekit.org/index.html to archlinux.

    Phrodo_00 wrote:yes I was thinking about you and the couple of packagekit topics that have appeared... and not thinking as seroius intentions from arch, but from, you know, some guy, you seemed pretty decided in that post, looks like I was wrong then... anyway, now that I know you aren't really interested and I'm starting vacation at university (and starting to work in a job if I can find one) I might aswell start taking a look at libalpm (why is it called like that?) and packagekit and see if I come out with something.
    From http://www.archlinux.org/pacman/ :
    As of version 3.0, pacman has been lib-ified, with a backend library named 'libalpm' (Arch Linux Package Management). Speed in some cases has been improved, and this should allow us in the future to speed development of alternative front ends.
    EDIT: however, some other guy nicknamed tradiaz said he was going to do it, not a lot about him has been heard though.
    There are two recent commits from him, you can see them in gitweb for example :
    http://gitweb.freedesktop.org/?p=packagekit.git
    (look for alpm and the date of today)
    But it looks far from complete if the table on the faq is uptodate:
    http://www.packagekit.org/pk-faq.html

  • Smart Package Manager

    Howdy all, I was asked to create the archlinux backend for smart package manager and I am making good progress.
    For right now, it will not include support for the AUR, though I am planning that for the future.
    smart forum post
    smart homepage
    launchpad branch
    my blog post
    Current issues at hand:
    08/02/08 - smart's builtin fetcher object not fetching db files, so Ill have to create a custom one.
    08/02/08 - no pkgbuild atm - will not be released until everything works
    comments/questions/suggestions welcome
    EDIT: my site is back up
    Last edited by platinummonkey (2008-08-04 02:23:46)

    skottish wrote:It's been a few years since I've used the Smart Package Manager, but I do remember that when I came to Arch I couldn't believe how much better pacman was. But, as I said, that was a few years ago. My question here is, how can Smart be better than pacman for Arch? (This is not a sarcastic question, I really want to know.)
    It really has to do with the algorithm. For me to explain that, would involve getting into the python code. I am a novice at python, so explaining all that would be a bit over my head. The same could be said of rpm or dpkg or any other. See, over the years there have been many package managers, and the evolution of package managers. Each have their own benefits, but they all were just overlays of the systems package management, and really didn't deal with the issue. That has historically been left up to, in the case of rpm, rpmlib and the packager. rpmlib is called upon the check provides, requires, depends, and obsoletes, and ofcourse this is all the job of the packager to properly handle those. So now enters smart on the scene. Smart changed all that by changing the algorithm, and part of it involves reordering. It's an rpm option, that is generally unknown and not used. Smart does allow you to turn off the algorithm, in which case it becomes just another overlay for the systems package manager.
    I started out with Slackware 7.1, and have used a variety of rpm distros, but have also used a few deb distros. I have also done Sabayon Linux, so I am familiar with portage as well. I was called up, some time ago, to code the backend for ArchLinux. So I read up on pacman. Lots of config options. A truly nice tool. I, however, found platinummonkey, who had more experience at python, and was already familiar with ArchLinux. So I introduced smart to him, and asked him to code the backend.
    I continue to study python, but until I get a whole lot better at python, and learn C, this is as far as I can explain the algorithm. Actually, I have my hands full. I'm learning Glade, GTK+, python, and pygtk, all at once. I do realize Glade is a RAD. Glade itself isn't hard. It's knowing GTK+, which is funny since knowing GTK+ requires knowledge of C. So I'm in deep.
    Feel free to review the code. http://bazaar.launchpad.net/~smartpm/smart/trunk/files

  • Using a package manager w/o root access

    I do a lot of scientific programming at work on different servers with out of date CentOS repositories and without root access. To get the libraries I need and to keep them up to date, what I'm doing now is compiling every program I need from source on every computer I use, and never updating the software.
    Is it possible to a package manager to operate in $HOME without root priviledges? For intsance, could I install yum (CentOS package manager) into $HOME or, even better, install pacman into $HOME and pull and update software from Arch repos into my $HOME directory? Or has anyone run into this problem and figured out a better way to install and update software?

    pacman has a --root <path> option. Try that (I haven't).
    Also, I don't know how you or the admins would feel about this but if you've got physical acces to the machines, anything is possible.
    Specifically, you could use a Linux LiveCD to mount the root partitions of said servers and reset the root passwords (in /etc/shadow).
    A less drastic approach would be to add your user(s) to /etc/sudoers with an entry like this
    Username ALL=(ALL) NOPASSWD: /usr/bin/pacman

  • [ABANDONED][Project] Wakka: A Gtk-Based Package Management Tool

    ==Summary==
    Wakka is a loosely-GtkPacman based package manager, designed to cleanup the design of GtkPacman as well as the user interface, and update it to the latest and greatest releases of Python and pyGtk. It was originally developed as a project to make GtkPacman more stable on my own system, but I realized that many other users had the same problems that I did, thus the public release.
    ==History==
    I found GtkPacman when I first came to Arch in 2009, being the GUI loving Ubuntu convert that I was, and I noticed that the last release had been in February of 2008, with no updates since, and no indication that the project was ongoing. Being a budding (and overconfident) Computer Science student I decided to take on the task of forking and maintaining this wonderful piece of software for the community. Yes, I could finally give back! Little did I realize that the task was far beyond my skills to accomplish.
    I quickly found that cleaning this thing up enough for my own use was hard enough, and getting a decent realease out and dealing with bug reports and such would be neigh on impossible. It also didn't help that I had no idea what the heck pacman was doing in the backend, since apt and Synaptic were my only prior experience with package managers.
    So there I lost steam, but from time to time I would open the code up and peck away at it, modifying bits here and there to work the way I wanted, but I eventually just took to the command line and lost sight of old Wakka. Well, just this last week I stumbled back upon it, and with my newfound pacman-fu and python-jitsu (not to mention free time) I decided to tackle this beast once and for all. I may not keep it up to date when I'm finished, and I may not even use the thing, but I'm going to clean this monster up and make it faster, more stable, and most of all more elegant (have you looked at the code for gtkPacman? It's not very elegant).
    ==Installation and Use==
    You can now install Wakka from the AUR, but if you still wish to download and try other versions, you can grab a source tarball of any release from the project page on google code or get the newest stable release from the link below. You can also grab the bleeding edge (sometimes broken) svn code as well, but it's not useful for much other than development purposes.
    Basically, unless you're going to dig through the code, use the AUR version, it's the safest.
    ==Files==
    Pkgbuild: http://aur.archlinux.org/packages.php?ID=47037
    Project: http://code.google.com/p/wakka-package-manager/
    Source: http://wakka-package-manager.googlecode … .4.tar.bz2
    ==TODO==
    - Speeeeed it up!
    - Streamlining
    - Bugfixes
    Not particularly in that order, depending on the circumstances.
    Last edited by minasmorath (2012-04-12 18:22:08)

    swanson wrote:Just did a daily update/upgrade and it worked very nicely indeed! All events present themselves clearly during the process. For me, as new Arch user, it is very nice to get a list of all available packages in the repos. The overview and search capabilties are handy, much more so than doing pacman -Ss "xxxxx" in terminal.
    I'm glad you like it!
    pablokal wrote:when you install something the sizes are not given of the packages to be installed (also the sizes of the dependencies); would be nice if these sizes were given, just like in pacman.
    I didn't even notice that, I'll add it asap.
    pablokal wrote:Second when installing by default the terminal is closed.
    I don't know about opening it up, but you're right, hiding things is bad practice, so at least a summary and a more clear indication that stuff is going on.
    tomd123 wrote:can you provide a PKGBUILD in the aur?
    Hopefully I can get the PKGBUILD up in the AUR within the next week, but I won't post it until everything is ported to Python 3 and I've done thorough testing. I also have a couple minor changes to make along the way, I don't like the way the update all button works right now, I'm changing it so that it just marks all changes in the install queue and alerts you of the packages to be updated, and I need to fix the 'required by' section of the package summary, since it uses an old method, and dependency size display.
    All in all as soon as it's cleaned up I'll post it. I'll be going on spring break here in a week as well so I'll have plenty of time to work on it this week and next.
    Thanks for the input, I'm on it!
    Mitch

Maybe you are looking for