creating private versions of public packages with changes (naming & versioning issue)
lists at avi.co
Mon Oct 21 18:44:50 UTC 2013
Michael Barrett wrote:
> 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.
This is how I tend to do it, with similar problematic caveats that I've
only just had to think about actually considering in anger.
> 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.
> 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.
My current (untested) favoured option is to increment the epoch; for
example when I repackage libpcap which is currently:
I'll probably create one that comes out like this:
which guarantees that it will always be higher-versioned than the debian
package, but also mean I can encode in the version string where it came
from so I know what it's 'my' version of.
Unfortunately, my reading of the Debian policy doesn't suggest a
'proper' way to deal with this - having my own version of the Debian
package that I wish to always be preferred to the equal-versioned Debian
one. That said, I didn't think to mail the user lists and see what
anyone else was doing :)
More information about the ubuntu-users