brenekh / blinky Goto Github PK
View Code? Open in Web Editor NEWPacman repository hosting server.
License: GNU General Public License v3.0
Pacman repository hosting server.
License: GNU General Public License v3.0
I have an project written in Golang which is for building pacman repository, which is Hayao0819/ayaka
Now, ayaka has no functions to update db and upload it but has building package with devtools so your blinky has what my tools does not have.
What I would like to do is calling blinky from my ayaka through golang module. I am going to read blinky packages and implements it on my ayaka.
However, from Readme, blinky does not support another architecture. Could I ask you how to use it on multi architecture, x86_64 and pentium4 ?
My thought is that the only information that needs to be provided for removal is the package name.
If a key-value database is kept which contains the package name and the file that was uploaded for it, that can be used to identify the file that needs to be removed for a given package name, which greatly simplifies the API spec.
Currently users of the API have to provide the API key set by the server owner in the Authorization
HTTP header.
This approach is confusing for the user and doesn't allow the CLI to use one method to authenticate for both the integrated and possible third-party auth providers.
A better option is to allow the server owner to set both a username and a password. Then HTTP Basic Authentication can be used which will also allow third party auth solutions to work well.
By using /repo/<repo_name>
the root path can be reserved for future uses, and repo names such as api
won't interfere with those paths.
Instead of specifying a single repo path in $BLINKY_REPO_PATH
, multiple should be allowed using the same separator used for $PATH
.
If an admin wanted to, they should be able to require that a package be uploaded with a proper signature.
Optionally, the key could be verified by a web of trust local to Blinky. However, this may present more problems than solutions because setting up the web correctly will more than likely be hard to do.
I'm not sure how to make this work for both native and Docker installations, but a signed DB is almost a requirement of any serious software repository so it needs to be done in one way or another.
Blinky does not automatically create the database files when creating a repository for the first time. The user needs to upload a package before those files are created.
This means that pacman
will fail to pull the DB for an empty repo, because the DB files don't exist and Blinky can't serve them up.
Currently, there isn't a great way to upload and remove packages from Blinky. curl
commands will technically work, but there should be a more intuitive way to go about these tasks.
I'm thinking of a blinky
cli tool that will be able to login to various servers and upload/remove packages.
This should allow both signed and unsigned packages to be added to a repository.
Because signed packages require both the .pkg.tar.zst
and the .sig
files, the multiple file upload feature of HTTP Form Data will need to be leveraged as part of the API spec.
JSON is fine for testing and small scale deployments, but a more robust key-value store should be used to make Blinky more robust.
Badger looks like a good candidate for this job.
The configuration toml file locations are hardcoded and cannot be set, but ConfigDir
makes it sound as though that is modifiable.
ConfigDir
is actually used for the database so a more appropriate name would be DataDir
.
Currently the API just takes the client at face value when it gives the package name to use for file association in the Blinky database. (repo-add
parses the package and uses the name in the file) This obviously could lead to issues, maybe even security problems if one were to use a misbehaving client.
The solution is to move the name extraction to the server and use the name inside of the *.pkg.tar.zst
instead. This also lays some groundwork for parsing the architecture and sorting the package into the correct "sub" repository.
While performing this change, it also makes sense to change the API so that uploading a package is just PUT /<repo name>/package
instead of PUT /<repo_name>/package/<package_name>
, as it makes more sense if the server is no longer relying on the client for the package name.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.