Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Sam James wrote: > Eli Schwartz writes: > >> On 4/3/24 11:30 AM, Eddie Chapman wrote: >> >>> Just to report I've been able to remove app-arch/xz-utils from my own >>> workstation, with 2412 packages installed and running kde. I'm going >>> to roll it out to my other gentoo systems which have a lot less stuff >>> on them so am confident will be fine. It's not completely trivial but >>> not as difficult as I imagined it to be, certainly something an >>> advance Gentoo user could do if they wanted, with instructions. It >>> does involve a relatively small hack and functionality previously >>> provided by xz-utils is replaced by app-arch/p7zip. >> >> I'd just like to clarify my previous posts: what you're describing here >> is neat and productive and valid to my eyes. Actually, I wish this had >> been the topic of the *first* post in this thread. :) > > Completely agreed. We just prefer shorter text and focusing on technical > changes. > > This sounds fun! > > >> [...] >> > > thanks, sam Well, I didn't think my first post was so bad, but OK, I'll take that criticism onboard and in future will think more about how I bring something to this list, and will take into account what you and Eli have said. Thanks for sharing your thoughts above, both of you, in a constructive way. regards, Eddie
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Eli Schwartz wrote: > On 4/3/24 11:30 AM, Eddie Chapman wrote: > >> Just to report I've been able to remove app-arch/xz-utils from my own >> workstation, with 2412 packages installed and running kde. I'm going to >> roll it out to my other gentoo systems which have a lot less stuff on >> them so am confident will be fine. It's not completely trivial but not >> as difficult as I imagined it to be, certainly something an advance >> Gentoo >> user could do if they wanted, with instructions. It does involve a >> relatively small hack and functionality previously provided by xz-utils >> is replaced by app-arch/p7zip. > > > I'd just like to clarify my previous posts: what you're describing here > is neat and productive and valid to my eyes. Actually, I wish this had been > the topic of the *first* post in this thread. :) > > Replacing implementations has several great uses. There's some prior art > in make.conf, but it doesn't go far enough: > > PORTAGE_BZIP2_COMMAND > BINPKG_COMPRESS > BINPKG_COMPRESS_FLAGS > > > Disregarding the security component entirely, one might wish to use pixz > or pigz instead of the default programs. Why not 7zip as well? One of my emails elsewhere in this thread (easy to miss in a long thread, I know) I discussed pixz, pigz and 7zip. The former two were not suitable for me as both rely on xz utils. However I will probably switch from p7zip to the latest upstream 7zip in the near future, for reasons discussed in that email. > In terms of security, this suggests an easy and simple way both to allow > users to depclean xz-utils without sacrificing the ability to install > packages using *.tar.xz sources, and for Gentoo to roll out an update that > would do this distribution-wide if necessary via a trivial configuration > change. > > https://dev.gentoo.org/~ulm/pms/head/pms.html#section-12.3.15 may need > updating to allow this. But it seems very valid to propose doing exactly > that. I am not sure why it specifies e.g. "must ensure that GNU gzip" with > heavy ties to implementations, when it doesn't specify such for > compression. That would certainly be a nice improvement for all users if it were ever to come to pass. > I'm guessing what you did was override/hook the unpack phase helper > function and divert it to 7zip instead. ;) It would be interesting to have > actual hooks for that instead. Yes it is in the unpack phase where emerge calls /usr/bin/xz mostly. In fact I didn't have to touch emerge/portage, it was more crude, I uninstalled app-arch/xz-utils (and put it in /etc/portage/profile/package.provided) and replaced /usr/bin/xz with a bash script to behave like what the unpack phase was expecting, but using /usr/lib64/p7zip/7za to do the decompression. However, I need to do some more work on this "wrapper" (though it's more than a wrapper) as I found one package where xz is called from the install phase and my script doesn't handle that yet it just throws an error for anything other than the unpack phase case (which is 99.9 percent of packages). But ultimately doing something along the lines of what you suggest instead would of course be much better than this dirty hack (though it works just fine for me for now). Since there appears to be some interest I'll put together a single email to the list later today detailing everything, as I needed to do more things overall in addition to replacing /usr/bin/xz.
[gentoo-dev] Re: [PATCH] efmtutil-sys: use ebegin/eend and log output
I just noticed two things seconds after sending the patch:
Commit message is missing "texlive-common.eclass" prefix.
On 04/04/2024 15.01, Florian Schmaus wrote:
Use ebegin/eend and instead of redirecting the output to /dev/null
capture stdout and stderr under a file under $T.
Signed-off-by: Florian Schmaus
---
eclass/texlive-common.eclass | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index 66d3999bd103..0cc61f735cb2 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -199,9 +199,11 @@ etexmf-update() {
efmtutil-sys() {
if has_version 'app-text/texlive-core' ; then
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/bin/fmtutil-sys ]] ;
then
- einfo "Rebuilding formats"
- "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null ||
- die -n "fmtutil-sys returned non-zero exit status
${?}"
+ ebegin "Rebuilding TexLive formats"
+ "${EPREFIX}"/usr/bin/fmtutil-sys --all \
+ > "${T}"/fmutil-sys-all.log \
+ &> "${T}"/fmutil-sys-all.err.log
This should be 2> instead of &>
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] efmtutil-sys: use ebegin/eend and log output
Use ebegin/eend and instead of redirecting the output to /dev/null
capture stdout and stderr under a file under $T.
Signed-off-by: Florian Schmaus
---
eclass/texlive-common.eclass | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index 66d3999bd103..0cc61f735cb2 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -199,9 +199,11 @@ etexmf-update() {
efmtutil-sys() {
if has_version 'app-text/texlive-core' ; then
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/bin/fmtutil-sys ]] ;
then
- einfo "Rebuilding formats"
- "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null ||
- die -n "fmtutil-sys returned non-zero exit
status ${?}"
+ ebegin "Rebuilding TexLive formats"
+ "${EPREFIX}"/usr/bin/fmtutil-sys --all \
+ > "${T}"/fmutil-sys-all.log \
+ &> "${T}"/fmutil-sys-all.err.log
+ eend $? || die -n "fmtutil-sys returned non-zero exit
status ${?}"
else
ewarn "Cannot run fmtutil-sys for some reason."
ewarn "Your formats might be inconsistent with your
installed ${PN} version"
--
2.43.2
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
If that’s working, it could at least be on an user personnal page on the wiki as well. Le 04/04/2024 à 10:32, Sam James a écrit : Eli Schwartz writes: On 4/3/24 11:30 AM, Eddie Chapman wrote: Just to report I've been able to remove app-arch/xz-utils from my own workstation, with 2412 packages installed and running kde. I'm going to roll it out to my other gentoo systems which have a lot less stuff on them so am confident will be fine. It's not completely trivial but not as difficult as I imagined it to be, certainly something an advance Gentoo user could do if they wanted, with instructions. It does involve a relatively small hack and functionality previously provided by xz-utils is replaced by app-arch/p7zip. I'd just like to clarify my previous posts: what you're describing here is neat and productive and valid to my eyes. Actually, I wish this had been the topic of the *first* post in this thread. :) Completely agreed. We just prefer shorter text and focusing on technical changes. This sounds fun! [...] thanks, sam
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Eli Schwartz writes: > On 4/3/24 11:30 AM, Eddie Chapman wrote: >> Just to report I've been able to remove app-arch/xz-utils from my own >> workstation, with 2412 packages installed and running kde. I'm going to >> roll it out to my other gentoo systems which have a lot less stuff on them >> so am confident will be fine. It's not completely trivial but not as >> difficult as I imagined it to be, certainly something an advance Gentoo >> user could do if they wanted, with instructions. It does involve a >> relatively small hack and functionality previously provided by xz-utils is >> replaced by app-arch/p7zip. > > > I'd just like to clarify my previous posts: what you're describing here > is neat and productive and valid to my eyes. Actually, I wish this had > been the topic of the *first* post in this thread. :) Completely agreed. We just prefer shorter text and focusing on technical changes. This sounds fun! > [...] thanks, sam
