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)

Similar Messages

Filesystem abstraction in package management

Hey all .. just a thought I had the other night, wanted to share and get opinons on it.
Probably not anything new, but I was wondering why some kinda filesystem abstraction layer couldnt be implemented in a package management system such as libalpm/pacman ? For instance, instead of storing information as 'absolute' directories, one could store data such as $appdir or $bindir or $libdir, so on and so forth. Information as to where that points to is stored in the config files locally, for any particular distro.
Potentially one particular dev could package a tarball containing a PKGBUILD with info as to how to build & install the software, along with dependencies, and then locally the package management system takes care of installing everything in the right manner, building the source with the right tools / configurations if needed.
Im not sure if im explaining this right, but anyway, let me know what you guys think. Maybe there are other factors in play that prevent something like that from being implemented. i dunno ?

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)

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

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

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)

Pcurses - a curses package management tool

pcurses features package browsing and management in a curses frontend written in C++
Features:
* regexp filtering and searching any package property
* customizable colorcoding
* customizable sorting
* external command execution with package list string replacements
* user defined macros and hotkeys
Package management is done through external command execution: for example, '!sudo pacman -S %p' will install all currently queued packages.
For more information, read the README file at github and take a look at some of the defined macros in /etc/pcurses.conf.
Default hotkey mappings:
1 - filter packages with updates available
2 - filter installed packages
5 - run pacman -Syu
6 - run pacman -S on the current contents of the queue
7 - run pacman -Rs on the current contents of the queue
These macros are entirely customizable and are defined in /etc/pcurses.conf.
The default view optimized for 80x24 terminals:
And a 3 pane view for larger terminals:
Get it here: http://aur.archlinux.org/packages.php?ID=42685
Or, if you are using pacman-git: http://aur.archlinux.org/packages.php?ID=50804
Github: https://github.com/schuay/pcurses
Old thread from Nov 2010: https://bbs.archlinux.org/viewtopic.php?id=108585
For now, documentation is located mostly in the README file.
Keyboard commands are displayed by pressing the 'h' key in pcurses.
Last edited by schuay (2011-07-18 13:54:05)

Reposting the full tutorial from the README file:
QUICK TUTORIAL
Navigation and queue management
The package list and queue can be navigated using the up/down arrows, page
up/down, and the home and end keys. The tab key switches focus between the
package and queue lists.
Adding packages to the queue is done by pressing the right arrow key while the
package list is focused. Left arrow removes the selected package from the
queue.
Filtering
Keybindings are displayed by pressing the 'h' (Help) key in pcurses.
Filtering takes the following syntax:
nd:game 1 23
1 is a list of field specifiers. These tell pcurses which fields to search.
Field specifiers are the highlighted characters in the field names in the info
pane. In this example, this means that the Name and Description are searched
for the phrase 'game'.
2 the character ':' separates the field specifier list from the search phrase.
If this character is not present, the entire string is interpreted as the
search phrase.
3 is the actual search phrase. If it contains only alphanumeric characters, a
simple and quick string search is used. Otherwise, it is treated as a regular
expression (which is a bit slower). The search is case INSENSITIVE.
1 and 2 are OPTIONAL.
These searches can be chained. This means that a search for 'n:^a', followed by
'b:2010' will show all packages beginning with the letter 'a' and having a
build date in the year 2010.
Previous filters are cleared by pressing the 'c' key.
Pressing the up and down keys while in input mode will scroll through all
previous history.
Sorting and colorcoding
Colorcoding and sorting use the same syntax as filtering, but only accept a
single field specifier.
Command execution
Command execution can be entered by pressing the '!' key. The token '%p' will
be replaced by the current contents of the package queue. For example, with a
current package selection of pcurses and pacman,
!sudo pacman -S '%p'
will be expanded to
echo 'sudo pacman -S pcurses pacman'
A few useful commands could be
!pacman -Sy
!sudo pacman -S %p
!sudo pacman -Rs %p
Macros
Macros are defined in /etc/pcurses.conf using the syntax 'macroname=command'.
Macros can be chained by separating them with a comma. A few examples:
sortbyname=.n
colorbyrepo=;r
filterupdates=/d:update available
chainedmacro=@sortbyname,colorbyrepo,filterupdates
If defined, the macro named 'startup' will be executed on each application
start. Hotkeys can be defined by creating macros named '1', '2', [...], and are
triggered by pressing the corresponding key in pcurses.
All macros can be executed in pcurses by pressing the '@' key and entering the
macro name.
Last edited by schuay (2011-07-18 13:50:37)

Visual Studio 2013 Nuget Package Manager error

Hello everyone,
I tried to add and use OpenCV library in my Visual Studio javascript windows application project, but I still get the same error.
This is my Package manager console:
PM> Install-Package OpenCV
Installing 'OpenCV 2.4.8'.
Successfully installed 'OpenCV 2.4.8'.
Adding 'OpenCV 2.4.8' to BlankSharedApp1.Windows.
Uninstalling 'OpenCV 2.4.8'.
Successfully uninstalled 'OpenCV 2.4.8'.
Install failed. Rolling back...
Install-Package : Could not install package 'OpenCV 2.4.8'. You are trying to install this package into a project that targets 'Windows,Version=v8.1', but the
package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
At line:1 char:1
+ Install-Package OpenCV
+ ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-Package], InvalidOperationException
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand
Thanks for answers.

Hi Fačko,
Normally, we won't get any errors if we create a new project. Since you get this error when using OpenCV library and it is a third-party product, I think you need to ask in
OpenCV forum for better response.
Thank you for your understanding!
Best regards,
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

