[SCM] mplayer packaging branch, ubuntu, updated. debian/1.0.rc3++final-0ubuntu2

[Reinhard Tartler]

On Do, Jun 03, 2010 at 18:41:24 (CEST), Felipe Sateler wrote:

> On Thu, Jun 3, 2010 at 12:32, Reinhard Tartler <siretart at tauware.de> wrote:
>>>>>  # Build architecture-independent packages
>>>>>  binary-indep: install-indep
>>>>> diff --git a/debian/source/format b/debian/source/format
>>>>> index d3827e7..163aaf8 100644
>>>>> --- a/debian/source/format
>>>>> +++ b/debian/source/format
>>>>> @@ -1 +1 @@
>>>>> -1.0
>>>>> +3.0 (quilt)
>>>>> diff --git a/debian/source/options b/debian/source/options
>>>>> new file mode 100644
>>>>> index 0000000..98a0c1a
>>>>> --- /dev/null
>>>>> +++ b/debian/source/options
>>>>> @@ -0,0 +1,2 @@
>>>>> +single-debian-patch
>>>>
>>>> this fixes the filename of the generated patch.
>>>
>>> I'm not quite sure this is correct... You already have
>>> debian/patches/*. What is your intended purpose with this flag?
>>
>> ,----[From the dpkg-source(1):
>> |
>> |  --single-debian-patch
>> |
>> |         Use debian/patches/debian-changes instead of
>> |         debian/patches/debian-changes-version for the name of the
>> |         automatic patch generated during build. This option is
>> |         particularly useful when the package is maintained in a VCS
>> |         and a patch set can't reliably be generated. Instead the
>> |         current diff with upstream should be stored in a single
>> |         patch. When using this option, it is recommended to create a
>> |         debian/source/patch-header file explaining how the Debian
>> |         changes can be best reviewed, for example in the VCS that is
>> |         used.
>> |
>
> I have already read that, thanks. What I mean is why do you want it
> enabled, *if you already have patches in debian/patches*?. In other
> words, why is the version suffix not desired? Note that this would
> only apply for autogenerated patches (for example, in a NMU).

hm. actually, good question. My main motivation was to make the naming
not dependent on getting the version number right in debian/changelog.
But since those patches are not intended to be committed under this name
anyways, this is probably a rather weak argument...

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4