Does iproute2 moving config files to /usr/lib violate section 10.7.2?
Hello debian-policy, iproute2 has moved it's config files that were traditionally at /etc/iproute2 to /usr/lib/iproute2 due to an upstream change. I've tried to convince the maintainer(s) that this is a bad idea in Bug#1051577, when this was shot down I filed Bug#1051847 as severity:serious on the basis of Debian policy section 10.7.2 section 10.7.2. "Configuration files / Location" which states as follows: > Any configuration files created or used by your package must reside > in /etc. Pretty clear cut in my reading, however this was promptly shot down by Bastian with the justification: > No, it does not. The files in /usr are defaults. Those should be copied > to /etc for modification, which is config. Am I going nuts? Somehow long established unix convention and usability doesn't matter anymore and policy doesn't mean what it says? I'd appreciate any input and advice on how to proceed here since I'm new to contributing to Debian outside of packaging :) Thanks, --Daniel signature.asc Description: PGP signature
Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?
Sam, Russ, Bill, Thanks for your input. To be quite frank I still don't see how the interpretation of allowing configuration files outside of /etc can be supported based on the policy text. Ultimately I'm just concerned about the UX aspects of admins suddenly having to go hunting for config files all over their system when packages start implementing this config-in-/usr business en mass. I don't really mind if we go that way but then policy needs to be updated and some convention or mechanism[1] put in place to make working with config by hand as easy as it's been in the past, but that work is on the devs pushing the project in that direction. [1]: Josh had an interesting idea over in a relate d-devel thread: "sysadmin configuration of sparse-/etc vs prepopulated-/etc?" https://lists.debian.org/debian-devel/2023/09/msg00192.html Perhaps by having /usr/etc which must mirror where files go in /etc? Right now different packages seem to put files in random places, some in /usr/share some in /usr/lib. Madness. If this becomes more common I fear it's going to cause a lot of friction for root users. Remember: those are the ones with the power to just uninstall Debian and replace it ;) On Thu, Sep 14, 2023 at 09:41:00AM -0700, Russ Allbery wrote: > Configuration file has a very specific meaning in Policy: it's a file that > the local system administrator changes in order to configure the software. Sorry, I don't buy that. Policy is kind enough to have an explicit definition for what it means by "configuration file" in 10.7.1. Definitions: > configuration file > > A file that affects the operation of a program, or provides site- or > host-specific information, or otherwise customizes the behavior of a > program. "A file that affects the operation of a program" pretty clear cut to mean exactly the type of files at issue here. Policy goes on to suggest that such a file might typically be intended to be edited by the admin: > Typically, configuration files are intended to be modified by the system > administrator (if needed or desired) to conform to local policy or to > provide more useful site-specific behavior. Note how this is not a requirement for a file to be captured by this definition. So I maintain that the current policy text doesn't allow configuration files outside of /etc. --Daniel signature.asc Description: PGP signature
Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness
Source: developers-reference Severity: normal Hi, > 6.3.2. Selecting the upload urgency mentions only high, medum and low urgency values. Britney also supports critical and emergency. These should be documented as well. Something like: - The delays are currently 2, 5 or 10 days, depending on the urgency (high, medium or low). + The delays are currently 0, 2, 5 or 10 days, depending on the urgency: critical/emergency, high, medium or low respectively. Where emergency is simply an alias for critical. Thanks, --Daniel
Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness
Hi Holger, On Wed, Dec 13, 2023 at 02:19:14PM +, Holger Levsen wrote: > On Wed, Dec 13, 2023 at 01:55:21PM +0100, Daniel Gröber wrote: > > > 6.3.2. Selecting the upload urgency > > mentions only high, medum and low urgency values. Britney also > > supports critical and emergency. These should be documented as well. > > thanks for filing this bug report, even with a patch, basically! > > I'm sorry I still closing this as documenting those severities has no > practical benefit, and in fact might confuse people thinking using those > severities would be encouraged or useful, which is both not the case. That's fine, but in that case this fact should be documented instead no? Right now there's confusion across the docs what criticality levels are available. Britney.conf and d-policy mention critical/emergency but nothing else even acknowledges they exist which is just confusing. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness
On Wed, Dec 13, 2023 at 07:24:49PM +, Holger Levsen wrote: > On Wed, Dec 13, 2023 at 07:04:01PM +0100, Daniel Gröber wrote: > > That's fine, but in that case this fact should be documented instead no? > > Right now there's confusion across the docs what criticality levels are > > available. Britney.conf and d-policy mention critical/emergency but nothing > > else even acknowledges they exist which is just confusing. > > I believe Debian policy should be changed then and not mention a severity > which is not used in practice. Easier said than done. I see debian-policy@d.o is already CCed on this bug so, opinions? Doesn't policy document the reality that these urgency values are in fact usable? Do you not agree that britney does in fact support these? If I go ahead and upload a package with urgency=critical will this be REJECTed by ftp-master? If not they exist so why shouldn't they be documented in devref? --Daniel signature.asc Description: PGP signature
Bug#499167: developers-reference: please explain deb/debian/ds suffixes in versions
The convention seems to be documented in https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F > “+dfsg.N” and “+ds.N“ are a conventional way of extending a version > string, when the Debian package's upstream source tarball is actually > different from the source released upstream. The former is used when > upstream's source release contains elements that do not satisfy the > Debian Free Software Guildelines (DFSG) and hence may not be distributed > as source in the Debian system, the latter (standing for “Debian Source”) > is used when the modification are for other non-DFSG reasons. The text in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774843 seems to incorporate it. --Daniel signature.asc Description: PGP signature
