Debian Bug report logs - #630344
dpkg-gensymbols: Add support for private symbol tag

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: Guillem Jover <guillem@debian.org>

Date: Mon, 13 Jun 2011 06:33:05 UTC

Severity: wishlist

Found in version dpkg/1.16.0

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#630344; Package dpkg-dev. (Mon, 13 Jun 2011 06:33:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 13 Jun 2011 06:33:09 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: submit@bugs.debian.org
Subject: dpkg-gensymbols: Add support for private symbol tag
Date: Mon, 13 Jun 2011 08:29:10 +0200
Package: dpkg-dev
Version: 1.16.0
Severity: wishlist
User: dpkg@packages.debian.org
Usertags: dpkg-gensymbols

Hi!

It would be nice to have a private tag which would have the following
semantics:

 * any symbol marked as such could not be used by any external package,
   it would produce a fatal error at dpkg-shlibdeps time.
 * such symbols could be used by binary packages produced from the same
   source package.
 * probably they should be non-optional by default, as there's the
   optional tag already, and there's no way to mark a symbol as
   non-optional anyway.

So while this could alternatively be achieved by modifying upstream
source, with one of the following methods: advanced or simple symbol
versioning, symbol visibility or an export map; it might not be always
desirable to diverge from upstream on this. So having support for
this in Debian would allow package maintainers to disallow external
dependencies on interfaces which are not supposed to be used.

The biggest issue I see is how to transport that information from
the symbols pattern file in the source to the binary package.

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#630344; Package dpkg-dev. (Mon, 13 Jun 2011 08:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 13 Jun 2011 08:06:03 GMT) Full text and rfc822 format available.

Message #10 received at 630344@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Guillem Jover <guillem@debian.org>, 630344@bugs.debian.org
Subject: Re: Bug#630344: dpkg-gensymbols: Add support for private symbol tag
Date: Mon, 13 Jun 2011 10:03:19 +0200
On Mon, 13 Jun 2011, Guillem Jover wrote:
> Package: dpkg-dev
> Version: 1.16.0
> Severity: wishlist
> User: dpkg@packages.debian.org
> Usertags: dpkg-gensymbols
> 
> Hi!
> 
> It would be nice to have a private tag which would have the following
> semantics:
> 
>  * any symbol marked as such could not be used by any external package,
>    it would produce a fatal error at dpkg-shlibdeps time.
>  * such symbols could be used by binary packages produced from the same
>    source package.
>  * probably they should be non-optional by default, as there's the
>    optional tag already, and there's no way to mark a symbol as
>    non-optional anyway.
> 
> So while this could alternatively be achieved by modifying upstream
> source, with one of the following methods: advanced or simple symbol
> versioning, symbol visibility or an export map; it might not be always
> desirable to diverge from upstream on this. So having support for
> this in Debian would allow package maintainers to disallow external
> dependencies on interfaces which are not supposed to be used.
> 
> The biggest issue I see is how to transport that information from
> the symbols pattern file in the source to the binary package.

Since private symbols are not to be used outside of the source package,
we can just invent a special value to use in the associated minimal
version field.
 symbol@Base *private*

If that's not ok, then the easiest is to add a supplementary (optional)
field/column on each symbol line. But it requires to make the dependency
number explicit in the cases where it was omitted.
 symbol@Base 1.2-3 0 private

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#630344; Package dpkg-dev. (Sun, 24 Jul 2011 16:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 24 Jul 2011 16:03:07 GMT) Full text and rfc822 format available.

Message #15 received at 630344@bugs.debian.org (full text, mbox):

From: Modestas Vainius <modax@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Guillem Jover <guillem@debian.org>, 630344@bugs.debian.org
Subject: Re: Bug#630344: dpkg-gensymbols: Add support for private symbol tag
Date: Sun, 24 Jul 2011 18:59:04 +0300
[Message part 1 (text/plain, inline)]
Hello,

On pirmadienis 13 Birželis 2011 11:03:19 Raphael Hertzog wrote:

> Since private symbols are not to be used outside of the source package,
> we can just invent a special value to use in the associated minimal
> version field.
>  symbol@Base *private*
> 
> If that's not ok, then the easiest is to add a supplementary (optional)
> field/column on each symbol line. But it requires to make the dependency
> number explicit in the cases where it was omitted.
>  symbol@Base 1.2-3 0 private

What do you think about using a negative dependency template id in order to 
trigger dpkg-shlibdeps failure? In my opinion, it's still useful (for 
reference purposes) to have version information even for private symbols.

Negative dependency template would be treated like its abs() value except 
dpkg-shlibdeps would fail if the symbol file was from the external package. 
However, yet I haven't tested how dpkg-gensymbols from squeeze handles 
negative IDs. Hopefully, it fails in some (weird) way :)

P.S. I plan to work on #615940, #630342 and #630344 in the next 
days/weeks/month. Maybe I will even propose something acceptable for #533916 
in the process.

-- 
Modestas Vainius <modax@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#630344; Package dpkg-dev. (Sun, 24 Jul 2011 19:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 24 Jul 2011 19:45:06 GMT) Full text and rfc822 format available.

Message #20 received at 630344@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Modestas Vainius <modax@debian.org>, 630344@bugs.debian.org
Cc: Guillem Jover <guillem@debian.org>
Subject: Re: Bug#630344: dpkg-gensymbols: Add support for private symbol tag
Date: Sun, 24 Jul 2011 21:42:10 +0200
Hi,

On Sun, 24 Jul 2011, Modestas Vainius wrote:
> What do you think about using a negative dependency template id in order to 
> trigger dpkg-shlibdeps failure? In my opinion, it's still useful (for 
> reference purposes) to have version information even for private symbols.

Could be workable I guess. Except that the negation of 0 doesn't exist, so
it forces you to have at least one extra dependency template. 

> P.S. I plan to work on #615940, #630342 and #630344 in the next 
> days/weeks/month. Maybe I will even propose something acceptable for #533916 
> in the process.

Are you at debconf this week?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#630344; Package dpkg-dev. (Sun, 24 Jul 2011 19:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 24 Jul 2011 19:51:03 GMT) Full text and rfc822 format available.

Message #25 received at 630344@bugs.debian.org (full text, mbox):

From: Modestas Vainius <modax@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 630344@bugs.debian.org, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#630344: dpkg-gensymbols: Add support for private symbol tag
Date: Sun, 24 Jul 2011 22:49:00 +0300
[Message part 1 (text/plain, inline)]
Hello,

On sekmadienis 24 Liepa 2011 22:42:10 Raphael Hertzog wrote:
> Hi,
> 
> On Sun, 24 Jul 2011, Modestas Vainius wrote:
> > What do you think about using a negative dependency template id in order
> > to trigger dpkg-shlibdeps failure? In my opinion, it's still useful (for
> > reference purposes) to have version information even for private
> > symbols.
> 
> Could be workable I guess. Except that the negation of 0 doesn't exist, so
> it forces you to have at least one extra dependency template.

That might be an advantage to a certain degree, i.e. the default (0) template 
can never be private by design. However, if the maintainer aim is to always 
fail when a private symbol is referenced (either locally or externally), 
symbol dep_id could point to a non-existing template.

> > P.S. I plan to work on #615940, #630342 and #630344 in the next
> > days/weeks/month. Maybe I will even propose something acceptable for
> > #533916 in the process.
> 
> Are you at debconf this week?

Nope.

-- 
Modestas Vainius <modax@debian.org>
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 16:54:11 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.