Repackaging a Universal Package – The RIGHT Way

Presenter: Kevin Griffin of SwiftKick Training, and an Inedo-certified Master Trainer

Note: The following text is a transcript of the video, with minor edits for readability.

Now there are cases, where you need to change a file, but you still want to maintain that hash. So usually the thing that you want to change is the version, you don’t want to change the contents of the package.

Repackaging in UPack

UPack has a feature that does exactly this. It allows you to change the version of the package without altering the hash of the file. So, it’s still cryptographically verifiable, it’s just an actual release version. This commonly happens when you go from a pre-release to a full release. So, we had 1.0.1-beta or alfa or RC out there in the wild and it’s ready to go. Now we want to make that the official 1.0.1 package, but we don’t want the hashes to change.

And I love this illustration. You can see that we have Beta, which is X34A…etc, we need that to be the same when the package goes for release.


Let’s walk through an example and see if we can do the same thing in our environment. So, I have my code, and I’m going to go into my manifest. We’re going to create 1.0.2-beta and we’re going to then pack it, and I’m going to publish it. Actually, I probably don’t have to publish it, but we’re going to publish it anyway so you can get used to the publishing workflow. So, what did I call it? Beta? 1.0.2-beta. Nope, I got the file name wrong. Oh, it’s still a 1.0.2.upack, but it’s beta underneath the scenes.

What not to do

Alright, so that’s published, let’s go back over here to ProGet and take a look at it. We’ll see that is currently uploaded. So 1.0.2-beta. Now what I want to do is, there’s the hash, 836…etc. Now lets go through and change that version myself, which I can technically do. Let’s go into UPack and let’s edit that file. UPack was modified, so let’s update it in the archive. Now let’s do a UPack hash command on CurrentTime-1.0.2, now it’s a different hash! Which is not what we want. That’s bad.

Lets Make it Right

Alright, let’s recreate our package again, so I’m working with a good square. So let’s say this is now 1.0.3 beta. We are going to recreate it and we’re going to re-push it. Alright, so that is published, let’s come over and take a look at it, 1.0.3 is installed. Alright, 4cc…etc, that’s the SHA. Now, what I want to do is, I want to convert this. I’m going to do this from memory, so likely I am going to screw it up.

Lets Repack!

We want to repack. Alright, here’s all the information about repack:

Usage: upack repack «source» [--targetDirectory=«targetDirectory»] [--newVersion=«newVersion»] [--note=«note»] [--overwrite]

Creates a new ProGet universal package by repackaging an existing package with a new version number and audit information.

source - The path of the existing upack file.
targetDirectory - Directory where the .upack file will be created. If not specified, the current working directory is used.
newVersion - New package version to use.
note - A description of the purpose for repackaging that will be entered as the audit note.
overwrite - Overwrite existing package file if it already exists.  

We want to repack CurrentTime-1.0.3 and I want to give it a new version, we are going to give it 1.0.3. I think I should do this in quotes. There we are. Then I’m going to say overwrite, just in case.

upack repack CurrentTime-1.0.3.upack --newVersion="1.0.3" --overwrite

Alright, so I updated. Let’s do a hash of CurrentTime-1.0.3 and what should happen is, that this hash, from just updating the version, should be the same hash.

Moving on…

Next Training Snippet   ➔

Customized Training

Our training courses are built modularly, and we can develop a customized training roadmap for your organization, so that everyone gets the training they need, when they need it.