| Summary: | [EAPI] unpacking lzma files | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Grant Goodyear (RETIRED) <g2boojum> |
| Component: | [OLD] Core system | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | almostik, arctika42, bugs_gentoo_org.Tim_OKelly, christopher.aiken, cJ-gentoo, der.osterhase, dev-portage, esigra, jer, jordi.sola, pacho, peper, pms, rafael, rodrigo |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Grant Goodyear (RETIRED)
2008-01-23 17:35:54 UTC
Paludis skips the lzma-compressed file. 17:36 < g2boojum> SpanKY, vapier: bug # 207193 <-- nobody else seeing this? 17:37 <@vapier> that's weird 17:37 <@vapier> i bet it's the lzma hate 17:38 <@vapier> g2boojum: you'd have to post the full build output, not the epatch log 17:41 < g2boojum> Ah, you mean this part: >>> Starting src_unpack 17:41 < g2boojum> >>> Unpacking coreutils-6.10.tar.lzma to /var/tmp/paludis/sys-apps/coreutils-6.10-r1/work 17:41 < g2boojum> Skipping unpack for /usr/portage/distfiles/coreutils-6.10.tar.lzma 17:43 <@vapier> ;) There should be an EAPI bump for this kind of change. Since which version is the lzma support included in portage? btw. 0.26.0_alpha9 supports lzma extraction (In reply to comment #2) > There should be an EAPI bump for this kind of change. Since which version is > the lzma support included in portage? Yep, that's what vapier said when I asked him about it. > btw. 0.26.0_alpha9 supports lzma extraction So it does. Thanks! Because sys-apps/coreutils-6.10-r1 now contains mktemp, you have to remove sys-apps/mktemp before upgrading coreutils (otherwise mktemp blocks coreutils). For decompression lzma (while upgrading coreutils) the mktemp binary is required. try: $ p7zip <Enter> which: no mktemp in ( ... /usr/bin/p7zip: mktemp: command not found Workaround: - copy mktemp from /bin to /usr/local/bin - unmerge mktemp - emerge -u coreutils - remove mktemp from /usr/local/bin - maybe now you should change the dir or try "hash -r" (In reply to comment #4) > Because sys-apps/coreutils-6.10-r1 now contains mktemp, you have to remove > sys-apps/mktemp before upgrading coreutils (otherwise mktemp blocks coreutils). > For decompression lzma (while upgrading coreutils) the mktemp binary is > required. > > try: > $ p7zip <Enter> > which: no mktemp in ( ... > /usr/bin/p7zip: mktemp: command not found It works fine with portage afaik. Our extraction code uses lzma-utils instead of p7zip so it doesn't need mktemp: lzma) if [ "${y}" == "tar" ]; then lzma -dc "${srcdir}${x}" | tar xof - ${tar_opts} assert "$myfail" else lzma -dc "${srcdir}${x}" > ${x%.*} || die "$myfail" fi ;; Well we've clearly established it's not a base-system bug, it's a Pauldis bug. Re-assigning to peper to fix. (In reply to comment #6) > Well we've clearly established it's not a base-system bug, it's a Pauldis bug. > Re-assigning to peper to fix. As peper pointed out in comment #2, paludis has already been fixed. The only reason I can see for this to still be open is to discuss the matter of adding a new compression format to unpack without an EAPI bump. (In reply to comment #6) > Well we've clearly established it's not a base-system bug, it's a Pauldis bug. > Re-assigning to peper to fix. > As dleverton said, it's not a paludis bug. Also, you appear to have misread the package metadata.xml works for me on the shipping package manager with Gentoo. The ebuild is fine. Hence not a base-system bug. (In reply to comment #9) > works for me on the shipping package manager with Gentoo. Why do we have EAPIs then? New features require EAPI bumps. Ideally, this should also be documented in PMS. - ferdy (In reply to comment #9) > works for me on the shipping package manager with Gentoo. a) I just downloaded a portage snapshot, it appears to be shipping with at least 5 package managers: yum, rpm, portage, pkgcore and paludis > The ebuild is fine. > Hence not a base-system bug. Oh, maybe that's why vapier added pms-bugs to the cc? Maybe you could have taken a second to look at the bug, rather than reassigning it to the wrong person and then INVALIDing it. If we're talking about EAPI and PMS changes, that's the PMS people. (In reply to comment #10) > Why do we have EAPIs then? New features require EAPI bumps. Ideally, this > should also be documented in PMS. We can avoid the need for an EAPI bump for trivial changes like this if we move unpack into the tree somewhere. For example, the unpack function could be defined in something like an eclass or the profile.bashrc of the base profile and then it would be less tightly coupled to EAPI. Then we could easily do lots of api extensions without changing the EAPI. we talked about this sort of thing a long time ago, but ferringb iirc was against it which means it wasnt going to happen the proposal was to move a bunch of funcs out of ebuild.sh and into the tree and that file would be auto-sourced. things like unpack(), epatch(), econf(), etc... were being looked at for it. If our new system is well designed then there will be no drawbacks and it will only give us more flexibility in the ebuild api while allowing us to avoid EAPI breakages like this bug. We're creating another class of ebuild libraries in the tree, similar to eclasses. If we organize it so that there is a separate script for each eapi then the package manager can take the eapi from the ebuild and use that to determine which script to source. The separate scripts for each eapi could share implementations of some functions amongst themselves where appropriate. For example, the econf function is the same for both eapi 1 and 2, so it's implementation could be shared between them. i'm not really concerned with the security aspects of it, but if we dont care about forcing people to fetch some tree in order to perform any ebuild operation, then it should be fine (In reply to comment #15) > If our new system is well designed then there will be no drawbacks and it will > only give us more flexibility in the ebuild api while allowing us to avoid EAPI > breakages like this bug. > > We're creating another class of ebuild libraries in the tree, similar to > eclasses. If we organize it so that there is a separate script for each eapi > then the package manager can take the eapi from the ebuild and use that to > determine which script to source. The separate scripts for each eapi could > share implementations of some functions amongst themselves where appropriate. > For example, the econf function is the same for both eapi 1 and 2, so it's > implementation could be shared between them. And... what do you do if you're *not* deriving from gentoo-x86, and using a seperate/standalone tree? I'm all for moving chunks of ebuild.sh into the tree- I'm against mandating that each repo carry their own implementation of EAPI chunks (that's the managers duty, not the tree). I'm nobody to talk, but I agree with the idea of having "exotical" unpackers in the tree in the form of eclasses. This can add the correct dependencies to packages and do nice things. This idea can be a solution to a part of my request in bug #218459 : >I also think of the possibility to add support to app-arch/lzma's lzma in package managers' unpackers, and having virtual/unlzma, which could be provided by both lzmas and busybox with use=lzma. >This principle could also be used with other compression methods... I imagine an unpack-lzma.eclass, a virtual/unlzma provided by the packages that could unpack lzmas. Cleaner tree, and it would avoid duplication of code in package managers :) *** Bug 216997 has been marked as a duplicate of this bug. *** *** Bug 223187 has been marked as a duplicate of this bug. *** *** Bug 233931 has been marked as a duplicate of this bug. *** *** Bug 236215 has been marked as a duplicate of this bug. *** *** Bug 237188 has been marked as a duplicate of this bug. *** *** Bug 316093 has been marked as a duplicate of this bug. *** What is this bug about? - PMS should mention lzma (it does since EAPI 2 or so) - Move unpack to an eclass (as suggested in comment #13) - Tracker for packages with missing lzma dependencies (as the dupes indicate) Feel free to reopen with appropriately changed summary. Or open a new bug (which may be cleaner). |