Back to the topic of changed binary named (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))
Hi Paul and others, its surely an interesting topic how to avoid binary name changes and its also interesting to discuss ABI changes and workarounds. However, my point was that I want to know what policy ftpmaster applies to new binary names and to focus on this topic. I really want to know that policy of ftpmaster and I really would like to see that documented and I'm afraid that thread is drifting away from the original topic that I will not get any answer on this. So again: I see a conflict in my interpretation of the mail[1] (original posters again in CC) which suggests "an auto-approver" and what I'm currently observing and I would be really happy if we can document the policy for changed (and new) binary names of existing source packages. To give another example which has nothing todo with ABI changes: Currently I'm afraid of splitting some Arch: all data from some Arch: any package since I'm simply afraid of the changed package sticking long in new queue. I know this is bad - but I consider users waiting for package updates worse. Kind regards Andreas. [1] https://lists.debian.org/debian-devel/2021/07/msg00231.html Am Mon, Jan 24, 2022 at 10:20:48AM +0800 schrieb Paul Wise: > On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote: > > > That only works if there are no other packages depending on those > > shared libraries which are coming from other source packages. > > I don't think that is true, I believe you can put multiple things in > the depends section of an shlibs file and dpkg-shlibdeps will propagate > that to reverse dependencies just fine. From the manual pages it looks > like the same applies to the symbols files. I found on my system that > there are *already* packages that do something similar (see below). > ... -- http://fam-tille.de
Re: The future of src:ntp
On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote: > On 1/19/22 15:04, Bernhard Schmidt wrote: > > On 19.01.22 20:34, Richard Laager wrote: > > > 2. I create transitional binary packages in src:ntpsec: > I got to thinking about this more. This won't work, because src:ntp is > 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of > 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's > transitional bin:ntp package to be newer than src:ntp's bin:ntp package. Bumping the epoch to 2 here is completely gratuitous and can make a mess for ntpsec *and* potentially ntp iff upstream got to be improved and we wanted to reintroduce it in the future. > It might be technically possible to build a binary package with different > versioning, but even if it is: 1) I don't know how, and 2) I'm not sure > whether that's a good idea, especially compared to the alternatives. Yes, this is the recommended method, that has been used in the past, and which is mentioned in the dpkg FAQ. You can set arbitrary versions via dpkg-gencontrol (or indirectly via dh_gencontrol). Thanks, Guillem
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote: > That only works if there are no other packages depending on those > shared libraries which are coming from other source packages. I don't think that is true, I believe you can put multiple things in the depends section of an shlibs file and dpkg-shlibdeps will propagate that to reverse dependencies just fine. From the manual pages it looks like the same applies to the symbols files. I found on my system that there are *already* packages that do something similar (see below). > But my claim is that if the upstream can't manage to maintain a stable > ABI, then maybe we shouldn't be trying to ship shared libraries. But > officially, that's not allowed, since it's considered bad. Personally, to detect such upstreams I think Debian needs a service tracking ABI using abipkgdiff (from abigail-tools) and pkg-abidiff. Once we have that it isn't too much more work for Debian to maintain the SONAME instead of upstream. > If we have that solution for Rust and Golang, the maybe it can also > make life easier for upstreams that can't maintain an ABI. I initially mainly wanted it for static linking detection, I expect there is some of that (at least in -static packages) in Debian and that we are not thinking to rebuild such packages after security issues. Packages that have complex dependencies in shlibs/symbols files: $ grep -h '^lib.*,' /var/lib/dpkg/info/*.shlibs libbfd 2.37.50-multiarch.20220106 binutils-multiarch (>= 2.37.50.20220106), binutils-multiarch (<< 2.37.50.20220107) libopcodes 2.37.50-multiarch.20220106 binutils-multiarch (>= 2.37.50.20220106), binutils-multiarch (<< 2.37.50.20220107) libbctoolbox 1 libbctoolbox1 (>= 4.4.0), libbctoolbox1 (<< 4.5.0) libbellesip 1 libbellesip1 (>= 4.4.0), libbellesip1 (<< 4.5.0) libbfd 2.37.50-system.20220106 libbinutils (>= 2.37.50.20220106), libbinutils (<< 2.37.50.20220107) libopcodes 2.37.50-system.20220106 libbinutils (>= 2.37.50.20220106), libbinutils (<< 2.37.50.20220107) libboost_python39 1.74.0 libboost-python1.74.0 (>= 1.74.0), libboost-python1.74.0-py39 libeabutil 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libeabwidgets 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libecontacteditor 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libecontactlisteditor 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libecontactprint 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libemail-engine 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libessmime 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-addressbook-importers 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-calendar-importers 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-calendar 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-mail-composer 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-mail-formatter 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-mail-importers 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-mail 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-shell 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-smime 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libevolution-util 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libgnomecanvas 0 libevolution (>= 3.42.3), libevolution (<< 3.43) libgconf-2 4 libgconf-2-4 (>= 2.31.1), gconf-service libgnustep-base 1.28 libgnustep-base1.28 (>= 1.28.0), gnustep-base-runtime (>= 1.28.0) libortp 15 libortp15 (>= 1:4.4.0), libortp15 (<< 1:4.5.0) libphonon4qt5 4 libphonon4qt5-4 (>= 4:4.11.1), phonon4qt5 libtotem 0 libtotem0 (>= 3.38.2-1), libtotem0 (<< 3.39) $ grep -h ',.*<<' /var/lib/dpkg/info/*.symbols | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6 (>> 2.33), libc6 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) | libc6-i386 (>> 2.33), libc6-i386 (<< 2.34) |
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Sat, Jan 22, 2022 at 08:58:37AM +0800, Paul Wise wrote: > > The other thing that's perhaps considering here is that unfortunately, > > there are some upstreams that are extremely irresponsible with library > > ABI backwards compatibility, where they bump the SONAME essentially at > > every release. I recall one extreme case a few years ago where there > > were over ten(!) SONAME bumps for a particular library over 12 months. > > You could avoid NEW for these SONAME bumps by using a single binary > package and ensuring that the symbols/shlibs depend on the right > version ranges. Or add Provides libfoo-abi-N or libfoo-abi (= N) > and have the symbols and or shlibs generate dependencies on that. That only works if there are no other packages depending on those shared libraries which are coming from other source packages. After all, if the only consumers of those shared libraries is source package for those libraries, there's a much simpler solution --- just compiling the d*mned package using static linking, and just moving on. But if there are other packages which are using those shared libraries, then the official party line is that just shipping static libraries in libshaky-dev is bad, Bad, BAD, since it means that when there are security bugs fixed in the sources for libshaky, they aren't automatically fixed for all of the users of libshaky until they relink. But my claim is that if the upstream can't manage to maintain a stable ABI, then maybe we shouldn't be trying to ship shared libraries. But officially, that's not allowed, since it's considered bad. Unfortunately, that's effectively punishing maintainers who are supporting sources which support shared library. For those languages like Rust, etc., which don't support shared libraries, life is *much* simpler. > In the past I've suggested a solution to static linking and binary > packages containing source could be to have a service scanning every > binary package for static/source files (.a, Rust, Golang etc), noting > the relevant package/version tuples and then searching the buildinfo > files for binary packages that built with those packages installed and > automatically rebuilding affected packages, or having a service that > would let you manually rebuild packages affected by security issues. > > https://wiki.debian.org/StaticLinking If we have that solution for Rust and Golang, the maybe it can also make life easier for upstreams that can't maintain an ABI. (And yes, I don't have much patience with those folks given that e2fsprogs has had a stable library since 1997, which is the last time I've had to bump an SONAME for libext2fs. But that's because I'm careful, where as some other developers like for f2fs-tools, bump their SONAME every !@#@?! release. Sigh...) - Ted
Re: The future of src:ntp
Richard Laager wrote on 23/01/2022: > On 1/19/22 15:04, Bernhard Schmidt wrote: >> On 19.01.22 20:34, Richard Laager wrote: >>> 2. I create transitional binary packages in src:ntpsec: > > I got to thinking about this more. This won't work, because src:ntp is > 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch > (of 2, since ntp already has an epoch of 1) on ntpsec in order for > src:ntpsec's transitional bin:ntp package to be newer than src:ntp's > bin:ntp package. > > It might be technically possible to build a binary package with > different versioning, but even if it is: 1) I don't know how, One way it can be done is by creating d/changelog files which are specific to the binary package, e.g. debian/ntp.changelog debian/ntpdate.changelog (no idea if it can be a symlink) ... with their own version, different from the one in debian/changelog. Paride
Re: The future of src:ntp
On Jan 23, Richard Laager wrote: > It might be technically possible to build a binary package with different > versioning, but even if it is: 1) I don't know how, and 2) I'm not sure > whether that's a good idea, especially compared to the alternatives. I did it long ago, I think for kmod taking over module-init-tools: you just need to add an appropriate Version field to debian/control. -- ciao, Marco signature.asc Description: PGP signature
Re: using epoch to repair versioning of byacc package
> Date: Sun, 23 Jan 2022 14:55:39 -0600 > From: Richard Laager > To: debian-devel@lists.debian.org > Subject: Re: using epoch to repair versioning of byacc package > > On 1/23/22 10:04, Thomas Dickey wrote: > > In #1003769, Andreas Metzler wrote: > > > 1. The upload introduces an epoch because the upstream version went from > > > mmdd to 2.0.mmdd. Given that the new version scheme seems to > > > have found acceptance in e.g. Fedora /I/ do not see a better way. Could > > > you ask about the epoch on debian-devel (as per policy > > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly > > > ) - TIA. > > > > As background, byacc was packaged by Dave Becket in 2005, switching > > to my ftp area as upstream. In doing that, the versioning of the > > package changed: > > > > from > > -- LaMont Jones Fri, 26 Nov 2004 18:49:09 -0700 > > byacc (1.9.1-1) unstable; urgency=low > > to > > -- Dave Beckett Sun, 14 Aug 2005 10:14:12 +0100 > > byacc (20050505-1) unstable; urgency=low > > I see no other way to correct this but to add an epoch. agreed. Is there some way to further improve the transition? > As we see in this case, switching from version numbers to date-based > versions is dangerous because it's impossible to go back without an epoch. A > better version would have been something like 1.9.1+20050505. I suspect that providing an interim 1.9.1+20140715 with/without an epoch would have problems going backward. But there might be some way to do that. > Lintian flags on this, but (according to the name and description) only for > new packages: > https://lintian.debian.org/tags/new-package-uses-date-based-version-number > > Personally, I'd like to see that lintian check fire if the date-based > versioning is new. That is, it should fire if the previous changelog entry > did not have a date-based version. yes... but it's a little late for that (I've only learned about these issues in the process of setting up the upgrade). > Even better would be a dak (or whatever ftp-master tool is relevant) hard > fail if going from non-date-based to date-based at the front of the version > string. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: The future of src:ntp
On Sun, 23 Jan 2022 at 15:12:49 -0600, Richard Laager wrote: > > > 2. I create transitional binary packages in src:ntpsec: > > I got to thinking about this more. This won't work, because src:ntp is > 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of > 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's > transitional bin:ntp package to be newer than src:ntp's bin:ntp package. > > It might be technically possible to build a binary package with different > versioning It is. > but even if it is: 1) I don't know how, and 2) I'm not sure > whether that's a good idea, especially compared to the alternatives. 1) something like this (untested) will give you ntpsec_1.2.1+dfsg1-2 and ntp_2:1.2.1+dfsg1-2 packages: override_dh_gencontrol: dh_gencontrol -pntp -- -v2:$(DEB_VERSION_UPSTREAM_REVISION) dh_gencontrol --remaining-packages 2) If you are going to build ntp.deb from src:ntpsec, then I think this is a lot better than adding an epoch to the whole source package (i.e. d/changelog) of src:ntpsec, because it can eventually go away (when the transitional package does). I'm not sure whether building transitional packages from src:ntpsec with this technique is better or worse than having a src:ntp that only builds transitional packages. smcv
Re: The future of src:ntp
On 1/19/22 15:04, Bernhard Schmidt wrote: On 19.01.22 20:34, Richard Laager wrote: 2. I create transitional binary packages in src:ntpsec: I got to thinking about this more. This won't work, because src:ntp is 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's transitional bin:ntp package to be newer than src:ntp's bin:ntp package. It might be technically possible to build a binary package with different versioning, but even if it is: 1) I don't know how, and 2) I'm not sure whether that's a good idea, especially compared to the alternatives. What do you think about the other approach of having src:ntp build the transitional packages? I think that looks like this: 1. I split out ntpdig, as suggested in #1003966. This is presumably ntpsec-ntpdig for consistency with the rest being ntpsec-*. 2. You (or I adopt and) create transitional binary packages in src:ntp, as 1:4.2.8p15+dfsg-2, 1:4.2.8p15+fake, 1:4.2.8p15+transitional, 1:4.2.8p16~transitional, or something else > 1:4.2.8p15+dfsg-1, with an empty upstream tarball: ntp -> ntpsec ntp-doc -> ntpsec-doc ntpdate -> ntpsec-ntpdate sntp -> ntpsec-ntpdig with an sntp -> ntpdig symlink 3. Upload that to experimental. People review. 4. Upload to unstable. 5. After bookworm releases, you (or I, if I adopted src:ntp) request removal of src:ntp. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: using epoch to repair versioning of byacc package
On 1/23/22 10:04, Thomas Dickey wrote: In #1003769, Andreas Metzler wrote: 1. The upload introduces an epoch because the upstream version went from mmdd to 2.0.mmdd. Given that the new version scheme seems to have found acceptance in e.g. Fedora /I/ do not see a better way. Could you ask about the epoch on debian-devel (as per policy https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly ) - TIA. As background, byacc was packaged by Dave Becket in 2005, switching to my ftp area as upstream. In doing that, the versioning of the package changed: from -- LaMont Jones Fri, 26 Nov 2004 18:49:09 -0700 byacc (1.9.1-1) unstable; urgency=low to -- Dave Beckett Sun, 14 Aug 2005 10:14:12 +0100 byacc (20050505-1) unstable; urgency=low I see no other way to correct this but to add an epoch. As we see in this case, switching from version numbers to date-based versions is dangerous because it's impossible to go back without an epoch. A better version would have been something like 1.9.1+20050505. Lintian flags on this, but (according to the name and description) only for new packages: https://lintian.debian.org/tags/new-package-uses-date-based-version-number Personally, I'd like to see that lintian check fire if the date-based versioning is new. That is, it should fire if the previous changelog entry did not have a date-based version. Even better would be a dak (or whatever ftp-master tool is relevant) hard fail if going from non-date-based to date-based at the front of the version string. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Fri, Jan 21, 2022 at 7:04 PM Paul Gevers wrote: > > It's not only the copyright that the ftp-master are responsible for. New > binaries fill a place in the Debian namespace and they *are* the keepers > of that. One could say that for new binaries packages whose src is already in Debian, the ftp-masters skip the d/copyright review and only do the other tasks. This should allow for way quicker transitions of simple SOVERSION bumps. In general I prefer a random d/copyright check more than one based on the introduction of a new binary, as I just don't see any connection between a new binary name and a change of copyright. Regards, Stephan
Re: using epoch to repair versioning of byacc package
In #1003769, Andreas Metzler wrote: > 1. The upload introduces an epoch because the upstream version went from > mmdd to 2.0.mmdd. Given that the new version scheme seems to > have found acceptance in e.g. Fedora /I/ do not see a better way. Could > you ask about the epoch on debian-devel (as per policy > https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly > ) - TIA. As background, byacc was packaged by Dave Becket in 2005, switching to my ftp area as upstream. In doing that, the versioning of the package changed: from -- LaMont Jones Fri, 26 Nov 2004 18:49:09 -0700 byacc (1.9.1-1) unstable; urgency=low to -- Dave Beckett Sun, 14 Aug 2005 10:14:12 +0100 byacc (20050505-1) unstable; urgency=low My (upstream) byacc tarballs have been named according to the patchdate. The program itself identifies with the complete version using "-V" option, which I added a few months before the Debian package change: 2005-05-04 Thomas E. Dickey * yacc.1: add -V option * main.c: add -V option to print the version. simplify option-parsing by moving the duplicate logic for setting flags into new function setflag(). * skeleton.c: move the actual definition of YYMAJOR and YYMINOR to defs.h (as numbers). add YYPATCH here so it can be tested by applications. * defs.h: add macros to define VERSION in terms of the (numeric) YYMAJOR, YYMINOR and YYPATCH symbols. * lalr.c, lr0.c, mkpar.c, defs.h, closure.c, warshall.c, output.c, symtab.c: reduce externs by making static the procedures that are not referenced outside the module in which they are defined. * makefile.in: the VERSION file holds the patch-date. Define YYPATCH, so this will be compiled into the skeleton. * VERSION: patch-level for byacc The policy cited above says Note that the purpose of epochs is to cope with situations where the upstream version numbering scheme changes and to allow us to leave behind serious mistakes. If you think that increasing the epoch is the right solution, you should consult debian-devel and get consensus before doing so (even in experimental). The version policy here: https://www.debian.org/doc/debian-policy/ch-controlfields.html#version says The version number of a package. The format is: [epoch:]upstream_version[-debian_revision]. epoch This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. Epochs can help when the upstream version numbering scheme changes, but they must be used with care. You should not change the epoch, even in experimental, without getting consensus on debian-devel first. upstream_version This is the main part of the version number. It is usually the version number of the original (“upstream”) package from which the .deb file has been made, if this is applicable. Usually this will be in the same format as that specified by the upstream author(s); however, it may need to be reformatted to fit into the package management system’s format and comparison scheme. The upstream version number (which is displayed using the "-V" option) shows the full version rather than the patchdate used for naming the tar files, e.g., byacc - 2.0 20220114 At the time Becket switched to my version of byacc, that would have printed byacc - 1.9 20050505 Since then, a) Dave Becket stopped maintaining the package (in 2014), and b) I released byacc 2.0 (September 10, 2019), to account for integrating the back-tracking feature beginning in 2014. Having Debian's package so far out of date is a nuisance, and on being reminded of this a few months ago, I decided to update the package. The Debian policy quoted above seems to assume that the Debian package is good, and that some allowance must be made for problems in upstream. However, it isn't that simple. Upstream identified the version in a conventional manner, but not in a manner which the packager noticed or found convenient for packaging. The upstream versioning scheme has not changed -- but the package version does not use upstream's version. Just changing this is also not simple. Adding the full (1.9 or 2.0 version to the Debian package runs into the problem that in Debian, "2.0.20220114" is less than "20140422" because "2" is the part that apt uses for comparison. The Debian-style workaround for this is to add an epoch, which I have done in https://mentors.debian.net/package/byacc/ -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1004245: ITP: ocsipersist -- Persistent key/value storage for Ocsigen using multiple backends
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocsipersist Version : 1.0.5 Upstream Author : Vincent Balat * URL : https://ocsigen.org/ocsipersist * License : LGPL-2.1 Programming Lang: OCaml Description : persistent key/value storage for Ocsigen using multiple backends Ocsipersist is used pervasively in Eliom/Ocsigen to handle sessions and references. It can be used as an extension for ocsigenserver or as a library. Implementations of the following backends currently exist: PostgreSQL, SQLite. This used to be part of ocsigenserver, and has been split out to its own package upstream. It is a dependency of eliom. It will be maintained in the OCaml team.
Another big update of /etc/mime.types
Hello everybody,
Today I uploaded another big update of /etc/mime.types with the
`media-types` package version 5.0.0. I expect it is the last one of
that scale as now the file is fully in sync with the registered types at
the IANA.
I might do more removals of types in the future, but before doing so, I
check Internet search engines, codesearch.debian.net, the source code of
the `file` package and Share MIME Info via `/usr/share/mime` so I expect
it to be safe.
>From now one, if one of you wants to add a type that was freshly
regstered to the IANA registry, please feel free to go for a Team Upload
if you are a DD, and update the package's source repository on Salsa
accordingly.
The remaining major tasks with the package are to conclude on
case-sensitivity of file suffixes and resolve the remaining duplicates
(art,asn,aso,chm,cif,cml,cpt,csh,fm,frm,gsm,mpc,pdb,sce,sdf,sh,shp,shx,tcl).
For you information, here is the changelog of todays update.
Have a nice day,
-- Charles
media-types (5.0.0) unstable; urgency=medium
Types changed:
26cc8f9 Change GIMP's application/x-xcf to image/x-xcf.
Thanks to Joel Hockey (Closes: #991158)
956d82e Uppercased audio/QCELP as in the IANA documents.
72781ac Uppercased text/SGML and application/SGML as in IANA.
bfc437b Uppercased application/IOTP, application/ISUP, application/QSIG.
39cbba4 Uppercased application/CALS-1840, a/EDI-consent and a/ODA.
723e182 Corrected application/vq-rtcp-xr to application/vq-rtcpxr.
c9818e3 Corrected 'ense' to 'ence' in a/vnd.piaccess.application-licence.
dbc72aa Corrected '-' to '.' in application/vnd.efi.img and a/vnd.efi.iso.
091fe07 Corrected model/x3d+vrml to model/x3d-vrml.
6ddcb9e Remove non-registered ('*/x-*') types with no file extension:
application/x-core, application/x-executable,
application/x-java-applet, application/x-java-bean,
application/x-kdelnk, application/x-pki-message, application/x-rx,
application/x-shellscript, application/x-videolan,
application/x-www-form-urlencoded, application/x-x509-ca-ra-cert,
application/x-x509-next-ca-cert, audio/x-pn-realaudio-plugin,
image/x-icon, text/x-makefile, text/x-server-parsed-html
6834f86 Removed text/x-crontab (no file extension).
20ef945 Removed x-world/x-vrml, gave vrm extension to model/xml,
added x3dz extension to model/x3d+xml
47a46bc Removed obsolete and unregistered x-epoc/x-sisx-app (ext: sisx)
8b518ce Removed obsolete undeclared type x-conference/x-cooltalk (ext: ice)
0ce50aa Remove unregistered application types that extensions:
application/cap+xml, application/docbook+xml, application/ghostview
application/ms-tnef, application/news-message-id,
application/vnd.tve-trigger
dca94fb Remove text types with no extension or no apparent use.
text/english, text/h323, text/iuls, text/richtext, text/scriptlet,
text/vnd.flatland.3dml
dadf927 Remove unregistered extensionless video/vnd.mts.
4473324 Removed application/x-ms-manifest: (ext: manifest).
fb4ad41 Removed application/x-ms-application (ext: application).
319889b Remvoved extension from image/t38.
8cb03f0 Added file extension smf to application/vnd.stardivision.math
Types added:
943d860 Added image/jxl (Closes: #987395).
fbee352 Added image/avif
74d5493 Added audio/scip
7d98212 Added video/AV1, video/FFV1, video/jxsv, video/scip and video/VP9
1289cba Added text/fhirpath, text/cql-extension, text/cql-identifier, text/cql
ecfeac2 Added text/gff3 and text/shaclc
063d184 Added text/spdx and application/spdx+json
b0eb56e Added text/shex, text/vnd.familysearch.gedcom, text/vnd.hans
eb47d5e Added application/elm+json and application/elm+xml
ff44383 Added application/vnd.veritone.aion+json and application/vnd.wfa.dpp
81f79f9 Added application/vnd.sycle+xml and application/vnd.syft+json
b5ec7a2 Added application/vnd.resilient.logic and application/vnd.seis+json
5dcf147 Added application/vnd.opentimestamps.ots
06c9422 Added application/vnd.nebumind.line and application/vnd.oma.lwm2m+cbor
182621c Added application/vnd.las, application/mipc and application/sipc
60f54a2 Added application/vnd.nacamar.ybrid+json
5cb2a4a Added application/vnd.hl7v2+xml and application/vnd.hl7cda+xml
7526702 Added application/vnd.geogebra.slides
09f65bc Added application/vnd.fujifilm.fb.docuworks,
application/vnd.fujifilm.fb.docuworks.binder
application/vnd.fujifilm.fb.docuworks.container
application/vnd.fujifilm.fb.jfi+xml
d16a2e2 Added application/vnd.familysearch.gedcom+zip
8f6b0ff Added application/vnd.eu.kasparian.car+json
a5f5fba Added application/vnd.d3m-dataset and application/vnd.d3m-problem
597488a Added application/vnd.cyclonedx+json and application/vnd.cyclonedx+xml
8f81fab Added a/vnd.cryptomator.encrypted and a/vnd.cryptomator.vault
51f1b9a Added application/vnd.apache.arrow
