headers
Simon Josefsson | 7 Feb 14:47
Favicon
Gravatar

debian build of 0.35

Russ,

I'm building 0.35 now, to be able to give #423944 back to the inetutils
package.  There are minimal changes compared to 0.34, so it builds fine,
but I started to look at some of the warnings.

Several of the packages result in:

dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}

Isn't there a ${misc:Depends} variable?  Searching on the web yields a
lot of similar warning messages, but I didn't found how people solved
it.  Should we remove that dependency?

Then there are a bunch of warnings as below.  I suspect these are
related to

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390882

but I'm not sure whether it is useful to spend time to try to fix this
for this particular package, as I discussed in that bug report.  I don't
recall seeing the warning from dpkg-shlibdeps before, so maybe there has
been some policy change in debian?

I suspect to fully solve this, changes may be needed in the *.la file
from gnutls, libidn, libtasn1 etc too.  Alas, I'm upstream for those as
well..

/Simon
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 7 Feb 15:21
Favicon
Gravatar

Re: debian build of 0.35

Another issue came up when packaging 0.35, lintian complained:

W: shishi-dbg: dbg-package-missing-depends shishi
N:
N:   This package has a name of the form of "X-dbg", indicating it contains
N:   detached debugging symbols for the package X. If so, it should depend
N:   on the corresponding package, generally with (= ${binary:Version})
N:   since the debugging symbols are only useful with the binaries created
N:   by the same build.
N:

That was likely because 'shishi-dbg' only depend on libshishi (=
${binary:Version}), not the other packages for which it also contains
debugging information.

I did install the following fix:

-Depends: libshishi0 (= ${binary:Version})
+Depends: libshishi0 (= ${binary:Version}),
+ libshisa0 (= ${binary:Version}),
+ shishi (= ${binary:Version}),
+ shisa (= ${binary:Version}),
+ shishi-kdc (= ${binary:Version}),
+ libpam-shishi (= ${binary:Version})

But then I realized this probably isn't a good idea... a user should be
able to install 'shishi-dbg' without having to pull in shishi-kdc etc.

How can this be resolved?  Should there be one -dbg package for each
binary package?  I.e., libshishi0-dbg, libshisa0-dbg, shishi-dbg,
(Continue reading)

Permalink | Reply |
headers
Russ Allbery | 7 Feb 19:52
Favicon

Re: debian build of 0.35

Simon Josefsson <simon <at> josefsson.org> writes:

> Another issue came up when packaging 0.35, lintian complained:
>
> W: shishi-dbg: dbg-package-missing-depends shishi
> N:
> N:   This package has a name of the form of "X-dbg", indicating it contains
> N:   detached debugging symbols for the package X. If so, it should depend
> N:   on the corresponding package, generally with (= ${binary:Version})
> N:   since the debugging symbols are only useful with the binaries created
> N:   by the same build.
> N:
>
> That was likely because 'shishi-dbg' only depend on libshishi (=
> ${binary:Version}), not the other packages for which it also contains
> debugging information.
>
> I did install the following fix:
>
> -Depends: libshishi0 (= ${binary:Version})
> +Depends: libshishi0 (= ${binary:Version}),
> + libshisa0 (= ${binary:Version}),
> + shishi (= ${binary:Version}),
> + shisa (= ${binary:Version}),
> + shishi-kdc (= ${binary:Version}),
> + libpam-shishi (= ${binary:Version})
>
> But then I realized this probably isn't a good idea... a user should be
> able to install 'shishi-dbg' without having to pull in shishi-kdc etc.
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 7 Feb 20:30
Favicon
Gravatar

Re: debian build of 0.35

Russ Allbery <rra <at> stanford.edu> writes:

> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> Another issue came up when packaging 0.35, lintian complained:
>>
>> W: shishi-dbg: dbg-package-missing-depends shishi
>> N:
>> N:   This package has a name of the form of "X-dbg", indicating it contains
>> N:   detached debugging symbols for the package X. If so, it should depend
>> N:   on the corresponding package, generally with (= ${binary:Version})
>> N:   since the debugging symbols are only useful with the binaries created
>> N:   by the same build.
>> N:
>>
>> That was likely because 'shishi-dbg' only depend on libshishi (=
>> ${binary:Version}), not the other packages for which it also contains
>> debugging information.
>>
>> I did install the following fix:
>>
>> -Depends: libshishi0 (= ${binary:Version})
>> +Depends: libshishi0 (= ${binary:Version}),
>> + libshisa0 (= ${binary:Version}),
>> + shishi (= ${binary:Version}),
>> + shisa (= ${binary:Version}),
>> + shishi-kdc (= ${binary:Version}),
>> + libpam-shishi (= ${binary:Version})
>>
>> But then I realized this probably isn't a good idea... a user should be
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 13 Feb 16:49
Favicon
Gravatar

Re: debian build of 0.35

Russ Allbery <rra <at> stanford.edu> writes:

>> -Depends: libshishi0 (= ${binary:Version})
>> +Depends: libshishi0 (= ${binary:Version}),
>> + libshisa0 (= ${binary:Version}),
>> + shishi (= ${binary:Version}),
>> + shisa (= ${binary:Version}),
>> + shishi-kdc (= ${binary:Version}),
>> + libpam-shishi (= ${binary:Version})
>>
>> But then I realized this probably isn't a good idea... a user should be
>> able to install 'shishi-dbg' without having to pull in shishi-kdc etc.
>
> I think that's right, except that you want | instead of , between the
> dependencies.  That way, the debug package requires at least one package
> for which it provides debug symbols to be installed.
>
> I was going to do that when I added the dependency and then didn't.

