UniPKG (universal Package manager) is a modular package manager. It contains support for .rpm, .deb and Slack’s .tgz package format. In future, ArchLinux’s package format is planned as well. It doesn’t depend on any of the distribution’s tools; it’s completely self-sufficient.
in the future it’s planned the page says. until that happens we cannot force all those lovefull distros (such as Archlinux, Debian) to have the slack “philosophy” (of no deps) and in the end dep hell (because you end up installing manual packages from there and from here)
True, but how would you propose handling dependencies, while each package format provides dependency information in different format — or doesn’t provide it at all? That’s why remote repository, which always tells the -package name- and relation (newer, older, whatever) is apparently the way. It’s 0.foo anyway, but I guess it’s rather fit for small devices already, where size and speed -really- matters.
>True, but how would you propose handling dependencies
emerge
how would you propose handling dependencies
No need to re-discover what has been around for quite a while. I mean, it’s nice (at least in theory) to have some sort of cross-distro package handling, but the only single reason I would ever want that is to be able to use Debian’s repositories in _any_ distro on this earth. Other than that, why use a package manager which a). has no dependency handling, or b). has dependency handling but it’s worse then dpkg/apt. If some yet-another-genius comes around suggesting that every other package manager is crap as hell and his one is the best on the planet, he’d better be much better than this one.
I think
apt-get install [protocol://machine][/directory][/file.deb] should be the same as:
1. adding protocol://machine/directory to sources.list;
2. updating Packages.gz only from the URI above;
3. pinning the URI above as priority 9999;
4. apt-get install file;
5. undoing #1 to #3.
That sounds pretty useful!
$whizz is a unified package system which handles rpms. debs, tgz, …
Uuh, can you name some other $whizz than this unipkg?
It seems like that’s about how often they’re coming out and that begs the question: How do I install a package manager if I need one?
(The other question that’s being begged is: do I know what begging the question really means?)
id love to see this coming out, so i dont have to hear crap anymore from slackware users bugging me because i dont have to deal with stupid stuff anymore because i use ubuntu.
there are simply no issues in ubuntu.
gahh.
watever happened to autopackage…lying low?
Don’t worry, we’re still alive. 🙂
We’ve haven’t had any major releases for a while (only bugfix for our stable series) so it has been rather quiet on the news pages.
Some tools to extend autotools
1. Patch “install” to manage “package owned files” (uninstall, store md5sums, patch on update and such)
2. A global p2p network to distribute rcs branches and microbranches
3. A branch fetcher and aggregator to download from and monitor branches in 2
2. Layer a dependency solver on top of ./configure and 2+3
5. Plugins for IDE’s to manage 2
If a non-native package is to be intalled on your distribution, the package could contain a list of the _files_ necessary for it to work.
For example one required file could be “libpng.so.3” Not sure if that is a valid example, but anyhow, if the file in question is not installed a dependency resolving mechanism needs to fix things.
Say that the distribution has an online database contains the files of all available native packages. Then, wouldn’t it be easy for the native package manager to resolve any dependencies?
Does any package manager work like this? Seems like a feasible way to integrate non-native application packages with the distros own packaging system, or have i missed some important ‘gotcha’ here?
My point is that specifying dependencies in the form of files seems easier than defining them in terms of package names, since they aren’t necessary inter-distro-consistent like file names are.
Your idea has a good point — and yes, RPM does this. In header ID 1049, it contains information about what is necessary, and some details about it. For example:
/sbin/ldconfig
libX11.so.6
…
libpthread.so.0
libpthread.so.0(GLIBC_2.0)
libpthread.so.0(GLIBC_2.1)
libpthread.so.0(GLIBC_2.3.2)
libxosd.so.2
rpmlib(CompressedFileNames)
rpmlib(PayloadFilesHavePrefix)
This mechanism is rather interesting for, as you said, interdistribution package transition. However, Debian uses package names and versions (which may or may not be good) and Slackware provides _no_ information about dependencies whatsoever.
That’s why you cannot solve dependencies on package manager level, if you want to use multiple package formats (sometimes even same format, but different distribution… typically forks of slackware), and you have to rely on remote repositories, where each package has info like “With me, you gotta have also $foo and $bar packages to work properly!”