Talk:Package management system

Mac OS X installer needs mentioning!

Mac OS X does have some package management functionality (an installer and a software update utility), which should be included here. - Samsara (talk • contribs) 13:04, 15 March 2006 (UTC)

From RPM Package Manager

Related tools

RPM is often used by another tool for handling dependencies, such as the Yellow Dog Updater Modified (yum) or the RPM-based version of the Advanced Packaging Tool (apt).

Some other package managers are

• dpkg used with Advanced Packaging Tool (apt) in Debian GNU/Linux
• portage used with emerge in Gentoo Linux
• Encap Package Management System
• cygcheck used in Cygwin

The following tools are simply front ends to RPM-based systems:

• YaST used in SuSE
• urpmi used in Mandriva Linux
• yum used in Yellow Dog Linux and Fedora Core.

In addition, the advanced dependency-management system in APT has been ported to work on RPM databases as apt4rpm.

See also: Archive formats

- Samsara (talk • contribs) 18:44, 25 April 2006 (UTC)

Suggested merge of Package management system and Installer

Mostly I am suggesting the merge to force a clarification of what each article is about. Some of the material in Installer belongs in this article, and some material that clearly belongs in Installer is simply absent. klik would be an example of an installer mentioned in the PMS article. - Samsara (talk • contribs) 20:59, 4 May 2006 (UTC)

Installer != Package Management System

These two pages should not be merged. A package management system does install programs, but it also checks dependencies and installs those which are required by the program being installed, according to the preferences and command line choices made by the installing user. Most installers, on the other hand, assume that the user's system already has the required libraries or programs the program being installed requires. This is especially true in the case of Windows installers. Some well-written installers do check, usually exiting if the libraries are not found, but most will only mention what is needed. But the inclusion of the functions of checking dependencies and downloading required libraries would, in my opinion, make an installer into a package management system. It might be argued that this makes a package management system a subset of installers, but I think they should still have separate entries to avoid confusion.

If you'd written that as a clarification on a merged page, it would be more useful. Not that it was news to me... And, following your proposed definition, it would seem that several examples are currently misclassified. - Samsara (talk • contribs) 20:36, 9 May 2006 (UTC)

I'd have to agree with the Installer != PMS. Here is my reasoning, let's see if it's bad. When I think installer, I think of a self contained EXE file that I can download and double-click, which will run it's included executable to move files from the executable into the directories where they need to be. An installer contains not only the program, but all support libraries as well. The installer checks to see if you have the support libraries installed, if not, it installs those libraries. A Package Management System, however, is separate from the actual program being installed. (My experience is with emerge from Gentoo and apt-get from Debian) You use the PMS system's program to download a separate package, then follow the instructions in that separate package to install that package. Should that package need support libraries, the PMS can download those as well; however, the program being installed DOES NOT contain it's own copies of the libraries like a Win installer. It depends on the PMS to get those for it.

So, in summary, to ME, a Installer is a program that contains within itself the program to be installed and it's support libraries. In contrast, a PMS is a Utility that gets the program to be installed as a completely separate file, and can retrieve any libraries the program to be installed needs as completely separate files. The difference is between WinampInstall.exe and apt-get(+x) + XMMS.deb + Mp3.deb + ... Autodmc 16:42, 25 May 2006 (UTC)

I didn't want to get dinged for not providing sources for my statements. And I didn't have time when I made the comment to properly research it. Skreyola (talk) 04:26, 4 January 2008 (UTC)

Agreed. Installers are mostly stand-alone, I-don't-care-about-other-software programs. Package management systems handle installers, dependencies, etc. æle ✆ 2006-05-27t14:13z

Installers are mostly

Guys, can we have clear definitions, please?! - Samsara (talk • contribs) 20:25, 27 May 2006 (UTC)

I'm trying not to generalize, because some programs blur the line a little bit (see the Cygwin installer; it also manages Cygwin packages). æle ✆ 2006-05-28t02:19z

If this page is to be just a list, it should be so renamed or nominated for deletion. I think it would be a shame, because there actually are general principles to discuss here that haven't yet been touched on. - Samsara (talk • contribs) 08:59, 28 May 2006 (UTC)

