|
|
Subscribe / Log in / New account

Zimmerman: We’ve packaged all of the free software…what now?

Zimmerman: We’ve packaged all of the free software…what now?

Posted Jul 7, 2010 10:27 UTC (Wed) by mjthayer (guest, #39183)
In reply to: Zimmerman: We’ve packaged all of the free software…what now? by mjthayer
Parent article: Zimmerman: We’ve packaged all of the free software…what now?

Another funny thought that occurs to me would be to have the main packaging database on a system as a sort of meta-database. One could have a dpkg database on the system, and a Java environment in parallel (somewhere out of the way of dpkg), and the meta-database would be aware of all of them, and would be able to install or find software with a single command, automatically deciding which of the packaging systems was the right one.

After all, free software is all about choice, but the choice of packaging system currently tends to be rather all-or-nothing.

to post comments

Zimmerman: We’ve packaged all of the free software…what now?

Posted Jul 7, 2010 10:33 UTC (Wed) by tzafrir (subscriber, #11501) [Link] (1 responses)

What happens when Eclipse depends on gtk? Do we take it from the Java repo or from the deb repo?

Zimmerman: We’ve packaged all of the free software…what now?

Posted Jul 7, 2010 13:27 UTC (Wed) by dskoll (subscriber, #1630) [Link]

The meta-packager would have to have some rules. (I run into this a lot with .deb packages vs. CPAN modules.)

For example, the meta-packager could be told to prefer .debs if they are new enough to satisfy requirements. Otherwise, fall back on CPAN.

This is a very hard problem, though. And if you want to allow more than one version of a package to be installed at the same time, it gets totally nightmarish. This is why (in my experience) most real-world systems consist of distributor packages plus a few hand-installed and hand-maintained non-packages. And this makes security updates complex and annoying.

Zimmerman: We’ve packaged all of the free software…what now?

Posted Jul 7, 2010 13:43 UTC (Wed) by amck (subscriber, #7270) [Link] (1 responses)

The package manager is there to provide consistency guarantees for the _system_, not just the software in the package. If you have multiple package management systems (eg dpkg + CPAN + python eggs, .. ) then you can't guarantee that the necessary dependencies are installed, that the language extensions match the version of the language installed, etc.

So you implement a set of rules, if you want them all to work together, and then you end up with a 'meta-package-manager' on top to enforce consistency. Think about how you would manage evolving packaging policies in such an environment.

Alternatively, you implement one package manager on the computer (eg. .deb or .rpm) and create converters to ensure that python eggs ship as debian-system-consistent .deb packages, etc. This is the most flexible approach: it means that only one place needs to change to make installed software match any changes in debian policy, etc; stops the python developers from being locked into deb-format and policy rules, etc. This is what is done today.

Zimmerman: We’ve packaged all of the free software…what now?

Posted Jul 8, 2010 9:06 UTC (Thu) by mjthayer (guest, #39183) [Link]

> Alternatively, you implement one package manager on the computer (eg. .deb or .rpm) and create converters to ensure that python eggs ship as debian-system-consistent .deb packages, etc. This is the most flexible approach: it means that only one place needs to change to make installed software match any changes in debian policy, etc; stops the python developers from being locked into deb-format and policy rules, etc. This is what is done today.

What about having say apt/dpkg as the meta-manager and CPAN/whatever plugins for that? So that apt-get commands also search through CPAN and so on. Of course, one is then relying on both the Debian people and the CPAN people to test that the two work well together. I don't think that is such a big issue though, because in the end the individuals who would be doing that testing are the same ones who package and test the stuff in Debian today.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds