aboutcode-org / scancode-toolkit

:mag: ScanCode detects licenses, copyrights, dependencies by "scanning code" ... to discover and inventory open source and third-party packages used in your code. Sponsored by NLnet project https://nlnet.nl/project/vulnerabilitydatabase, the Google Summer of Code, Azure credits, nexB and others generous sponsors!
https://aboutcode.org/scancode/
2.13k stars 548 forks source link

Support illumos/omnios/netbsd packages #3164

Open pombredanne opened 1 year ago

pombredanne commented 1 year ago

See

pombredanne commented 1 year ago

From a chat:

Philippe Ombredanne: @ Jim Klimov

Note since you mentioned, it does not handle SVR4 package though it support FreeBSD.

I would love to have support for SVR4/opensolaris style of packages :slightly_smiling_face: contribution/help mucho welcomed!

Jim Klimov @ Philippe Ombredanne

Well, my time with SVR4 packaging was a couple of decades ago, and in most of illumos (post-opensolaris) ecosystem it is mostly on "life lease": tooling and libs still exist so packages can be made and installed, but otherwise deprecated and not distributed at least by major distro efforts.

There are some legacy-flavoured ones that tried to stick with SVR4, others even used DEB to package Solarish files, but most of the community went along with "pkg(5)" aka IPS - which is much more metadata-rich, has some different paradigms about installation lifecycle (e.g. no more postinstall scripts, rather using single-fire services for first runtime), and singular self-contained package files are possible but not used much -- rather whole repositories are made and maintained.

It did take literally years to get used to, get persuaded and persuade others that this in fact is better regarding maintainability and bandwidth (e.g. your packaging client can fetch only files that changed since last version, but not the immobile foundations), and I think the info crusade still continues after a decade :slightly_smiling_face:

If you do want to add SVR4, I'd suggest taking a look at Joerg Schilling's work (possibly part of Schily distro) - he was one of the last active developers on several technologies others gave up on, including a much more functional and network-aware SVR4 tooling.

And a very standards-conformant shell, among other highlights.

Philippe Ombredanne @ Jim Klimov

Thanks... I am interested in things that would be used in practice and seen in the wild. ....

so if SVR4 is not, and IPS is it, then IPS it would be?

Jim Klimov

Probably, at least moving forward with both Oracle Solaris and illumos communities. Long-term, rather the latter :slightly_smiling_face:

Philippe Ombredanne @ Jim Klimov

Are Illumos, Solaris, OpenSolaris, OpenIndiana still active? active communities?

Jim Klimov

Yes, quite - there are several community and commercial players in the illumos ecosystem; many cooperating, a few rather leeching, business as usual :slightly_smiling_face:

Less certain about Solaris proper; there are certainly good folks on the other side, some still cooperate with the community.

But I think nobody has any idea about the corporation's stance on that legacy - it may be a burden they have to uphold for as long as LTS contracts last. Just don't know, there are few messages from behind the red curtain.

Philippe Ombredanne

I reckon that I have seen FreeBSD used in the wild, but not much of Solaris or Solaris packages

Jim Klimov

So to recap, OpenSolaris was forked as illumos and as OpenIndiana, initially two separate efforts which quickly converged as a "kernel-and-tools" (illumos-core) and a practical distro (OpenIndiana).

And then other companies and people had pet projects or practical products based on illumos, including OmniOS as the other popular FOSS distro there.

OI aims to cover everything in-distro, desktop and server and all; OO aims to be a minimal-footprint "JeOS" for people who roll their own server content tailored to purpose. So while technically they are similar, and many people cooperate developing both, build recipes differ and mainly the goals and ideology of them differs, so talks of converging withered away :slightly_smiling_face:

Philippe Ombredanne

so is there a package manager and a public package repo/registry/feed for these?

Jim Klimov

For OpenIndiana "Hipster" there is a rolling-release model at http://pkg.openindiana.org/hipster/en/index.shtml

Ideas to cut "stable releases" for OI was discussed but I think abandoned (or suspended for years) - mostly due to nobody willing to look after old stuff when time can be spent spinning new stuff :slightly_smiling_face:

FWIW https://github.com/illumos has the core and other common resources for the ecosystem

For OmniOS there is a business-like approach with numbered releases ("bloody" which is more or less rolling in the newest number), and every few numbers are LTS, roughly yearly

Regarding SBOM as a security tool, maybe makes sense to contact SmartOS too https://www.tritondatacenter.com/smartos - this is a commercial hosting-oriented leg of illumos ecosystem (I think now they power Samsung datacenters). They would probably benefit from inventorying the packages and resulting images they (or customers) make.

But possibly they have made something already.

Got no recent info there really.

And on a somewhat related note, many people (maybe more so on OmniOS) use a baseline OS and alternative software distribution efforts from https://sfe.opencsw.org/ and http://pkgsrc.joyent.com/

The latter (pkgsrc) is generally very cross-platform, so may be useful to support not just for illumos :smile:

Somewhat similarly with (Home)Brew - I think it is gathering ground lately, not just for MacOS nowadays

Jim Klimov

Also the Brew author started a new package-manager effort https://tea.xyz/ which aims to be also tied with metadata in and out (in particular to disseminate contributions to people supporting obscure but important infra projects), probably SBOM is a core concept there (but I did not dig into details more) (edited)

Philippe Ombredanne

Thanks... the point is that general, no package or origin means no SBOM

or nothing useful

Philippe Ombredanne

I guess a mog file is as close as it gets to a package manifest of sorts https://github.com/omniosorg/omnios-extra/blob/master/build/tcpdump/local.mog

Or rather a build.sh https://github.com/omniosorg/omnios-extra/blob/master/build/tcpdump/build.sh ?

No structured data format?

(luckily I wrote a shell script parser https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/bashparse.py for similar cases)

https://github.com/TritonDataCenter/pkgsrc/tree/trunk/multimedia/ffmpeg2 seems to have something like Makefile with metada kinda like FreeBSD

so easier to get to :slightly_smiling_face:

I am building an open db of all the purls FWIW in https://github.com/nexB/purldb/

Jim Klimov

For structured info in source, rather https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/sysutils/tcpdump/tcpdump.p5m largely templated and populated by data from https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/sysutils/tcpdump/Makefile

The resulting package manifest would be like http://pkg.openindiana.org/hipster/manifest/0/diagnostic%2Ftcpdump%404.99.1%2C5.11-2022.0.0.0%3A20221003T145138Z

For OI manifest link above, you might want to save a copy of the text if needed. Or a way to get the new one : search at http://pkg.openindiana.org/hipster/en/search.shtml?token=tcpdump&action=Search and press "Manifest" link

as a rolling release with limited storage, there are somewhat-regular cleanings to drop old artifacts and mainly to keep the metadata database size manageable (most people need newest builds and care less for knowing about a hundred recent iterations)