Gah, I was writing that late last night. I meant "generalize too much", in the sense that there're always exceptions to any rule. æle ✆ 2006-05-28t13:02z

Comparison of package management systems

I think it would be nice to have a comparison table that outlines features of various package management systems. —The preceding unsigned comment was added by Kc8tpz (talk • contribs) 20:32, 22 January 2007 (UTC).

This is a cool idea. One issue is redundant information. Each portal wants its own specific information, e.g., the Linux portal doesn't want to see everything about Windows and Mac managers. Also, the grouping is a bit odd. The core fields would include name, platform, package formats managed, what package managers are 'under the hood' and a list of features: GUI, command line, creating packages, managing multiple machines, and so on.--Charles Merriam (talk) 21:21, 27 December 2007 (UTC)

Windows PMS

1. [...] whereas the PMS of Mac OS X and Windows will only upgrade software provided by Apple and Microsoft, respectively [...]

   What, if any exists, is the official Windows PMS? --Abdull 09:39, 5 July 2007 (UTC)

   Windows does not, to my knowledge, have anything resembling a PMS, because Windows is designed on a single-user model, and PMSs are generally found in multi-user platforms. MacOS is an exception. Skreyola (talk) 04:22, 4 January 2008 (UTC)

2. Appsnap link comment edit Gert4gt (talk) 02:22, 18 November 2007 (UTC) someone can add that back in if they can add a link to backup the "most advanced" claim. I couldn't find anything to back that up. Sorry.
3. Regarding the linkfarm template in the Windows section:

   As I note in a comment, since none of these are official systems bundled with Windows, people might not be familiar with them, and since individual software is not necessarily likely to have a Wiki page, linking to them directly does not seem unreasonable. All of these links seem appropriate to the article. I recommend removal of the linkfarm template. Skreyola (talk) 05:46, 4 January 2008 (UTC)

diagram

What does the diagram achieve that a numbered list (inline with the text) wouldn't? Is it meant to imply a cycle? Also, the "typical" manual action of requesting a reboot, is quite atypical except on Windows. (That example just perpetuates the myth that it's normal for computers to need to get rebooted every time some dumb screen saver is installed). —Fleminra 23:43, 10 October 2007 (UTC)

I agree. A screenshot of a GUI package manager, like Synaptic, might do better at conveying the core idea. --Charles Merriam (talk) 21:15, 27 December 2007 (UTC)

How about a screenshot of aptitude? (Sorry, I don't have Synaptic installed at the moment). Skreyola (talk) 05:55, 4 January 2008 (UTC)

• Please, don't shrink it, there is no sense in unreadable text-mode screenshot --pavel.

I would like for someone to explain to me what magical advance in software engineering Linux made that reboots are not necessary after you've just overwritten half a dozen shared libraries, while running processes are using them. It is not a myth, and unless you can point out some magic I'm not aware of, you DO have to reboot a Linux system after updates to ensure a consistent state. I'm sick and tired of Linux getting credit for these incredible feats of engineering when all you do is shrug something off. Linux will someday wind up with a system similar to either Windows (files overwritten at reboot) or OpenSolaris IPS (updates installed to filesystem snapshot, snapshot promoted at next reboot) to provide consistency, and all the Linux community will do is pretend it was never an issue. Patching Solaris, Windows and other commercial systems is a little trickier than Linux, but stop pretending your Linux system does anything more advanced than blindly overwrite files. Face the issues, or you'll be left behind. Linux isn't perfect. -SMJ —Preceding unsigned comment added by 216.136.25.72 (talk) 02:21, 8 July 2008 (UTC)

As I understand it, it's because of the way Linux executables use libraries. You don't normally have to reboot the whole system, just the processes that use the updated libraries, and that only if those processes are going to keep running indefinitely. Linux isn't flawless, and I don't know anyone who says it is. But to pretend that Linux is not a stable system that can run for months without rebooting is silly. I only reboot my server when I install a new kernel or change hardware. But this is probably not the right place for such a discussion. Skreyola (talk) 16:31, 21 September 2010 (UTC)

That opinion was said more than two years ago, I think that article has already reflected the facts you're basing your point of view upon. 1exec1 (talk) 16:07, 22 September 2010 (UTC)

A cloud of articles

I spent some time cleaning up, and possibly making some sections worse. :). There seems to be an odd cloud of related pages of varying quality, from the individual package managers, installers, and general terms like software distribution. What would be a good 'master' article that talks about the whole system administration of installed software that can put all this in perspective to a person with only a general understanding of computers. It just feels like the cloud is wrong. Any ideas?--Charles Merriam (talk) 21:25, 27 December 2007 (UTC)

