creating private versions of public packages with changes (naming & versioning issue)

[Avi Greenbury]

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:

 libpcap0.8   1.1.1-2+squeeze1

I'll probably create one that comes out like this:

 libpcap0.8   1:1.1.1-2+squeeze1

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 :)

-- 
Avi