Should PPAs be forced to specify a ~ppa1 or similar in the package version?

[Scott Ritchie]

On 04/02/2011 08:29 AM, Raphaël Pinson wrote:
> On Sat, Apr 2, 2011 at 5:19 PM, Scott Ritchie <scott at open-vote.org> wrote:
>> On 04/02/2011 08:08 AM, Felix Geyer wrote:
>>> On 02.04.2011 16:36, Scott Kitterman wrote:
>>>> My practice is to us ~ppa1 when targeting the development release and
>>>> ~release1~ppa1 for previous releases.  This has the advantage of naturally
>>>> upgrading to an official backport if one is done since they use a ~releaseX
>>>> numbering scheme.  For all the reasons Scott argued for ~ppaX, I think
>>>> ~release1~ppaX is the right answer for non-development releases
>>>
>>> That version scheme breaks once we are in the q-series as the p-codename
>>> might be > "ppa".
>>>
>>>
>>
>> Shouldn't official backports replace ppa packages anyway?
>>
> 
> That release depends on the goal of the PPA. If it's just to provide
> backport versions, then sure, that makes sense. But if the PPA
> provides additional features (some bindings activated, a compilation
> flag set, etc.), then no. I think though that it's the sysadmins' task
> to set their apt_preferences correctly in order to ensure that they
> get the version they consider to be prioritary. Backports and PPAs
> provide versions, but it's up to the machine admin to choose which
> version to install.
> 
> 

Of course things like apt pinning are going to be the ultimate arbiter,
but it would be nice to do what we can within the naming standards since
it's so much simpler to deal with.  At the very least we can have some
defaults to expect (eg ppas will be replaced by packports unless the ppa
specifies a release version)

-Scott Ritchie