More sections: History; How does it works.

Does anyone know the history? It probably makes a difference.

Also, we should have some sort of How Does It Work section and diagram. The diagram might have the software repository, package manager, internals of a package, the local package database, and some directories. Showing how a user contacts a repository, selects a package from the description, gets prompted to download dependencies, downloads to local machine, unpacks into local directories, and updates the local package database might be good. Hmmm..... --Charles Merriam (talk) 21:35, 27 December 2007 (UTC)

Not an essay any more...

I looked at this, and think it doesn't look like an essay anymore. Still needs a history, and an "example of how it does it" section.

The reference updates

Hello - I've upgraded the formatting of the references. This includes verifying that the links are still active. Sometimes over time they become dead links. Standard reference syntax has the "retrieved on" date as the original viewing date. My changes have that date as the most current viewing date. This helps Wikipedia editors see, at a glance, when that page was last verified as active. E_dog95' ^{Hi '} 14:23, 7 April 2008 (UTC)

The Terminology table

Terms on the table are wrong. None of the Linux or *BSD package manager systems belongs to operating system. They are just like normal applications running top of operating system. The article information is wrong and is mistaken by typical conclusion and not for computer science. The package management system is just a set of tools and can be removed totally if wanted, it just comes preinstalled on software system and belongs usually to system programs -level, what is top of OS -level. This might not be the case of Windows NT, where even the browser was/is part of OS because it is integrated to it, so the package management system might be part of OS. Golftheman (talk) 11:55, 1 December 2008 (UTC)

You are right, it is just software. For instance, Gentoo is known for portage, but portage can also be used on Macs. Sockigami (talk) 19:31, 14 February 2009 (UTC)

Package management system versus package manager

I know the difference between an installer and a package management system; this does not concern that. But at the top of the article it says "a package management system is sometimes incorrectly referred to as a package manager or a system install manager." A package management system and a package manager are the same thing. RPM is called the "RPM Package Manager," and is a package management system. I'm taking the part that says it's incorrectly referred to as a package manager out. Sockigami (talk) 19:28, 14 February 2009 (UTC)

Recent revert

This edit made the article internally inconsistent, using the terms "Linux" and "GNU/Linux" interchangeably. This is confusing; we should use one or the other. It should be reverted. Chris Cunningham (not at work) - talk 18:19, 2 March 2009 (UTC)

Article name

Why does this not live at package manager? —Wiki Wikardo 19:38, 23 February 2010 (UTC)

WPM (Windows Package Manager)

please consider adding a link to http://code.google.com/p/windows-package-manager/ 62.153.127.78 (talk) 10:56, 8 July 2010 (UTC)

GNU Stow

Any reason why this has it's own special link in See Also and can it be removed to List of software package management systems, perhaps the Linux distributions section? Teh klev (talk) 14:03, 10 November 2010 (UTC)

Ian Murdock about package management

In 2006, he said it sucked, but hopefully not for much longer. His recent blog post where the "Impact" article section was taken from stated his reasoning for thinking it was a lot better now was that:

These days, you increasingly just “apt-get install whatever“.

Debian-based distros coming to be used more is good for standards? That's not a solution or standard, that's everyone choosing one thing. Package management still sucks in that there still isn't integration with software management systems for "third-party programs" essentially, and ISVs are still facing the exact same problem of needing to support many distros. This latest blog post of his didn't address any of the problems and points he made in those two earlier posts. Thus, I think his earlier comments about package management sucking on Linux should also be noted, or that "Impact" section completely removed. I also think a section on fragmentation and a lack of packaging standards (especially between Linux distros) is needed. Yfrwlf (talk) 01:03, 2 January 2011 (UTC)

Personal POV has no place in Wikipedia.
1) Package management still sucks in that there still isn't integration with software management systems for "third-party programs" - Bullshit. Noone (including Google, Oracle, Skype to name a few) has any difficulties packaging their software for Linux distributions.
2) fragmentation - According to this report more than 60-65% of desktop Linux users use Ubuntu + Debian distributions (which in turn use deb package format) and additional 10-15% use Fedora + SUSE (rpm package format). I don't see fragmentation issues here.
3) lack of packaging standards - are you living in the previous century? Making deb and rpm packages already covers more than 99% of Linux market.
1exec1 (talk) 16:04, 4 January 2011 (UTC)

