Bug#944920: Revise terminology used to specify requirements

[Sean Whitton]

Hello,

On Mon 18 Nov 2019 at 05:34PM -08, Russ Allbery wrote:

> Yeah, that was my thought process, but I did totally break my own rule.  I
> can break this out into a separate change if that makes more sense.  I was
> trying to reword the sentence to avoid using "no ... may" and trying to
> keep the 64-bit qualification seemed very awkward.
>
> /usr/lib64 is for 64-bit architecture support the Red Hat way (instead of
> the Debian multiarch approach), so no 32-bit package would ever
> legitimately install files there.

Let's go ahead and make the change as part of resolving this bug, but
let's also mention the semantic change in the upgrading checklist, just
in case there is some strange edge case we've missed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

David Bremner  writes:
> Sean Whitton  writes:

>>> -No package for a 64 bit architecture may install files in
>>> -``/usr/lib64/`` or in a subdirectory of it.
>>> +Packages must not install files in ``/usr/lib64`` or in a subdirectory
>>> +of it.
>>
>> This seems to be a semantic change, generalising the requirement to all
>> packages?

> Well, I think you're both right. A lawyerly reading of policy might say
> 32 bit packages can install in /usr/lib64, but wouldn't that just be
> nonsensical, and maybe contradict other wording about FHS conformance

Yeah, that was my thought process, but I did totally break my own rule.  I
can break this out into a separate change if that makes more sense.  I was
trying to reword the sentence to avoid using "no ... may" and trying to
keep the 64-bit qualification seemed very awkward.

/usr/lib64 is for 64-bit architecture support the Red Hat way (instead of
the Debian multiarch approach), so no 32-bit package would ever
legitimately install files there.

-- 
Russ Allbery (r...@debian.org)  

Bug#944920: Revise terminology used to specify requirements

[David Bremner]

Sean Whitton  writes:

>
>> -No package for a 64 bit architecture may install files in
>> -``/usr/lib64/`` or in a subdirectory of it.
>> +Packages must not install files in ``/usr/lib64`` or in a subdirectory
>> +of it.
>
> This seems to be a semantic change, generalising the requirement to all
> packages?

Well, I think you're both right. A lawyerly reading of policy might say
32 bit packages can install in /usr/lib64, but wouldn't that just be
nonsensical, and maybe contradict other wording about FHS conformance

Bug#944920: Revise terminology used to specify requirements

[Sean Whitton]

Hello,

On Sun 17 Nov 2019 at 05:48PM -08, Russ Allbery wrote:

> I agree, but let's also fix existing incorrect wording.  I reviewed every
> instance of may and optional in Policy, and I think this larger diff will
> make wording (mostly) consistent.  I've tried not to change the sense of
> any of these Policy statements (even though a few are questionable and
> should probably be revisited).

Cool!  I think in this case we should s/sometimes used/used/ in your new
description of the use of 'may' and 'optional', right?

Review of the big diff:

> -No package for a 64 bit architecture may install files in
> -``/usr/lib64/`` or in a subdirectory of it.
> +Packages must not install files in ``/usr/lib64`` or in a subdirectory
> +of it.

This seems to be a semantic change, generalising the requirement to all
packages?

>  is being used.) You must not include the ``/etc/rcn.d`` directories
> -themselves in the archive either. (Only the ``sysvinit`` package may do
> -so.)
> +themselves in the archive either. (Only the ``init-system-helpers``
> +package may do so.)

Likewise, isn't this a semantic change?

> @@ -797,14 +798,13 @@ the upstream tarball.  In order to satisfy the DFSG for 
> packages in
>  2. include a copy of the sources in the ``debian/missing-sources``
> directory.
>
> -There is an optional convention to organise the contents of
> -``debian/missing-sources`` in the following way.  For a sourceless
> -file ``foo`` in the subdirectory ``bar`` of the upstream tarball,
> -where the source of ``foo`` has extension ``baz``, the source is to be
> -located at ``debian/missing-sources/bar/foo.baz``.  For example,
> -according to this convention, the C source code of an executable
> -``checksum/util`` is to be located at
> -``debian/missing-sources/checksum/util.c``.
> +Package maintainers are encouraged to use the following convention to
> +organize the contents of ``debian/missing-sources``: for a sourceless file
> +``foo`` in the subdirectory ``bar`` of the upstream tarball, where the
> +source of ``foo`` has extension ``baz``, the source is to be located at
> +``debian/missing-sources/bar/foo.baz``. For example, according to this
> +convention, the C source code of an executable ``checksum/util`` would be
> +located at ``debian/missing-sources/checksum/util.c``.

I don't think this should be strengthened to something Policy
encourages, or if it should, we should discuss it in a separate bug.  So
I'd like to suggest using none of the magic words in this paragraph,
just starting it with "There is a convention to organise ..."

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[gregor herrmann]

On Sun, 17 Nov 2019 17:01:21 -0700, Sean Whitton wrote:

> On Sun 17 Nov 2019 at 10:29AM -08, Russ Allbery wrote:
> > How about:
> >
> > This field should only be used when there are license or DFSG
> > requirements to retain the referenced source package.  It should not
> > be added solely as a way to locate packages that need to be rebuilt
> > against newer versions of their build dependencies.
> 
> Thanks, I think this is good -- would be good to hear from Nicholas too
> though.

(Not Nicholas but) As a non-native speaker I think that's clear and
easy to read.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Koko Taylor: Wang Dang Doodle


signature.asc
Description: Digital Signature

Processed: Bug#904246 marked as pending in developers-reference

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #904246 [developers-reference] developers-reference: section 6.4 should 
recommend command -v, not which
Added tag(s) pending.

-- 
904246: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904246
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#904246: developers-reference: section 6.4 should recommend command -v, not which

[Holger Levsen]

Hi,

thanks for your feedback, I've now rewritten the paragraph in question
to simply read:


If you need to check for the existence of a command, you should use
something like

::

   if command -v install-docs > /dev/null; then ...

You can use this function to search ``$PATH`` for a command name, passed
as an argument. It returns true (zero) if the command was found, and
false if not. This is really the best way, since ``command -v`` is a
shell-builtin for many shells and is defined in POSIX.

Using ``which`` is an acceptable alternative, since it is from the required
``debianutils`` package.


I think this is much better.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature