when not to use an epoch and how to avoid a sync

[Alberto Milone]

On 06/05/2011 10:30 AM, Micah Gersten wrote:
> On 06/04/2011 05:25 AM, Alberto Milone wrote:
>> nvidia-common (1:0.2.30+1) oneiric; urgency=low
>>
>> * Add epoch to override the sync. The packages in Debian and Ubuntu
>> have the same name but different code and scope (LP: #792576).
>>
> 
> So, in Ubuntu we have a sync blacklist to avoid syncing something from
> Debian.  There's no need to add an epoch to avoid this.  In fact, adding
> an epoch will not necessarily help, since you never know when Debian
> will add one as well.
> 
> The process for requesting something to be blacklisted from being sync'd
> from Debian is to simply file a bug against the package and subscribe
> ubuntu-sponsors if you cannot upload the package (to verify if this is
> indeed the correct course of action) or subscribe ubuntu-archive and set
> the status to confirmed if you can upload the package.
> 
> Adding an epoch makes it harder to get back in sync with Debian.  It
> requires manual intervention until Debian has a situation where they add
> a similar epoch.  Granted, that for this package, it might not happen
> for a while; but, if we ever were to get these packages in sync, we are
> now stuck with the epoch forever.
> 
> Generally, people have been using BAD_VERSION+reallyGOOD_VERSION when
> something like this happens to avoid having to add an epoch.
> 
> IMHO, epochs should not be used in Ubuntu at all for this very reason.
> 
> In order to prevent autosyncs in the future, one can use an x.y-0ubuntu1
> or x.yubuntu1 version scheme.
> 
> Micah
> 

Hi Micah,

I don't plan on syncing my package with the one in Debian as, put
simply, they are too different in scope and it's just a coincidence that
now they share the same name. This is why I decided to use an epoch
instead of having something as 20110426+1+really0.2.x (which, in this
case, I found unnecessarily ugly).

Furthermore I knew that Steve Langasek had already blacklisted
nvidia-common and, in the light of these facts, I made my choice as a
maintainer and upstream author.

Regards,

-- 
Alberto Milone
Sustaining Engineer (system)
Premium Engagements Team
Canonical OEM Services