Add FreeBSD installation instructions #321
Conversation
|
Screenshot from the rendering of the PR:
|
FreeBSD ports for OpenSearch and OpenSearch-Dashboards have been committed to the FreeBSD ports tree, and packages will be available soon to FreeBSD users through the regular package management system. Add FreeBSD to the list of platforms. Because installation instruction do not change based on the architecture, add a "All" architecture to avoid duplicating the same information multiple times. Also include a link to the port page on FreshPorts which allow to "conveniently" see the port history (in a more convenient way than cgit). While here, adjust the list of all artifacts to order them alphabetically in the artifacts directory.
| architecture: all | ||
| slug: opensearch-1.0.1-freebsd-all | ||
| category: opensearch | ||
| type: pkg |
There was a problem hiding this comment.
Humm. pkg is a bit overloaded as it's used in macos too.
There was a problem hiding this comment.
Quite agree… Maybe something like 'system-package' to insist on the way this is managed using the regular package manager of the system?
| artifact_id: opensearch-dashboards | ||
| architecture: all | ||
| platform: freebsd | ||
| type: pkg |
There was a problem hiding this comment.
see above. I think it might need some disambiguation.
_layouts/versions.html
Outdated
| @@ -46,11 +48,13 @@ | |||
| - x64 | |||
| - arm64 | |||
| - x86 | |||
| - all | |||
There was a problem hiding this comment.
would noarch work better than all? I've not settled on this... 🤔
There was a problem hiding this comment.
noarch make me think "platform agnostic" (e.g. we use noarch to refer to FreeBSD packages that are identical on all architectures, e.g. python / ruby). Here we indeed have platform-dependent packages because the application bundle architecture specific binaries (jna for OpenSearch; re2 for OpenSearch-Dashboards).
Maybe any is a better fit?
There was a problem hiding this comment.
@smortex OK - so what architectures are supported in the FreeBSD version?
There was a problem hiding this comment.
@stockholmux we currently have i386, amd64 (x86, 32 and 64 bits) and aarch64 (arm 64 bits) packages available. Other platforms might not have packages because of a failing dependency (I am not sure openjdk11 build on 32 bit ARM) or be delayed because of limited build resources (I only saw aarch64 packages today).
There was a problem hiding this comment.
OK. That makes sense @smortex I think it makes sense to more explicit here (repeating near identical /_artifact/ files) than less (using all or any). Two reasons:
- I'd like these files to be useful to eventually to power an API and making sure there is an explicit entry for each architecture would simplify the the implementation.
- Who knows, maybe someone ports OpenSearch to RISC-V (or whatever) and would be frustrated
allnot being true.
There was a problem hiding this comment.
Sure! How should we name 32bit x86 (i386 architecture with FreeBSD terminology)? x86 (what Microsoft seems to use for this architecture)?
There was a problem hiding this comment.
Replying to myself: x86 is not listed in the architectures list but appear in the architecture_order so should be fine :-)
`pkg` is already something used by MacOS, so remove this ambiguity.
|
As of today, The packages availability matrix is visible in FreshPorts at the URI the PR associate with the artifacts. |
|
🚀 |
Drop the generic `all` which is indeed not an architecture and might lead users to think that packages are available for architecture actually not supported.
|
Scheduled for production on 2021/10/4 |
FreeBSD ports for OpenSearch and OpenSearch-Dashboards have been
committed to the FreeBSD ports tree, and packages will be available soon
to FreeBSD users through the regular package management system.
Add FreeBSD to the list of platforms. Because installation instruction
do not change based on the architecture, add a "All" architecture to
avoid duplicating the same information multiple times.
Also include a link to the port page on FreshPorts which allow to
"conveniently" see the port history (in a more convenient way than
cgit).
While here, adjust the list of all artifacts to order them
alphabetically in the artifacts directory.