Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

Package: debian-policy
Version: 4.6.0.1
Severity: important

Building packages should not require to be root.

I don't know what's going on, but see

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002497#31

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  4.3.2-1

Versions of packages debian-policy suggests:
ii  doc-base  0.11.1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

Control: reopen -1

On 2021-12-25 14:55:37 -0700, Sean Whitton wrote:
> Hello,
> 
> On Sat 25 Dec 2021 at 10:38PM +01, Vincent Lefevre wrote:
> 
> > Package: debian-policy
> > Version: 4.6.0.1
> > Severity: important
> >
> > Building packages should not require to be root.
> >
> > I don't know what's going on, but see
> >
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002497#31
> 
> It looks like the issue has been fixed over there.

Not currently available, but anyway this doesn't answer the issue with
other possible packages where this would not be fixed. This was mainly
about the bug severity.

IMHO, a failure to build a package as a normal user should be regarded
as a RC bug (Scott Kitterman said "Certainly not a serious bug. [...]
Don't upgrade the severity again. If you think this is such a big
deal, go get something in Debian policy.").

In particular, all packages in stable should be buildable as a normal
user (in particular to lower the risk of breaking the system in case
of a bug somewhere in the build system).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

Hello Bill,

On 2021-12-25 22:58:25 +0100, Bill Allombert wrote:
> On Sat, Dec 25, 2021 at 10:38:47PM +0100, Vincent Lefevre wrote:
> > Building packages should not require to be root.
> 
> Hello Vincent!
> 
> Currently, packages are allowed to require root to build.
> See Rules-Requires-Root for more detail.

No, this is not what the Rules-Requires-Root documentation says.

https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-rules-requires-root
says:

  Depending on the value of the Rules-Requires-Root field, the package
  builder (e.g. dpkg-buildpackage) may run the debian/rules target as
  an unprivileged user and provide a gain root command. This command
  allows the debian/rules target to run particular subcommands under
  (fake)root.

When a package is built as a normal user, Rules-Requires-Root assumes
that using fakeroot would be fine.

Here, the build via "debuild" is failing even when fakeroot is
available (installed on the machine). Note that Rules-Requires-Root
has been set to "no". IMHO, the policy should say that when
Rules-Requires-Root is set to "no", being root or using fakeroot
should not be required.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

Hi Sean,

On 2021-12-25 15:55:32 -0700, Sean Whitton wrote:
> Okay, I've attempted to retitle this bug in accordance with your
> suggestion.  The relevant change would not be in ch. 4, but under ch. 5.
> What you suggest is to add to the meaning of "Rules-Requires-Root: no"
> that packages which declare this must not fail to build as non-root.
> 
> This would be quite a significant change, as currently
> Rules-Requires-Root is pretty much just advisory to dpkg-buildpackage.

I'm wondering what is the point to set "Rules-Requires-Root: no" if
the consequence is that this makes the build fail as a non-root user.

> Do we have a project consensus that it ought to be more than advisory?
> I'm not sure -- the field is fairly new.

If this is new, I would have assumed that when a maintainer adds this
field, he should check that the build really succeeds as non-root.

> In addition to that, we would also need to be confident that making this
> change in Policy would not render more than a few packages buggy.

Couldn't there be a build bot to check that?

FYI, over the past few years, I've built dozens of packages as a
non-root user (I never build packages as root), and with the new
postfix bug (now closed as fixed), this was the first time I saw
a failure for this reason.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

On 2021-12-25 14:48:33 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> 
> > Here, the build via "debuild" is failing even when fakeroot is available
> > (installed on the machine). Note that Rules-Requires-Root has been set
> > to "no". IMHO, the policy should say that when Rules-Requires-Root is
> > set to "no", being root or using fakeroot should not be required.
> 
> It does already.
> 
> no: Declares that neither root nor fakeroot is required. Package
> builders (e.g. dpkg-buildpackage) may choose to invoke any target in
> debian/rules with an unprivileged user.
> 
> Am I missing something?

According to Sean, this is just advisory (and Scott Kitterman seemed
to assume that a build failure as non-root[*] was not a RC bug).

[*] here, just because of "Rules-Requires-Root: no".

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

On 2021-12-27 17:54:24 -0700, Sean Whitton wrote:
> The sort of case I have in mind is an 'RRR: no'%e package that does not
> FTBFS when built as root, but does do so as non-root.  I agree that
> that's an FTBFS bug, but is it release-critical?  For a relatively new
> feature like RRR, I'm not sure it is, unless Policy says it is.  But I
> could be convinced, and I agree with you that the sort of reasoning
> you're giving is a good way to think about this sort of thing.

I think that it should be release-critical: RRR may be new,
but removing the "RRR: no" would normally solve the problem
(this might not be the best solution, but it is at least
better than a FTBFS as non-root).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#703612: developers-reference: transitional packages cannot always safely be removed

[Vincent Lefevre]

Package: developers-reference
Version: 3.4.9
Severity: normal

share/doc/developers-reference/developers-reference.txt.gz says:

  6.7.7. Make transition packages deborphan compliant
[...]
For example, with --guess-dummy, deborphan tries to search all
transitional packages which were needed for upgrade but which can
now safely be removed. For that, it looks for the string dummy or
transitional in their short description.

"which can now safely be removed" is incorrect, as a transitional
package can still contain executables and be functional, e.g. ffmpeg.

According to

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692193#29

a transitional package can also be a package that will be removed
in a future version of Debian.

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

developers-reference depends on no packages.

Versions of packages developers-reference recommends:
ii  debian-policy  3.9.4.0

Versions of packages developers-reference suggests:
ii  doc-base  0.10.4

-- no debconf information


-- 
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/2013032543.ga28...@xvii.vinc17.org

Bug#703619: www.debian.org: language-related problem with http://www.debian.org/doc/manuals/developers-reference pages

[Vincent Lefevre]

On 2013-03-24 19:20:17 +0900, Charles Plessy wrote:
> like for the other pages of the Debian website, the Developers Reference is
> served by content negociation and for that reason it is not possible to
> transiently change the default language without the use of a browser plugin 
> (or

By correcting the internal links to those corresponding to the same
language, it is possible. This is what is usually done. But perhaps
it is related to this:

> From a general point of view, I think that this bug can be closed, as the
> Debian website works as intended.  However, in contrary to the pages generated
> by WML, the Developers Reference web pages do not have link to the available
> translations.  Therefore, you can also consider reassigning this bug to the
> developers-reference package.  But given the usual lack of manpower, a patch
> would then be very welcome if you want the reassignment to have an effect in
> the short-mid term :)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130324122843.gu11...@xvii.vinc17.org

Re: Removing the manpage requirement for GUI programs?

[Vincent Lefevre]

On 2010-03-04 17:12:15 +0100, Bill Allombert wrote:
> On Thu, Mar 04, 2010 at 04:32:45PM +0100, Josselin Mouette wrote:
> > Because, of course, the user is too stupid to click the “Help” menu
> > inside the application.
> 
> Because the users have not yet decided if they want to start the application
> and they look to the manpage for guidance.

Yes, and for various reasons, it may happen that the application
doesn't start (e.g. due to incorrect environment), and the user
cannot look at the help from the menu to see what's wrong.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
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/20100305083004.ga13...@prunille.vinc17.org

Bug#412668: debian-policy: extended 10.7 to other forms of configuration (e.g. symlinks)

[Vincent Lefevre]

Package: debian-policy
Version: 3.7.2.2
Severity: important

[Severity set as important, because the lack of a requirement can
have serious implications, including security ones.]

Configuration is sometimes represented in another way than contents
of a configuration file, e.g. a set of symbolic links. However there
is absolutely no reason to regard such information as less important
than the contents of a configuration file. This is particularly true
for 10.7.3, e.g. the Debian policy should require that local changes
in symbolic links (or whatever that can represent a configuration)
must be preserved during an upgrade.

An example is bug 412159 that is not regarded as a release-critical
bug though one of the settings is not preserved, because the
corresponding configuration is represented by a symbolic link
somewhere in /etc.

Note: though in this bug, the lost configuration is just one bit of
information, this is still annoying, and in general, symbolic links
can also represent much more information and possibly configuration
related to security/privacy settings.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686-bigmem
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#412668: debian-policy: extended 10.7 to other forms of configuration (e.g. symlinks)

[Vincent Lefevre]

On 2007-02-27 16:37:21 -0800, Steve Langasek wrote:
> Policy requires that packages preserve local changes to
> *configuration files*. What you're asking for is that packages be
> required unconditionally to preserve *application behavior*.

No, this is not what I'm asking for. I really mean configuration
(as long as the option exists and has the same meaning, of course).

> In the case of bug #412159 I agree it's a bug to delete a symlink
> that the user has created by hand.

Note that the symlink status wasn't changed by hand, but via debconf,
when I changed the local configuration with dpkg-reconfigure.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"

[Vincent Lefevre]

Package: developers-reference
Version: 13.5
Severity: normal

Now that the deborphan package has been removed from unstable,
the section "Make transition packages deborphan compliant" in
"Best Packaging Practices" is out of date and should be updated.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312
where "apt-mark auto ..." (for autoremove) is suggested as a
replacement. But with it, putting transition packages to oldlibs
is even more necessary.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

developers-reference depends on no packages.

Versions of packages developers-reference recommends:
ii  debian-policy4.7.0.0
ii  libjs-sphinxdoc  7.2.6-6
ii  sensible-utils   0.0.22

Versions of packages developers-reference suggests:
pn  doc-base   
ii  elinks [www-browser]   0.16.1.1-4.1+b2
ii  firefox [www-browser]  124.0.1-1
ii  firefox-esr [www-browser]  115.9.1esr-1
ii  links [www-browser]2.29-1+b3
ii  links2 [www-browser]   2.29-1+b3
ii  lynx [www-browser] 2.9.0rel.0-2+b1
ii  w3m [www-browser]  0.5.3+git20230121-2+b3

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1098948: Changing 10.1 requirements for /usr/games

[Vincent Lefevre]

On 2025-02-26 15:55:06 +0100, Helmut Grohne wrote:
> Of course this does not consider conflicts, so in practice we have
> some false positives. Here is an example output.
[...]

As the policy is written, a Conflicts does not seem to be a resolution
for programs with the same filenames:

10.1
Two different packages must not install programs with different
functionality to the same filenames, even names under different
directories, when the directories are on the default PATH.

There is no mention of non-conflicting packages here (such as
"Two different non-conflicting packages"), and it does not say that
this concerns simultaneous installations (or on the same machine).

As I understand it, if a program name "foo" comes from conflicting
packages A and B, this may confuse the user and possibly scripts
(or configuration in applications that run other programs) if
package A is installed on some machine and package B is installed
on another machine, or if some day on some machine, package A gets
removed and package B gets installed. This could be a reason why
such a case may be forbidden, just like for non-conflicting
packages.

Moreover, if the program "foo" does not do the same thing in these
two packages A and B, then the user may want to be able to use both
programs on the same installation, which would be possible if the
program names were different (avoiding the package conflict).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)