MOTU Application

[Laurent Bigonville]

On Mon, 24 Sep 2007 20:35:20 +0200
Stefan Potyra <sistpoty at ubuntu.com> wrote:

> Hi Laurent,
Hi,
> Since I'm not too comfortable in rating your technical ability with only the 
> feedback from Daniel and Sebastien, let's try s.th. new: This time I have a 
> few technical questions for you to answer:
> 
> 1) What does the number of "Standards-Version" in debian/control stand for? 
> When should you change it? What do you need to make sure when doing so?

The "Standards-Version" refers to the debian-policy version (currently
3.7.2(.2)). It should be bumped when the debian-policy is updated.
Before doing this, you must check that the package is still conforms
with the new policy(and running lintian or so).

> 2) You upgrade a library, which has the same SONAME as the current one. What 
> do you need to check when upgrading the package and how? After checking, you 
> find out that the SONAME upstream provided is sane. Nonetheless, the library 
> has new functions added. What debhelper command should you use for this 
> purpose with what argument? In which situations is not doing so harmful?

Must check that there are no API/ABI breakage (no previously exported
function removed, no changes in functions arguments, no changes in
exported structures). If there are new exported functions, the shlibs
version must be bumped by increasing the version in the -V argument of
dh_makeshlibs. Not doing so could cause problems if an application uses
a newly exported function but an older version of the library is
installed.

> 
> 3) Is it safe to publish a modified source package together with a 
> signed .changes file before you upload it to ubuntu? Is it safe after you 
> uploaded it? Why/why not?

With a signed .changes file anybody could upload it to Ubuntu (if the
key is in the keyring) even if you don't want it.
I don't see any harm in publishing the .changes file after the package
entering in the archive (even debian do this).

> 
> 4) You want to investigate a debdiff between two versions of a package, which 
> contain many changes. You're especially interested in the changes done inside 
> the debian directory. How can you generate a diff with only these changes?

interdiff -p1 -z old.diff.gz new.diff.gz
or
debdiff old.dsc new.dsc|filterdiff -i "*/debian/*"

Or if you only have the debdiff file:
filterdiff -i "*/debian/*" debdiff.diff

> 
> 5) In a debian source package, there always is a file debian/control. The 
> binary package also contains a control file. What is the correlation between 
> these two? Why should debian/control never get modified during building?

The two files are almost the same. The one in the binary package only
contains the relevant part of the debian/control that concerns the
binary package, variables (like dependencies..) get their value set by
the debhelper tools.
I'm not really sure, but modify the debian/control could causes
unpredictable results since all debhelper tools rely on it to build the
package.

> 
> Ok, enough questions for now.
> 
> Cheers,
>     Stefan.
Best regards,
Bigon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/motu-council/attachments/20070925/64d2f24b/attachment.pgp