You could add the comments by Tony Mobily about how software installation on GNU/Linux is still broken. Yfrwlf (talk) 01:31, 2 January 2011 (UTC)

Merger proposal with Application Packaging

Isn't Application Packaging covered under Package management system? If so, I propose a merge. A redirect could be more appropriate, if all the content is already covered here. -- Trevj (talk) 11:53, 25 November 2011 (UTC)

I'd say no, although from the article it's quite unclear what Application Packaging is supposed to cover (it includes Installers and some Systems/configuration management software I'm not familiar with). It seems to be wider in scope than what are traditionally considered package management systems. Perhaps Software package (installation) would be a better target? Or maybe it could be developed into a proper stand-alone article? —Ruud 12:44, 25 November 2011 (UTC)

Yes, package management systems are more specific. Some further thoughts:

1. "Application packaging" means building an installer. I suggest merging it to the more general article Installation (computer programs).
2. It's kind of strange Installer isn't an article.
3. The second list in Application Packaging are tools for managing deployment of packaged applications. Contrary to what the lead sentence says, managing deployment is related to application packaging, not part of it.
4. Software package (installation) is about packages in package management systems.

--Pnm (talk) 19:33, 25 November 2011 (UTC)

I don't agree with a merge, as an application package may or may not integrate with a package managment system. (eg. klik, RUNZ) --SF007 (talk) 05:05, 15 January 2012 (UTC)

*System*

What is this here, and what is not the relationship to SCCM (its software distribution module)? --Alien4 (talk) 12:17, 16 May 2014 (UTC)

Hello there! Well, "package management system" is pretty much a general term, while SCCM‍—‌I suppose‍—‌contains a Microsoft's specific implementation of such a concept. — Dsimic (talk | contribs) 02:31, 19 May 2014 (UTC)

So you would say, there is a connection between the two, but no obvious relationship (intrawikilinking or so) between them in the Wikipedia? There are tons of mentionings of *nx, whereas Windows just a few. Or maybe I'm confusing something; although I maybe rather would consider msi a package management technology, it is mentioned here, whereas a software (package) managment *system* like SCCM is not. Or maybe I'm just too completely confused. --Alien4 (talk) 14:59, 19 May 2014 (UTC)

I'm completely unfamiliar with SCCM so unfortunately I can't draw any conclusions, but I'd say that SCCM might fit better into the Systems management article, while SCCM's specific components might be mentioned in Software repository article. — Dsimic (talk | contribs) 06:47, 20 May 2014 (UTC)

With SCCM you can do software deployment (or software distribution, whichever expression you like best), and you can do that also with msi, App-V packages or others. In other organisations it might be different, but I know it best as that beeing the main functionality of SCCM. Which leads me to conclusion, although it does system management - S stands for "System", (CC), M stands for "Manager" - and personally I might maybe rather regard a combination of SCCM with a version control system like ClearCase as a software repository (maybe i confuse that with a Definitive Media Library), a software (package) deployment/distribution (system) (module) seems to be a lot like a "package management system" to me. But then again, do I understand the package management system article right? You know, stuff like dependencies - expressis verbis in the article introduction - is stuff you can (also) do in SCCM, although they might be more high level dependencies: if you want to install an Office plugin, MS Office must be installed, but you don't put the dependend MS Office in the plugin msi; it might be a good idea however to define that dependency in SCCM. --Alien4 (talk) 10:34, 20 May 2014 (UTC)

Hm, can SCCM automatically handle dependencies and install required packages? For example, when you try to install a software package which requires Visual C++'s redistributable runtime, is SCCM going to locate and install that runtime package despite the fact it isn't contained within the original software package? — Dsimic (talk | contribs) 06:42, 21 May 2014 (UTC)