-
Notifications
You must be signed in to change notification settings - Fork 213
Add bsd package type #496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Add bsd package type #496
Conversation
PURL-TYPES.rst
Outdated
| - ``arch``: The target architecture for the package. | ||
|
|
||
| - Examples:: | ||
| pkg:bsd/freebsd/emacs@30.1_2?distro=14.3&epoch=3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For FreeBSD, another suggestion would includearch=all so it could have similar format as any other OS that includes qualifier arch.
Example: pkg:bsd/freebsd/emacs@30.1_2?distro=14.3&epoch=3&arch=all
If that is not required, no as it would reduce file size as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would there be more name space like bsd/freebsd/ports/emacs@30.1_2?distro=14.3&epoch=3 as it would nice to be able to also say bsd/freebsd/kernel/module@14.3 like thing or bsd/freebsd/core/app@14.3 or can they be handled other way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably ports would fit better as additional qualifier, example:
bsd/freebsd/emacs@30.1_2?distro=14.3&epoch=3&source=ports
More educational question:
For Kernel module, that is interesting point, how do you collect that? Since users can compile they own Kernel and possible enable/disable modules.
I ask this as in FreeBSD one can query the sqlite3 database and packages installed can be found, but for Kernel modules I am not too sure :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If pkgbase ever goes thru (and it seems to steadily do so) it'll bring kernel modules as pkg(8) packages New packages repositories for kernel modules. If one compiles own ones there is nothing to do but official ones should be able to point with purl?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need epoch? As there is this _2 part in package version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_2 is PORTREVISION, which is part of version and different from epoch. We use PORTEPOCH as epoch qualifier.
Please refer to FreeBSD Porter's Handbook for more information about PORTREVISION and PORTEPOCH.
pombredanne
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Do you know if you can invite folks in each of these communities to chime in on this? That would be awesome!
b580c87 to
b43ce9c
Compare
|
@pombredanne Updated the PR with the new approach. Thank you for letting me know! We will try to reach out to BSD communities to gather feedback from them. |
illuusio
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've looked this PR thru FreeBSD developer glasses. It seems be solid and can be used as-is without applying this review. It would nice to have more eyes to look at this from NetBSD and OpenBSD.
| @@ -0,0 +1,52 @@ | |||
| { | |||
| "$schema": "https://packageurl.org/schemas/purl-test.schema-1.0.json", | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct URL or is server down as this just returns HTTP server is too slow for me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. I just followed other purl type examples.
@pombredanne Do you know anything about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The server will be up in the new few days ;)
| - **Type Name:** BSD | ||
| - **Description:** BSD Operating System variant packages | ||
| - **Schema ID:** `https://packageurl.org/types/bitname-definition.json` | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why choose Bitname for types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one needs to be probably added in some point but as I can't get anything out of that domain or URL it probably does not matter.
types-doc/bsd-definition.md
Outdated
| ## Name definition | ||
|
|
||
| - **Native Label:** name | ||
| - **Note:** `The name is the component name. It must be lowercased.` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This requirement is bit complicated. How about KiCAD or FreeCAD for example whom likes that their name is written in strange way or X packages. There should be possibility to have also uppercase chars and how about is this alpha-numeric and how about packages like py311-my-python-package3 or package_name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use package names exactly as they are stored in the pkg database. Removed It must be lowercased..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there need to say anything about umlauts or similar stuff? How is UTF-8 things handled or is PURL similar to URL that one can decode inside with URL decoding if it's difficult character?
| | arch | Optional | | | The target architecture for the package. | | ||
| | distro | Optional | | | The BSD release version or distribution variant. | | ||
| | epoch | Optional | | | The package epoch number used for version comparison when normal version ordering is insufficient. | | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As FreeBSD is going thru pkgbasecifcation how one could write that package is from base FreeBSD 15.1 and not ports? I would suggest add keys like these (they can go under different name):
- branch - which would be is it unstable or stable version
- source - source of package like core, kernel or ports
With these one could write something like:
pkg:bsd/freebsd/mkuzip@15.1?source=core&branch=stable
pkg:bsd/freebsd/mkuzip@15.1?source=core&branch=releng/15.1
Then would URL would translate to https://pkg.freebsd.org/15/base_latest or https://pkg.freebsd.org/15/base_release_1 not ports one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@illuusio I agree to add something qualifier to distinguish how package is installed. But how can we get these information for each installed package?
It appears that this information does not exist in the pkg database.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion we have to trust people how write these PURLs. In perfect world it would be nice to have such info straight from pkg out generated. I don't know is this irrelevant to this but there were discussion about bit similar to this in mailing list PKGBASE Removes FreeBSD Base System Feature few weeks ago.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@illuusio Maybe we should leverage the existing known qualifiers such as repository_url, download_url, and vcs_url to represent how packages are installed. What do you think about using the known qualifiers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they are needed at the beginning and hopefully magically things will be sorted out and they are not needed anymore as they make PURLs look gluttered to me. If they don't exist then just assume installation location is default one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I think we should keep it simple at this point:
-
As per PURL specification, these qualifiers should be omitted when using default installation sources, which helps maintain cleaner and more readable PURLs.
-
Rather than defining new qualifiers now, we could revisit this discussion when FreeBSD's pkg database actually supports storing and retrieving this information. This approach would allow us to design qualifiers that align with FreeBSD's actual implementation.
This way, we can avoid premature specification while ensuring future extensibility when the underlying infrastructure supports it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think path goes that as 1. suggest we follow KISS and after this one has landed to PURL then start 2. as it can be little tricky part. As said we can't assume what will be supported by pkg(8) but I think it's doable.
c928568 to
b113213
Compare
|
@s-kenji what do you think should this be narrowed down to FreeBSD if there is not interest at this point of time? As this is made modular rest of the BSDs could be added later on when time is ready for them. |
|
@illuusio Yes, we reached out to OpenBSD and NetBSD communities, but we haven't heard from them. I'll update this PR accordingly. |
c772de2 to
65995b4
Compare
|
@illuusio I've updated this PR to primarily focus on FreeBSD, but to be able to extend it to other BSD variants in the future. Could you review this change and approve this PR if this looks good to you? |
I approve latest version. As I don't have admin/commit rights I can't push the approve button but hopefully @pombredanne can. |
|
@pombredanne @johnmhoran We have received approval from the FreeBSD community (through @illuusio) for this purl spec proposal. We also reached out to OpenBSD and NetBSD communities but haven't received any responses. Therefore, we decided to proceed with the FreeBSD specification for now. Since we have defined a minimal spec for FreeBSD, we believe this can be extended to support other BSD variants in the future if needed. If this looks good to you, could you approve and merge this PR? |
@s-kenji you are awesome! If I wanted to start a flame war, I could have said that there is only one BSD anyway. (But I will not tell you which one 👼 😈 ) |
types/bsd-definition.json
Outdated
| "namespace_definition": { | ||
| "native_name": "vendor", | ||
| "is_case_sensitve": false, | ||
| "note": "The namespace is the BSD variant name, primarily \"freebsd\" with support for other BSD variants. It is not case sensitive and must be lowercased.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you spell out explicitly netbsd and openbsd at least?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe all bsd (both in the schema name and files) should be changed to freebsd. I think both OpenBSD ports and NetBSD - in that case pkgsrc, that can be used to most Unix-like operating systems - will need a dedicated type.
(I've followed a bit the discussion but I need to dig deeper and learn more about both this spec... I think I can help in a possible pkgsrc spec.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iamleot Thank you for your input. I've looked into this more carefully.
While pkgsrc is indeed designed for cross-platform use across many Unix-like systems (which justifies its own pkg:pkgsrc namespace), I found that OpenBSD ports is actually specific to OpenBSD, tightly integrated with the OS like other BSD package managers.
Looking at the various BSD package managers:
- FreeBSD ports/pkg: FreeBSD-specific
- OpenBSD ports/pkg_add: OpenBSD-specific
- DragonFly DPorts: DragonFly BSD-specific
- NetBSD: uses pkgsrc
Given that most BSD systems have their OS-specific package managers (except NetBSD which uses the cross-platform pkgsrc), I believe using pkg:bsd/* namespace still makes sense for these OS-specific package managers.
So I would suggest:
- Keep
pkg:bsd/*for OS-specific BSD package managers - Use
pkg:pkgsrcfor pkgsrc packages
Would you share your thoughts on this perspective?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds fine to me!
I'm unfamiliar with OpenBSD ports and Dragonfly DPorts though, so I have no idea regarding them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pombredanne I've updated the note to explicitly list the BSD variants (FreeBSD, OpenBSD, and DragonFlyBSD), while incorporating feedback from @iamleot (from the NetBSD community) about NetBSD's package manager needing its own type due to its cross-platform nature.
Could you take a look at the PR again?
817e311 to
a640aed
Compare
|
The comments say that we should have something like as follows, right?
|
|
@pombredanne @johnmhoran Hi, I'm following up this PR regarding the BSD PURL type proposal. Quick status update:
We would like to move forward with this specification as FreeBSD is ready to adopt this PURL type. Thank you for your time! |
|
Should topic be changes to |
|
Yes - I updated the title. |
Add FreeBSD to OSVF-Schema with name FreeBSD and prefix FREEBSD. As FreeBSD OSV vulnerability database is not yet released this it bit WIP. FreeBSD PURL PR is also in the works: [purl-spec#496](package-url/purl-spec#496) Ecosystem schema's will be like: - `FreeBSD:base` For FreeBSD base system issues - `FreeBSD:kernel` For FreeBSD kernel issues - `FreeBSD:ports` For FreeBSD ports issues Signed-off-by: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>
This PR adds support for BSD package types to the purl specification.
BSD operating system variants (e.g. FreeBSD, OpenBSD, and NetBSD) have their own package management systems, but currently lack dedicated purl types despite their widespread use.
Key points:
pkgfor binary packages andportsfor source-based packages.pkg_addfor package management.pkgsrcfor package management.