RFC: support non-flatpak repositories #37
Conversation
| req.has_token_prefix(ref_parts[1]) | ||
| }, | ||
| _ => Err(ApiError::BadRequest(format!("Invalid ref_name {}", ref_name))), | ||
| _ => Ok(()), // Err(ApiError::BadRequest(format!("Invalid ref_name {}", ref_name))), |
There was a problem hiding this comment.
I think rather than completely removing the check, it would be better to add a configuration option to disable it.
There was a problem hiding this comment.
Or maybe make it non-fatal, but still logged?
There was a problem hiding this comment.
I don't think allowing any refs at all is a good idea. Clients can then e.g. replace appstream/x86_64 or other internal "trusted" refs. Allowing some prefix seems better.
|
Hi, I would love this option. I'm looking for a way to distribute CLI apps and SDK in a fashion similar to how sdkman.io and node version manager https://github.com/nvm-sh/nvm operate. I'm thinking of doing this like flatpak but without sandboxing since CLI apps are hard to configure for sandboxing. IMO having this option will expose more people to ostree and flatpak style of building apps and help with the migration. Also it will be exploratory for how CLI apps can be sandboxed more or isolated. I also believe that having developer tools distributed with this tech will expose more developers and increase adoption. Looking forward to any news about this feature. |
abderrahim
force-pushed
the
general_ostree
branch
from
6d2f0d7 to
031339c
Compare
4 participants
We were discussing the possibility of maintaining non-flatpak ostree repositories using flat-manager. This is a quick and dirty "what does it take to make it work?" hack.
In fact, not much.
flatpak build-commit-fromseems to cope well with non flatpak refs, except that they need to be specified explicitly on the command line. The other change is removing the check for invalid refs.I guess endless people may be interested too, but I'm not sure who to ping.
CC: @barthalion @valentindavid