It just occurred to me that, with |, couldn't the user have the proper
version of libshishi0 installed, but an old version of, say,
libpam-shishi?  The dependencies for shishi-dbg are satisfied via the
proper version of libshishi0, and the incorrect version of libpam-shishi
is not tested.  Then debugging of libpam-shishi would fail, potentially
even in bad ways.

The dependency relation that we want to express is that if any of the
shishi packages are installed, they must be of the same version as
shishi-dbg, if shishi-dbg is going to be installed.  Is that even
possible with dpkg?
(Continue reading)

Permalink | Reply |
headers
Russ Allbery | 13 Feb 19:14
Favicon

Re: debian build of 0.35

Simon Josefsson <simon <at> josefsson.org> writes:

> It just occurred to me that, with |, couldn't the user have the proper
> version of libshishi0 installed, but an old version of, say,
> libpam-shishi?  The dependencies for shishi-dbg are satisfied via the
> proper version of libshishi0, and the incorrect version of libpam-shishi
> is not tested.  Then debugging of libpam-shishi would fail, potentially
> even in bad ways.

Yes.  Of course, if the user wasn't interested in debugging libpam-shishi,
they wouldn't notice.

> The dependency relation that we want to express is that if any of the
> shishi packages are installed, they must be of the same version as
> shishi-dbg, if shishi-dbg is going to be installed.  Is that even
> possible with dpkg?

Only with something like Conflicts, and I think that gets too ugly to be
worth it and may lead to aptitude removing the wrong thing.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply |
headers
Simon Josefsson | 14 Feb 11:18
Favicon
Gravatar

Re: debian build of 0.35

Russ Allbery <rra <at> stanford.edu> writes:

> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> It just occurred to me that, with |, couldn't the user have the proper
>> version of libshishi0 installed, but an old version of, say,
>> libpam-shishi?  The dependencies for shishi-dbg are satisfied via the
>> proper version of libshishi0, and the incorrect version of libpam-shishi
>> is not tested.  Then debugging of libpam-shishi would fail, potentially
>> even in bad ways.
>
> Yes.  Of course, if the user wasn't interested in debugging libpam-shishi,
> they wouldn't notice.
>
>> The dependency relation that we want to express is that if any of the
>> shishi packages are installed, they must be of the same version as
>> shishi-dbg, if shishi-dbg is going to be installed.  Is that even
>> possible with dpkg?
>
> Only with something like Conflicts, and I think that gets too ugly to be
> worth it and may lead to aptitude removing the wrong thing.

Ok.  I'm uploading a new package with the fixes we have so far.  We can
always come back to this issue later, if it turns out to be any real
problem.

/Simon
Permalink | Reply |
headers
Russ Allbery | 7 Feb 21:40
Favicon

Re: debian build of 0.35

Simon Josefsson <simon <at> josefsson.org> writes:

> I'm building 0.35 now, to be able to give #423944 back to the inetutils
> package.  There are minimal changes compared to 0.34, so it builds fine,
> but I started to look at some of the warnings.
>
> Several of the packages result in:
>
> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
>
> Isn't there a ${misc:Depends} variable?  Searching on the web yields a
> lot of similar warning messages, but I didn't found how people solved
> it.  Should we remove that dependency?

This is a long-standing minor annoyance.  The recommendation is generally
to just leave it.  Basically: if there is anything that debhelper needs to
do in the maintainer scripts that creates additional dependencies, it will
add those dependencies to ${misc:Depends}.  However, if there are none, it
won't create the substvar, and you'll get warnings.  So you can remove it
if debhelper isn't creating it, but then if something changes about the
package later and you end up needing those dependencies, you have to add
it back in.

> Then there are a bunch of warnings as below.  I suspect these are
> related to
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390882
>
> but I'm not sure whether it is useful to spend time to try to fix this
> for this particular package, as I discussed in that bug report.  I don't
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 13 Feb 16:54
Favicon
Gravatar

Re: debian build of 0.35

Russ Allbery <rra <at> stanford.edu> writes:

> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> I'm building 0.35 now, to be able to give #423944 back to the inetutils
>> package.  There are minimal changes compared to 0.34, so it builds fine,
>> but I started to look at some of the warnings.
>>
>> Several of the packages result in:
>>
>> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
>>
>> Isn't there a ${misc:Depends} variable?  Searching on the web yields a
>> lot of similar warning messages, but I didn't found how people solved
>> it.  Should we remove that dependency?
>
> This is a long-standing minor annoyance.  The recommendation is generally
> to just leave it.  Basically: if there is anything that debhelper needs to
> do in the maintainer scripts that creates additional dependencies, it will
> add those dependencies to ${misc:Depends}.  However, if there are none, it
> won't create the substvar, and you'll get warnings.  So you can remove it
> if debhelper isn't creating it, but then if something changes about the
> package later and you end up needing those dependencies, you have to add
> it back in.

Ah, I understand.

>> Then there are a bunch of warnings as below.  I suspect these are
>> related to
>>
(Continue reading)

Permalink | Reply |

Gmane