Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
Maytham Alsudany writes: > In early 2022, Guillem added support for a new Static-Built-Using field to > dpkg, encouraging packagers to use it over Built-Using to specify > statically-linked dependencies [2]. The commit message states the following: > > This field mimics the previous Built-Using field semantics, but is > specifically intended for shadow dependencies stemming from static builds. > > In Debian, the Rust and Go teams agreed to use this language agnostic field, > instead of one for each of the languages. This means it can be easily > supported by dpkg, and can be used by other languages and run-times. > > This was also added to the deb-control(5) manpage, specifically > differentiating > it from Built-Using as a field to be used "for static building purposes (for > example linking against static libraries, builds for source-centered languages > such as Go or Rust[...])". > > The proposed change is to clarify and formally mandate the requirement to > declare statically-linked libraries used to build packages containing binaries > in Static-Built-Using. Attached is a draft patch of the proposed change. > Feedback is welcome! I think there is a gap between "statically linked libraries" and "builds for source-centered languages" -- could it be clarified if Static-Built-Using is intended to cover situations where package A incorporate source code from package B and source code from B affects whatever goes into the binary package of A? That is definitely true for statically linked libraries. I'm thinking of how gnulib C code is included in many packages, which could be set up to work in a way similar to how Go packages work. I just made 'libntlm' use the 'gnulib' package this way, to reduce xz-related risks with vendored gnulib code. Should libntlm's debian/control now include a 'Static-Built-Using: gnulib'? /Simon signature.asc Description: PGP signature
Bug#1064454: debian-policy: Restrict deb822 field names more
Would it make sense to change this to use an inclusive list of permitted characters instead? How about checking the field names that is in use today, and construct a regexp of permitted symbols out of that? Starting point: [A-Za-z][A-Za-z0-9-_]* /Simon signature.asc Description: PGP signature
Bug#987930: Rendering typo regarding bug title of package removal requests
Package: developers-reference Hi! The bug title suggestion for package removal requests on this page: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removing-packages is rendered (at least in firefox on debian) as: The bug title should be in the form RM:package Note that there is no space between 'RM:' and 'package'. I literally copied this form from the webpage when I made a bug request now [1], and then realized everyone else used the 'RM: package' form. The source code says: ``RM:``\ *package[architecture list]*\ ``--``\ *reason*, where *package* so my idea of coming up with a quick patch didn't work out, since it appears it does include a space. I'm not sure how to fix it, so I'll just report it. /Simon [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987928 signature.asc Description: PGP signature
Bug#475101: obsolete linuxthreads requirement
Russ Allbery r...@debian.org writes: p Libraries should be built with threading support and to be thread-safe if the library supports this. /p Yes, that's what I'm proposing -- at a guess, you may have misread the diff? diff --git a/policy.sgml b/policy.sgml index bad28af..1ffe148 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7225,10 +7225,10 @@ INSTALL = install -s # (or use strip on the files in debian/tmp) for C files) will need to be compiled twice, for the normal case. /p + p - You must specify the gcc option tt-D_REENTRANT/tt - when building a library (either static or shared) to make - the library compatible with LinuxThreads. + Libraries should be built with threading support and to be + thread-safe if the library supports this. /p Sorry, for some reason I must have completely missed the '-' in your patch. Then +1 from me. Hm. There is a small risk that the above will be interpreted to mean that e.g. pthreads should be enabled if supported by the library, but that is not always the best solution -- consider if a library supports native linking to pthreads, nptl, GNU Pth, or no thread library but require the application to provide mutex callbacks. (We are actually considering something like that for GnuTLS now, so it is not entirely hypothetical.) I would argue that the best for debian would be to build the library in the last configuration. Or can we declare that Debian only supports one thread package? The problem, of course, is that some applications will be using pthreads and some will use nptl, and linking libraries that are hard-coded to use pthreads (or nptl) will not work well. However, I suspect the wording above is sufficient, and that it is not a good idea to go into more details in a policy document. I just wanted to float this concern, to see if it sparks thoughts in anyone else. /Simon -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739vybaqs@mocca.josefsson.org
Bug#475101: obsolete linuxthreads requirement
Russ Allbery r...@debian.org writes: Russ Allbery r...@debian.org writes: Kurt Roeckx k...@roeckx.be writes: So it looks to me that _REENTRANT is only used to make some functions like getlogin_r available. I believe that's correct, and the discussion at the last DebConf reached the same conclusion. I think this bit in Policy is obsolete. I already closed a Lintian bug about it a while back. You may separately need _REENTRANT to get prototypes, but using the right feature test macros to get prototypes is a completely different issue and I don't think we need to leave this in Policy just for that (otherwise, we'd need to talk about GNU_SOURCE and whatnot as well, and I don't see a need to go there right now). I think that libraries in Debian should never change behaviour based on _REENTRANT. If a library can be build to either support threads or not, it should be compiled to support threads. It might also want to provide one that does and one that doesn't so that you can link to either one, but I would like to discourage that, and the default library should be the one that supports threads. And if it does provide 2 libraries, the header files for both should be the same and not depend on _REENTRANT. I think I agree. Could someone propose a wording change to Policy to say what we really mean here rather than focusing on _REENTRANT? Here's an attempt at that. I'm not sure if this says everything that needs to be said, but I'm not sure what else to say. I considered saying, as Kurt does above, that two libraries could be provided, one with thread support and one without, but this poses some serious problems because both libraries could be loaded into the same process space and then conflict. Doing this properly requires symbol versioning or some other similar mechanism, and at that point I think we're getting into something that's too difficult and specific to describe in Policy. I think I'd rather just let the should rather than must provide wiggle-room for that. Objections or seconds? I don't think it should reference _REENTRANT any more for modern GNU/Linux system like Debian. LinuxThreads is an old thread implementation -- see http://pauillac.inria.fr/~xleroy/linuxthreads/ -- that is not used any more. It is not even packaged in Debian. The only need for _REENTRANT I know is OSF/1: # On OSF/1, the compiler needs the flag -D_REENTRANT so that it # groks pthread.h. cc also understands the flag -pthread, but # we don't use it because 1. gcc-2.95 doesn't understand -pthread, # 2. putting a flag into CPPFLAGS that has an effect on the linker # causes the AC_TRY_LINK test below to succeed unexpectedly, # leading to wrong values of LIBTHREAD and LTLIBTHREAD. CPPFLAGS=$CPPFLAGS -D_REENTRANT and Solaris: # Some systems optimize for single-threaded programs by default, and # need special flags to disable these optimizations. For example, the # definition of 'errno' in errno.h. case $host_os in ... solaris*) CPPFLAGS=$CPPFLAGS -D_REENTRANT ;; GNU/Linux doesn't need it as far as I have been able to determine. getlogin_r appears to be declared by default now, /usr/include/unistd.h says: #if defined __USE_REENTRANT || defined __USE_POSIX199506 ... extern int getlogin_r (char *__name, size_t __name_len) __nonnull ((1)); But __USE_POSIX199506 is defined by default. Lacking any real evidence of the need of _REENTRANT, I have long since removed all uses of _REENTRANT in my projects (and gnulib) and these projects are used in multi-threaded environments without problem. On the other hand, I know that some Debian packages re-add _REENTRANT. Thus, I would suggest simply saying this: p Libraries should be built with threading support and to be thread-safe if the library supports this. /p Alternatively, provide the _real_ rationale for _REENTRANT. I'm pretty sure LinuxThreads isn't a valid rationale for it these days -- or am I wrong? /Simon diff --git a/policy.sgml b/policy.sgml index bad28af..1ffe148 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7225,10 +7225,10 @@ INSTALL = install -s # (or use strip on the files in debian/tmp) for C files) will need to be compiled twice, for the normal case. /p + p - You must specify the gcc option tt-D_REENTRANT/tt - when building a library (either static or shared) to make - the library compatible with LinuxThreads. + Libraries should be built with threading support and to be + thread-safe if the library supports this. /p p -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4pbirwq@mocca.josefsson.org
Bug#486453: Policy 8.2 suggests libraryname-tools, but not libraryname-utils
Fabian Greffrath [EMAIL PROTECTED] writes: Package: debian-policy Version: 3.8.0.1 Severity: minor Hi, Policy currently reads: 8.2 Shared library support files [...] Run-time support programs that use the shared library but are not required for the library to function or files used by the shared library that can be used by any version of the shared library package should instead be put in a separate package. This package might typically be named libraryname-tools; note the absence of the soversion in the package name. However, in practice the -utils suffix for the discussed type of packages seems to be much more widely used than the -tools suffix that is suggested by policy 8.2. On my system I get the following results: $ dpkg -l \*-tools | wc -l 27 $ dpkg -l \*-utils | wc -l 38 I'm not sure it is relevant, but another data point would be *-bin: [EMAIL PROTECTED]:~$ dpkg -l lib\*-bin|wc -l 20 [EMAIL PROTECTED]:~$ The lack of plurals here can also be confusing: [EMAIL PROTECTED]:~$ dpkg -l \*-util|tail -3 +++--===- un db4.6-util none (no description available) un libpam0g-utilnone (no description available) [EMAIL PROTECTED]:~$ /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475101: obsolete linuxthreads requirement
Kurt Roeckx [EMAIL PROTECTED] writes: On Fri, Apr 11, 2008 at 08:23:19AM +0200, Simon Josefsson wrote: Thanks. But does LinuxThreads need -D_REENTRANT today? The links to the gnulib list I gave suggested that it isn't necessary, but without knowing exactly what to test it is difficult to know for sure. I think that testing that errno is thread local instead of global is a good test to see if it's needed. Agreed. I know that extern int errno; used to work on systems using LinuxThreads, but that it fails to link on systems using NPTL. I believe one needs to use '#include errno.h' to be portable nowadays, at least according to: http://www.opengroup.org/onlinepubs/009695399/functions/errno.html But even the errno.h from i386 sarge seems to use (*__errno_location ()). Right. So it looks to me that _REENTRANT is only used to make some functions like getlogin_r available. That is how I understand the situation as well. I don't know much about thread stuff, but my hope is that we could derive some concrete explanation of what breaks if you don't add -D_REENTRANT when building debian packages. That would make it possible to come back to this text later and evaluate whether the reasons for having the text are still valid. I think that on a Debian system using glibc using _REENTRANT isn't needed if: - You don't need specialy reentrant functions from libc; To be more precise: if you don't need the *.h prototype's for the specialy reentrant functions. - Other libraries you're using have something in their include files that change behaviour depending on _REENTRANT; Right. libxml2 may be one such candidate, at least it inspects _REENTRANT in /usr/include/libxml2/libxml/xmlversion.h. I'm not sure if its value matters though. - The package you're building itself doesn't change change behaviour depending on _REENTRANT. Right. I think that libraries in Debian should never change behaviour based on _REENTRANT. If a library can be build to either support threads or not, it should be compiled to support threads. It might also want to provide one that does and one that doesn't so that you can link to either one, but I would like to discourage that, and the default library should be the one that supports threads. And if it does provide 2 libraries, the header files for both should be the same and not depend on _REENTRANT. I think I agree here too, although I'm not as confident. In any case, I think we can safely assert that many libraries don't need -D_REENTRANT. The trade-off then is to compare the costs of forcing maintainers (via the policy) to build all libraries in Debian with a special flag against the costs of potentially running into some library that actually need the flag in order to not cause problems in a threaded environment. My general preference is to only do exceptions when they are known to be needed, and avoid bloating all software for the benefit of a few scenarios. Thus, I would prefer if in the (likely few) cases where setting -D_REENTRANT is required, that it is done explicitly only in those cases. I wouldn't want to change something like this at this time in the release cycle though. This discussion reinforced the rationale for my decision that GnuTLS should not set -D_REENTRANT when it is built. It doesn't use any reentrant functions, and its use of errno is thread safe since it accesses it via errno.h. There may be non-debian systems were it is needed, but I'd prefer to add it only on those platforms. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475101: obsolete linuxthreads requirement
Kurt Roeckx [EMAIL PROTECTED] writes: On Thu, Apr 10, 2008 at 09:28:03AM +0200, Simon Josefsson wrote: Kurt Roeckx [EMAIL PROTECTED] writes: On Tue, Apr 08, 2008 at 08:22:10PM -0400, Joey Hess wrote: Package: debian-policy Version: 3.7.3.0 Severity: normal You must specify the gcc option `-D_REENTRANT' when building a library (either static or shared) to make the library compatible with LinuxThreads. AFAIK we don't use linuxthreads anymore, and I checked a few libraries and failed to find them using such a flag. I think hppa still uses it. The -D_REENTRANT might also be used in other libraries that can be compiled to support threads or not. But those might also be using some other options. I think we should just say that all libraries should get build with thread support if they support it. Do you have any references to the hppa case (in particular, does it affect glibc/debian on hppa?), and which these libraries are? http://lists.debian.org/debian-release/2008/03/msg00367.html says: - All Linux platforms except hppa have switched to NPTL. 2.4 kernels are not supported anymore. Thanks. But does LinuxThreads need -D_REENTRANT today? The links to the gnulib list I gave suggested that it isn't necessary, but without knowing exactly what to test it is difficult to know for sure. I don't know much about thread stuff, but my hope is that we could derive some concrete explanation of what breaks if you don't add -D_REENTRANT when building debian packages. That would make it possible to come back to this text later and evaluate whether the reasons for having the text are still valid. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475101: obsolete linuxthreads requirement
Kurt Roeckx [EMAIL PROTECTED] writes: On Tue, Apr 08, 2008 at 08:22:10PM -0400, Joey Hess wrote: Package: debian-policy Version: 3.7.3.0 Severity: normal You must specify the gcc option `-D_REENTRANT' when building a library (either static or shared) to make the library compatible with LinuxThreads. AFAIK we don't use linuxthreads anymore, and I checked a few libraries and failed to find them using such a flag. I think hppa still uses it. The -D_REENTRANT might also be used in other libraries that can be compiled to support threads or not. But those might also be using some other options. I think we should just say that all libraries should get build with thread support if they support it. Do you have any references to the hppa case (in particular, does it affect glibc/debian on hppa?), and which these libraries are? I have tried to find modern references to what -D_REENTRANT actually does, but haven't found any concrete examples of what breaks if you don't use it. I have now disabled it in gnutls. Some potentially relevant discussions in: http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2495 http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/12892 http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/12876 /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420701: GFDL is now in common-licenses
Russ Allbery [EMAIL PROTECTED] writes: Giacomo A Catenazzi [EMAIL PROTECTED] writes: I think we should add also the license version in the first paragraph, as is stated in the second part, not to confuse users. + license, the GNU GPL (v. 2), the GNU LGPL (v. 2 and v. 2.1), and the GNU FDL should refer + to the corresponding files under Agreed. Here's a new patch. Note that this removes the unversioned licenses from the non-normative footnote; that's not a normative change yet, but I do want to discuss that separately under Bug#431109. How about fixing the stylistic issue of saying 'For example, ..., and so on.'? Actually, the filenames doesn't strike me as examples at all. How about 'In particular, /usr/..., respectively.' instead? And make sure the paths are given in the same order as the text. Btw, the path to the LGPL v2.0 license is missing. Thanks, Simon --- orig/policy.sgml +++ mod/policy.sgml @@ -8653,21 +8653,18 @@ p Packages distributed under the UCB BSD license, the Artistic - license, the GNU GPL, and the GNU LGPL, should refer to the + license, the GNU GPL (version 2), the GNU LGPL (versions 2 and + 2.1), and the GNU FDL (version 1.2) should refer to the corresponding files under file/usr/share/common-licenses/file,footnote p For example, file/usr/share/common-licenses/Artistic/file, file/usr/share/common-licenses/BSD/file, - file/usr/share/common-licenses/GPL/file, - file/usr/share/common-licenses/LGPL/file, - file/usr/share/common-licenses/GFDL/file, - file/usr/share/common-licenses/GPL-2/file, and - file/usr/share/common-licenses/LGPL-2.1/file, and so - on. Note that the GFDL is new here, and the license file - may not yet be in place in - file/usr/share/common-licenses/GFDL/file. + file/usr/share/common-licenses/GPL-2/file, + file/usr/share/common-licenses/LGPL-2.1/file, + file/usr/share/common-licenses/GFDL-1.2/file, and so + on. /p /footnote rather than quoting them in the copyright file. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
