3 ms·

I love this! But I have to admit I'm a little confused. Is this mostly for large repositories? I ship some software on multiple platforms and part of my build

by cheez 10y ago

I love this! But I have to admit I'm a little confused. Is this mostly for large repositories? I ship some software on multiple platforms and part of my build process builds an apt repo (available over HTTP) as follows: run_gpg_command dpkg-sig -g " --yes" \ --sign builder *.deb && \ rm -rf repo && \ mkdir repo && \ cp *.deb repo && \ cd repo && \ (dpkg-scanpackages . /dev/null > Packages) && \ (bzip2 -kf Packages) && \ (apt-ftparchive release . > Release) && \ (run_gpg_command gpg --yes -abs -o Release.gpg Release) && \ (gpg --export --armour > archive.key) Then I sync it to S3 using aws s3 sync. What are the problems doing it this way?

daenney 10y ago
It's not just for large repos. The idea is that you can just build your package, drop it in S3 and the rest is taken care of. You don't need to generate the rest of the metadata yourself, like the Packages or Release file. It does however not address the issue of signing in this case. Would be interesting to see if someone can extend it using an additional bucket to store credentials with the necessary policies to only allow the Lambda function to get and use them.
- cheez 10y ago
  Seems to me that it's not really beneficial for most small software publishers in that case. They can just use a variant of the script I posted above, I suppose.
szinck 10y ago
I use it for "small"ish repos. Mainly I don't want to maintain a copy on disk. I have a list of (and tooling around) what all .debs go in a release, and copy from a master S3 location to the correct apt repo s3 location, and the Packages index gets generated automatically. So I just create a new repo each time but not every .deb changes each time. Other architectural issues kind of drove the need to move to S3, and at that point I wanted to see if I could just keep everything in S3.

by cheez 10y ago

daenney 10y ago

It's not just for large repos. The idea is that you can just build your package, drop it in S3 and the rest is taken care of. You don't need to generate the rest of the metadata yourself, like the Packages or Release file. It does however not address the issue of signing in this case. Would be interesting to see if someone can extend it using an additional bucket to store credentials with the necessary policies to only allow the Lambda function to get and use them.

cheez 10y ago
Seems to me that it's not really beneficial for most small software publishers in that case. They can just use a variant of the script I posted above, I suppose.

szinck 10y ago

I use it for "small"ish repos. Mainly I don't want to maintain a copy on disk. I have a list of (and tooling around) what all .debs go in a release, and copy from a master S3 location to the correct apt repo s3 location, and the Packages index gets generated automatically. So I just create a new repo each time but not every .deb changes each time. Other architectural issues kind of drove the need to move to S3, and at that point I wanted to see if I could just keep everything in S3.