Why write a new package manager anyway?

Posted Jan 17, 2014 16:16 UTC (Fri) by etienne (guest, #25256)
In reply to: Why write a new package manager anyway? by johannbg
Parent article: DNF and Yum in Fedora

Maybe writing down the list of thing that a good package manager should do, making a library, and one (or more) graphical user interface for user convenience is the way to go:
most package manager lack something...

Even the list of thing to do is complex to describe:
- capture the full list of dependencies automatically, at compile time (by looking which include files are used, and which library are linked-in, and what versions) - depending on the configuration selected for the package itself.
- install all dependent packages when the user install an application
- remember which packages have been installed automatically and remove them automatically when they are no more needed
- when a package is uninstalled, magically decide if the dependencies which have been upgraded by the install should be downgraded
- detect which package has never been used (newest access time of any files in the package) when a user ask for it
- detect/disallow two package using the same (configuration) file, even if this file is the obvious place to change that parameter
- manage any "plugin" which have to be upgraded after a main application has been upgraded
- manage interpreted languages: upgrade python/java/... libraries without creating a package version containing the whole thing
- display the dependency graphically so that a user can understand where a problem comes from (dselect is not that appealing)
- display some information about a package without having to install, and classify packages in a way a user can find what he needs

I have probably missed some requirements.

Why write a new package manager anyway?

Posted Jan 17, 2014 21:36 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (5 responses)

> when a package is uninstalled, magically decide if the dependencies which have been upgraded by the install should be downgraded

Do you have an example of this? It doesn't seem obvious to me.

Why write a new package manager anyway?

Posted Jan 20, 2014 10:29 UTC (Mon) by etienne (guest, #25256) [Link] (4 responses)

>> when a package is uninstalled, magically decide
> Do you have an example of this? It doesn't seem obvious to me.

If the user uninstall a package because he does not need it, then the dependent libraries shall be kept (it is better to use up-to-date software), but if a user uninstall a package because there is a regression - then the package manager shall guess if the regression is in the package itself or in one of the dependant libraries pulled by the main package, that is the automagic part.

Why write a new package manager anyway?

Posted Jan 20, 2014 12:42 UTC (Mon) by mpr22 (subscriber, #60784) [Link] (3 responses)

Making that work halfway reliably sounds halting-complete.

Why write a new package manager anyway?

Posted Jan 20, 2014 18:50 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (2 responses)

Worse. In the halting problem you know what behaviour to look for; here you haven't got the faintest clue (Is it slower? Now crashes with <random file>? The screen shows strange colors?).

Why write a new package manager anyway?

Posted Jan 20, 2014 23:50 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Maybe different subcommands "remove" and "revert" could help here? This really actually sounds like "yum history undo" to me… Good luck making a good UI for it and explaining to the user what is happening and the difference :D .

Why write a new package manager anyway?

Posted Jan 21, 2014 17:45 UTC (Tue) by nix (subscriber, #2304) [Link]

Quite. This is a telepathy-complete problem. (In some cases I suspect it may be precognition-complete.)