[otb] 02/02: update amd64 symbols for 5.2

[Sebastiaan Couwenberg]

On 23-12-15 15:04, Rashad Kanavath wrote:
> On 12/23/2015 12:00 PM, Sebastiaan Couwenberg wrote:
>> On 23-12-15 11:36, Rashad Kanavath wrote:
>>> --- a/debian/libotbapplicationengine-5.2-1.symbols
>>> +++ b/debian/libotbapplicationengine-5.2-1.symbols
>>> @@ -1,21591 +1,20415 @@
>>> -# SymbolsHelper-Confirmed: 5.0.0 amd64 i386
>>> -libOTBApplicationEngine-5.0.so.1 libotbapplicationengine-5.0-1 #MINVER#
>>> ...
>>> +# SymbolsHelper-Confirmed: 5.2.0 amd64
>>> +libOTBApplicationEngine-5.2.so.1 libotbapplicationengine-5.2-1 #MINVER#
>> We renaming symbols files for a new SONAME, you also need to edit the
>> dependency line in the symbols file to match the name library SONAME and
>> package name.
>>
>> For this example that would become:
>>
>>   # SymbolsHelper-Confirmed: 5.0.0 amd64 i386
>>   libOTBApplicationEngine-5.2.so.1 libotbapplicationengine-5.2-1 #MINVER#
>>
>> dpkg-gensymbols will then keep the version history in the symbols file
>> instead of generating a completely new file for library SONAME. You have
>> now lost which symbols where introduced in 5.0 and not changed in 5.2.
> 
> Okay. I had removed and generated new symbol files!. Should I revert
> back the files and then update them again?
> 
> since package was not uploaded anywhere, I did this way.

Because the packages has been uploaded to the Debian archive, you don't
have to revert the symbols change, only if you really want to do it
correctly. Just make sure to follow this procedure next time. It's quite
valuable to see that reverse dependencies don't actually use the new
features by using the lower version in their dependencies. You see this
for GDAL rdeps for example, most depend on libgdal1i (>= 1.8.0) because
they don't use the features introduced in later versions (yet).

>> This is quite similar to the renamed lintian overrides, just renaming
>> the files is not sufficient, you also need to make minimal edits to the
>> files.
>
> I will correct this right away. Maybe we can use a .in file. What do you
> think ?

Using templates for the lintian overrides too makes sense.

>> Also try to keep your commits as single logical changes, the spelling
>> patch update does not belong in this commit.
> 
> spelling patch was a disaster on my side. It took some time for me to
> get into the quilt workflow.
> 
> I promise I will be careful next time.

I generally rebase my changes before pushing them to Alioth to make the
changes easier to review. Consider doing the same. Rebasing is one of
the core features of git, don't be afraid to use it. Just make sure you
only rebase the changes that haven't been pushed yet, rebasing changes
that are available on Alioth already will complicate updating all the
working copies out there.

There is also a good argument to not rebase, and keep a messy history to
reflect the messy nature of development. But I strongly prefer a clean
history for the packaging changes which make it easier for the lurkers
on the list to learn by example.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1