System settings Package management part crashes on open

Hello all,
Whenever I open the system settings and then go to "package management" EVERY TIME the screen shows up and inmediatly closes and I get a KDE crash handler window.
Please note I am using KDEmod repos.
If I hover over the Package Management icon I get that it contains 2 items, which are "Aqpm global configuration" and "Aqpm databases configuration"
No idea of what could be happening, I checked and the package kdemod-aqpm is installed
Any more info you need just ask I will be around.
cheers

There'sa forum for kdemod here - you might get a quicker/better answer there.

Package Manager console failed to load

Last night I installed update 3 for Visual Studio 2012 professional (version 11.0.60610.01). This morning when I started the package manager console I received the following errors. I did a repair of VS but other than taking a long time
it did not fix anything. I also installed all the extension updates, no help either. The file mention below is where it should be and I can open it. Tried running in administrator mode, again no help. All three versions of power shell
seem to run just fine (64, 86, ISE). I am running Windows 8 on a 64 bit machine, all updates are installed.
Any suggestions on how to fix this one?
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2977) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2984) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2991) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2998) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(3005) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The term 'Get-ExecutionPolicy' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
John J. Hughes II
Ran Get-ExecutionPolicy from PowerShell (x86) it returns Restricted
Also looking around... I have on add-in installed or running
Also tried uninstalling nugget and reinstalling
I noticed on the NuGet website it calls for PowerShell 2.0. It seems I have PowerShell 3.0, could that be a problem? Can I install PowerShell 2.0/3.0 side by side, is there an update to NuGet?

Found the following link in stack overflow, added the suggested items to the VS exe config file and it works now without error.
http://stackoverflow.com/questions/12638289/embedding-powershell-v2-0-in-net-app-on-windows-8-rtm
Added the following to the devenv.exe.config file in the runtime section
<dependentAssembly>
<assemblyIdentity name="System.Management.Automation" publicKeyToken="31bf3856ad364e35" />
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.Commands.Utility" publicKeyToken="31bf3856ad364e35" />
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.ConsoleHost" publicKeyToken="31bf3856ad364e35" />
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.Commands.Management" publicKeyToken="31bf3856ad364e35" />
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.Security" publicKeyToken="31bf3856ad364e35" />
<publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.PowerShell.Commands.Diagnostics" publicKeyToken="31bf3856ad364e35" />
<publisherPolicy apply="no" />
</dependentAssembly>
John J. Hughes II

How to deploy EAR on CE server using Java Support Package Manager

Hello,
I am using CE server where I want to deploy EAR file by using JSPM. I run this program in Drive:\usr\sap\CE1\J00\j2ee\JSPM\go.bat
I have also put the EAR file into the inbox folder Drive:\usr\sap\CE1\SYS\EPS\in but still It does not show me any file to proceed further for deployment.
Does any one has idea?
Regards,
NK

Hi,
The Java Support Package Manager is not able to deploy a single .ear file.
If the *.EAR file is placed inside an SCA (Software Component Archive) then JSPM is able to deploy it.
You have to create a .SCA from an .EAR file
SAP note 1223957 contains an attachment (nwpacktool.zip) which can be used to create a .SCA file from the .EAR file.
Gerd

How to import all Support Packages simulteneily support Package Manager EBP

Can any body tel me how to apply all support package sumultanesoly by using support Package Manager EBP/CRM option in SPAM.
I could not able to select all pactche at a time.It selecting one patch at a time only
Regards
G Sasikanth Reddy

I solved my self by selecting highest level of patch so that its dependencies can also add to the queue.
Regards
Sasikanth Reddy

Support Package Manager for EBPCRM

Hi,
In CRM/EBP SAP systems there is used special 'Support Package Manager for EBPCRM' to implement Support Packages instead of standard transactions like SPAM/SAINT.
I'm trying to implement more then one Support Package into the system however this is probably not possible. It seems that it is not possible to create import queue with more then one Support Package? Importing SPs one by one is very time consuming task. SO that's why I'm wondering about this special tool.
Do you have similar functionality?
BR
m./

Hi Jose,
Yes I've put all the SPs into '\usr\sap\trans\Eps\in'. But 'Support Package Manager for EBPCRM' asks me for particular one while I'm going to import it. There is no such an functionality to use queue creation.
BTW: I'm on SAP CRM 4.0 on WIN/MSSQL platform.
BR
m./

Managing JAVA JDK and JRE with Package Management in Solaris 11.1

I want to manage Java JDK & JRE in an Solaris environment using Package Management I'm currently running Solaris 11.1 in a VMWare host. My current latest Java release is JDK1.7.0_07 and JRE1.7.0_07. I want to upgrade to JDK1.7.0_17 & JRE1.7.0_17 using Package Management. I've tried on several occasions to upgrade to latest release of Java but I have not been successful. Each time I try using the Package Management GUI or use command line they appear to be successful but the new release does not show.
What could I be doing wrong?
Thanks

I also learned that the READMEs for the following patches in My Oracle Support also describe the downgrave process:
Patch 18362676: JAVA 6 DOWNGRADE INCORPORATION FOR ORACLE SOLARIS 11.1.15.4.0 AND 11.1.16.5.0
Patch 18362686: JAVA 7 DOWNGRADE INCORPORATION FOR ORACLE SOLARIS 11.1.15.4.0 AND 11.1.16.5.0
-- Alan

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

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

Cheflex: a simple yet flexible package manager

Similar Messages

Maybe you are looking for