Re: Head's up: Debian Policy 3.9.3 release planned for 2012-02-22
On 2012-02-14 22:22, Russ Allbery wrote:
> Niels Thykier <niels@thykier.net> writes:
>
>> Thanks for the heads up - I suspect we are also a bit overdue on a
>> Lintian release. :) I had a quick look at the git shortlog and from
>> what I can tell Lintian is pretty much up to speed so far[1].
>
>> [1] Admittedly I only noticed some /run, DEP-5 and some multi-arch
>> stuff.
>
> Here's the draft upgrading-checklist:
>
> 2.4
> New archive sections _education_, _introspection_, and
> _metapackages_ added.
>
added in commit: d866978
> 5.6.8
> The `Architecture' field in `*.dsc' files may now contain the
> value `any all' for source packages building both
> architecture-independent and architecture-dependent packages.
>
fixed in 2.5.1 (#626775)
> 7.1
> If a dependency is restricted to particular architectures, the
> list of architectures must be non-empty.
>
no check for that as far as I recall (but I didn't check).
> 9.1.1
> `/run' is allowed as an exception to the FHS and replaces
> `/var/run'. `/run/lock' replaces `/var/lock'. The FHS
> requirements for the older directories apply to these directories
> as well. Backward compatibility links will be maintained and
> packages need not switch to referencing `/run' directly yet.
> Files in `/run' should be stored in a temporary file system.
>
> 9.1.4
> New section spelling out the requirements for packages that use
> files in `/run', `/var/run', or `/var/lock'. This generalizes
> information previously only in 9.3.2.
>
As I recall, we got a check treating /run similar to /var/run (that is,
"package installs files in /run").
> 9.5
> Cron job file names must not contain `.' or `+' or they will be
> ignored by cron. They should replace those characters with `_'.
> If a package provides multiple cron job files in the same
> directory, they should each start with the package name (possibly
> modified as above), `-', and then some suitable prefix.
>
Fixed in 2.5.0~rc2 (#615072)
> 9.10
> Packages using doc-base do not need to call install-docs anymore.
>
I assume that would be the "${maintscript}-calls-installdocs" tags?
> 10.7.4
> Packages that declare the same `conffile' may see left-over
> configuration files from each other even if they conflict.
>
> 11.8
> The Policy rules around Motif libraries were just a special case
> of normal rules for non-free dependencies and were largely
> obsolete, so they have been removed.
>
> 12.5
> `debian/copyright' is no longer required to list the Debian
> maintainers involved in the creation of the package (although
> note that the requirement to list copyright information is
> unchanged).
>
> mime
> Retire this separate document and merge its (short) contents into
> Policy section 9.7. There are no changes to the requirements.
>
> perl
> Packages may declare an interest in the <perl-major-upgrade>
> trigger to be notified of major upgrades of perl.
>
I guess those five are no-op for us?
> virtual
> `ttf-japanese-{mincho, gothic}' is renamed to
> `fonts-japanese-{mincho, gothic}'.
>
I don't see any of them in data/files/fonts. Well, ttf-japanese-mincho
disappeared when I refreshed the fonts file, but I do not see any of the
new ones.
>> If I recall correctly you were considering to drop the
>> "missing-symbols-file" for C++ libraries?
>
> Yeah. The alternative would be to make it wishlist/wild-guess for C++,
> but my experience was that it wasn't an issue with some C++ libraries, but
> rather that the current state of the tools and symbol handling make this a
> not particularly sane thing to do for more like 90% of libraries. I'm not
> sure that's accurate, but it's the reaction I came away with.
>
> At the very least, trying to maintain the file without something like
> pkg-kde-tools strikes me as very difficult.
>
> So, my inclination is to drop the tag for C++ until such time as the tools
> are better. I filed a set of bugs against pkg-kde-tools that would
> improve the situation.
>
Okay, I have not done that. I might get it done before the 22nd.
>> Was the conclusion of #659574 to downgrade the tag to "pedantic"? If
>> so, I might do it if I get a sudden urge to write some tests.
>
> Yes, I think that's the right thing to do.
>
Done that.
I also took the liberty of refreshing most of our data files and merge
Jakub's numpy patches. So beside the symbols files for C++ thing and
the coming S-V bump, I think Lintian is ready to be uploaded this week
(/next week depending on your timezone). :)
~Niels
Reply to: