Freight refactor for Debian archiving #3

Merged
mycognosist merged 22 commits from freight_refactor into main 2020-12-16 13:27:56 +00:00
mycognosist commented 2020-12-16 13:27:45 +00:00 (Migrated from github.com)

The setup script and supporting configuration files have been updated to utilize Freight as a Debian archive creator / manager in place of reprepro.

The major issue with reprepro was the inability to serve multiple versions of a single .deb. This would have been a problem if we ever wanted to downgrade an installed microservice or install one particular version among many.

Detailed setup and usage instructions have been added to the README.

The setup script and supporting configuration files have been updated to utilize [Freight](https://github.com/freight-team/freight) as a Debian archive creator / manager in place of [reprepro](https://wikitech.wikimedia.org/wiki/Reprepro). The major issue with reprepro was the inability to serve multiple versions of a single `.deb`. This would have been a problem if we ever wanted to downgrade an installed microservice or install one particular version among many. Detailed setup and usage instructions have been added to the README.
mhfowler commented 2020-12-18 07:23:43 +00:00 (Migrated from github.com)

@mycognosist this looks good

when you run the script, does it simply replace any packages it finds in the freight library with the same version number if one with the same version number exists?
I imagine this is documented in freight, but could be good to add a comment about this to the README

also seeing this all together now, and the way we are manually doing a lot of stuff on the VPS,
I could see moving the "install rust + cargo + cross-compilation" into its own script, or just not having it as part of the script
(I know I originally wrote that, but kind of a carry over from the ansible "from scratch paradigm" and I could also see this just being a freight-specific script so its more modular)

@mycognosist this looks good when you run the script, does it simply replace any packages it finds in the freight library with the same version number if one with the same version number exists? I imagine this is documented in freight, but could be good to add a comment about this to the README also seeing this all together now, and the way we are manually doing a lot of stuff on the VPS, I could see moving the "install rust + cargo + cross-compilation" into its own script, or just not having it as part of the script (I know I originally wrote that, but kind of a carry over from the ansible "from scratch paradigm" and I could also see this just being a freight-specific script so its more modular)
mhfowler commented 2020-12-18 07:47:35 +00:00 (Migrated from github.com)

(*also don't feel like it needs to be changed further just sharing that I agree with the feeling you mentioned earlier that that could be broken out)

(*also don't feel like it needs to be changed further just sharing that I agree with the feeling you mentioned earlier that that could be broken out)
mycognosist commented 2020-12-18 09:36:39 +00:00 (Migrated from github.com)

@mhfowler

when you run the script, does it simply replace any packages it finds in the freight library with the same version number if one with the same version number exists?

The package is not replaced if that particular version already exists in the Freight library (I think of the library as the staging area, with the cache being the actual archive from which packages are retrieved by a remote user). I've added a note about this behaviour to the readme.

I've separated the single script into setup_build_env.py and build_packages.py. PR here: https://github.com/peachcloud/peach-vps/pull/5

@mhfowler > when you run the script, does it simply replace any packages it finds in the freight library with the same version number if one with the same version number exists? The package is not replaced if that particular version already exists in the Freight library (I think of the library as the staging area, with the cache being the actual archive from which packages are retrieved by a remote user). I've added a note about this behaviour to the readme. I've separated the single script into `setup_build_env.py` and `build_packages.py`. PR here: https://github.com/peachcloud/peach-vps/pull/5
Sign in to join this conversation.
No description provided.