The unpack function right now hardcodes the tools and the syntax used to unpack particular kind of archives, basing itself on the extension of the file. We actually have in portage multiple choices of tools that can unpack a given archive format, for instance: tar(.bz2/.gz): tar, star, bsdtar zip: unzip, bsdtar cpio: (GNU) cpio, bsdcpio and so on. For instance a Gentoo/FreeBSD system will have libarchive installed by default, one can avoid installing cpio and unzip with that installed. In the future more formats could be added to that too. Not only the tool might differ, but its syntax too: while unpacking a tar.gz with GNU tar will perform better doing a zcat piped through a tar command, libarchive will handle decompression and unpacking in a single process, so the pipe makes little sense when using that. It should be possible to leave the user with the choice of which tool to use to extract a given filetype by creating a series of virtual packages, like for instance virtual/portage-unpack-zip and virtual/portage-unpack-cpio. An exception to this might be the tarball format as that is supposed to be always unpackable (although having a virtual/portage-unpack-tar{gz,bz2} as a portage dependency would be nice to get rid of tar from system, for instance).
Am I missing something, or would this just be some updated deps and a series of if type tar && type bzcat; then bzcat foo.tar.bz2 | tar x elif has_version libarchive; then # do whatever is needed here elif ... Maybe wrapped a bit nicer. If that's all then I don't think this is suitable as a full SoC project.
Well, probably not really, unless you still want to hardcode everything, which is quite a bit. The optimal way would be to have a way either for packages to describe their capabilities or to "outsource" the script for unpacking on the virtual package itself.
Assuming we want to make the package manager's unpack function support it, this is an EAPI bump. Feel free to remove if you want to do it in a way that doesn't require package manager changes, although that would force the complexity into the ebuilds instead....
(In reply to comment #3) > Assuming we want to make the package manager's unpack function support it, this > is an EAPI bump. It isn't unless the interface changes, and I don't see any reference to that. Don't confuse this with adding additional formats like in bug #207193, such things might be made easier with this project, but are a separate issue.
(In reply to comment #2) > Well, probably not really, unless you still want to hardcode everything, which > is quite a bit. As I said: wrapped a bit nicer. But no need for overengineering, IMO this still belongs in the manager, not the packages. For each format there are only a couple of tools to consider, that can be managed in the PM.
(In reply to comment #4) > (In reply to comment #3) > > Assuming we want to make the package manager's unpack function support it, this > > is an EAPI bump. > It isn't unless the interface changes, and I don't see any reference to that. If an ebuild depends on, say, virtual/portage-unpack-zip and not app-arch/unzip, but the package manager hardcodes unzip, then the ebuild will fail on systems that have libarchive but not unzip installed.
(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #3) > > > Assuming we want to make the package manager's unpack function support it, this > > > is an EAPI bump. > > It isn't unless the interface changes, and I don't see any reference to that. > > If an ebuild depends on, say, virtual/portage-unpack-zip and not > app-arch/unzip, but the package manager hardcodes unzip, then the ebuild will > fail on systems that have libarchive but not unzip installed. That's why the package manager depends on the virtual, not the indivdual ebuilds. Moving the deps into the ebuilds would be a separate step.
So you'd make the package manager dep upon virtual/portage-$obscure-unpacker?
unpack() is really just a special case. the thread in Bug 207193 covers this in the general case.
(In reply to comment #8) > So you'd make the package manager dep upon virtual/portage-$obscure-unpacker? Please don't comment if you don't get what this bug is about. File your own bug if you want to make PMS look important.
(In reply to comment #10) > (In reply to comment #8) > > So you'd make the package manager dep upon virtual/portage-$obscure-unpacker? > > Please don't comment if you don't get what this bug is about. File your own bug > if you want to make PMS look important. Please don't comment until you understand the implications of the change and why it has to be an EAPI issue.
(In reply to comment #11) > Please don't comment until you understand the implications of the change and > why it has to be an EAPI issue. Changing the exact command inside unpack() without changing the IO behavior has the implication of changed deps of the package manager and doesn't affect EAPI, unless unpack is moved into the tree. Thanks for wasting everyones time.
(In reply to comment #12) > Changing the exact command inside unpack() without changing the IO behavior has > the implication of changed deps of the package manager and doesn't affect EAPI, > unless unpack is moved into the tree. > Thanks for wasting everyones time. The package manager doesn't dep upon the unpacker. Individual ebuilds do. It thus affects EAPI. Really, this isn't difficult. Think about it before you mess with the Cc: list again.
(In reply to comment #9) > unpack() is really just a special case. the thread in Bug 207193 covers this > in the general case. Right. Perhaps a good SOC project would be to split the unpack() and other functions into a separate library package that package managers could pull in as a dependency. We started discussing this in bug 207193, comment #15.
Seeing how this bug is similar to bug 33544 in some ways, maybe unpack() should be part of something like the eapi-2.eclass idea mentioned in bug 33544, comment #16.
This is mostly superseded by unpacker.eclass. Reopen (with a tangible proposal) if you still need support in PMS.
