Revamp ebuilds #1
Conversation
Signed-off-by: Alfred Wingate <parona@protonmail.com>
* actually hook up tests * remove unnecessary boilerplate and fill in metadata * dropped keywords Signed-off-by: Alfred Wingate <parona@protonmail.com>
Signed-off-by: Alfred Wingate <parona@protonmail.com>
|
Also an alternative view on how you could handle PATH https://gitlab.com/src_prepare/src_prepare-overlay/-/blob/master/dev-util/plan9port/plan9port-2021.10.05.ebuild?ref_type=heads#L48 |
parona-source
force-pushed
the
changes
branch
from
2adeb7a to
109828c
Compare
|
Also minimal -> tiny because it installs tiny programs in addition rather than being more minimal by omitting something. |
parona-source
force-pushed
the
changes
branch
from
109828c to
fccd0cf
Compare
|
And /opt/bsd instead of /usr/bsd, because its less random from a FHS perspective |
* Add missing flags and dependencies * Cleanup all around Signed-off-by: Alfred Wingate <parona@protonmail.com>
parona-source
force-pushed
the
changes
branch
from
fccd0cf to
1dd43e6
Compare
|
(and yes there are no tests for real https://github.com/chimera-linux/chimerautils/actions/runs/5897935032/job/15998248788#step:5:736) |
|
BSD_PREFIX could also be /usr/lib/bsd. This would be similar to how llvm handles itself. |
|
The difference is that llvm is a library, whilst these utils are not. I think /opt/bsd is a good idea, but i originally wanted /usr because that's where most third-party programs get installed. /opt seems like a good fit as well though, but I'd like to look at more examples.
…On October 27, 2023 7:53:26 PM UTC, Alfred Wingate ***@***.***> wrote:
BSD_PREFIX could also be /usr/lib/bsd. This would be similar to how llvm handles itself.
--
Reply to this email directly or view it on GitHub:
#1 (comment)
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
|
keep in mind that llvm is slotted so it installs everything in there. so binaries and headers included. with llvm I mean the umberlla under llvm-project and not just libllvm.so |
|
/opt:
/usr/:
/usr/local:
Those seem to be the options. |
|
https://devmanual.gentoo.org/general-concepts/filesystem/index.html https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0201
|
|
Also system package manager shouldn't touch */local its for the system administrator to use as they please. |
|
I saw the explicit mention of /usr/local. Hmm, I am not liking my options here. Different sources try and say that opt is more for things like steam or discord - binaries that typically ship all of their dependencies and do things very differently. /opt might be the only right option here though. |
|
Ideally it would be installed normally, but that would require app-alternatives and picking non conflicting names for the binaries/manpages. |
|
right. app-alternatives/{coreutils,findutils,etc} is an idea for the future, but not now. |
|
I still think /usr/lib is also valid in practise. The rule about installing libraries only isn't respected. Notable systemd, pkgconfig, python, gcc and llvm do their own thing there in their own directories. But /opt/bsd or /opt/chimerautils is fine /opt is for the oddballs. |
|
I prefer /opt/bsd over /opt/chimerutils because the only thing branded about them is the name. Many files aren't touched at all from FreeBSD, for example. |
|
As it looks right now, I like it except for the keywords. I only tested amd64 as you guessed, but I have a few VMs for riscv and aarch64 and I could test on those. Do you have powerpc hardware/VMs? |
|
My point about keywords is to just not falsely claim "it should work" when you don't know. And its best to keyword it if there is someone with that hardware and is interested themselves. |
|
I'm going to try and spin up a few VMs and test this on some gentoo live ISOs. Do you have suggestions for a test suite? Although not strictly required, I'd like it if the test isn't building world because most of the time that's just compiling, and compiling in a cross-architecture VM is slow. |
|
I don't think you should spend time testing it, unless you are doing it because you are interested in it for the sake of it. Its wasted effort unless you find value in it in your own way. But a decent enough threshold is that they A) build B) tests pass if there are tests and C) they don't SEGFAULT when you execute the binaries. There is no motivation tbh to add more keywords unless there is someone in the wild who wants it from the package. |
|
I could see my own personal benefit in an aarch64 build guaranteed to work as I plan on doing some related things with a laptop sooner or later. Some subset of the GNU coreutils test suite would be something I'd consider to test every flag versus the GNU counterpart to make sure they deliver expected (but perhaps not exact) results. |
|
This looks good as is. I'll change keywords as needed. |
Dropped keywords as I suspect they were added haphazardly. I have no problem readding if you actually have such hardware and have tested it on that.