<div dir="ltr">For a while now I've been modifying public packages with various patches, etc for private use at various companies.  In all this time I've been able to make that work decently well, but I ran into an issue today with a package I did this with (nginx) and realized that I have tried a few different ways to deal with this issue, but I'm not sure what the best way to go is.<div>
<br></div><div>Basically it comes down to how you name/version these private packages.  In the nginx example I went ahead and just used dch -i to increment the version, which was fine - until the real package was upgraded.  In general this is fine because I use pinning to make sure that my private repos come first.  That said pinning doesn't seem to affect calls to 'apt-get source' so now when I attempt to get my source package to change it I end up with the public version that has a newer version string.</div>
<div><br></div><div>Another way I've done this is by prepending something to the name of the package - so, for example, nginx would become <company_abbreviation>-nginx.  I make sure that the new  packages have a Conflicts: set to the old named version of the package.  This works well, but it becomes more complicated when you start to deal with libraries.  You end up needing to then create personal versions of the things that use those libraries (sometimes other libraries).. and so on down the chain.  This doesn't seem very efficient.</div>
<div><br></div><div>I've also thought about trying to come up with a version string that is unlikely to be trumped by the 'real' versions of the packages - instead of going from 0ubuntu1 to 0ubuntu2, I instead change it to something like 7ubuntu1.  This works, but it feels a little weak.</div>
<div><br></div><div>Anyway, I'm curious how people deal with this - and if there's a standard way to do this that I haven't yet found.<br><br>My apologies if there is a better list for this - and thanks for your help!<br>
<div><br></div>-- <br>Michael Barrett
</div></div>