Recommending packages via virtual package
Hey all, not sure if this has been discussed elsewhere, but I recently noticed a change in APTs lookup for Recommends. Maybe also for other dependencies. Many packages recommend a webserver like this: > Recommends: apache2 | httpd Apparently this no longer works. When I install a package like nginx and then a package recommending a web server, APT will still try to install apache2. > apt install -y nginx > apt install wordpress I would expect APT to stay with any package that provides "httpd" and accept the recommendation as fulfilled. This happens in Buster and current sid. The policy guide does not really mention this [1], but it certainly worked before. And AFAIK it is a wide spread usage. What are your thoughts on that? Is there any other thread discussing this? The current bugs for apt touching on virtual package don't really mean this behavior. Regards Markus Frosch [1] https://www.debian.org/doc/debian-policy/ch-relationships.html -- lazyfro...@debian.org https://lazyfrosch.de
Re: RFC: Standardizing source package artifacts build paths
Sam Hartman: > I'm concerned about a leading . at least for: > > * the debian/tmp replacement > * the replacement for the package install directories under debian. > > I think that maintaining those directories such that ls shows them will > be more friendly for new maintainers. > So I'd prefer something like debian/build rather than debian/.build for > at least those directories. > > I don't care as much about substvars, debhelper intermediates, debhelper > logs and the like. > Hi, Guillem and I have debated this and come to a solution, which we believe will be able to address the concerns about the path being "hidden". It also enables us to simplify parts of the migration in some cases. The short version of that solution is to enable debhelper to expose the relevant directories where you want it and under debian/.build at the same time (the latter being a symlink to the former)[1]. This can be made to cover the directories you mention above, but also e.g. the build directory for upstream builds, which was mentioned elsewhere in this thread. Based on the feedback so far, I will go with the following defaults in debhelper: * build directories are exposed if -B/--builddirectory is used to request it. If there is no explicit -B/--builddirectory, it will (in a new compat level) be hidden by default. * The staging directories a la d/tmp will be exposed if --destdir is used with dh_auto_install. - I will expose d/tmp by default for now but "parallel" d/tmp-X dirs are not (they currently require a --destdir to work as it is now). * d/ are exposed by default for now. Any other debhelper artifact will move to a new path in a future compat level (at this stage, we are talking debhelper/14 rather than debhelper/13). ~Niels [1] Note that dpkg will migrate to always use the paths under debian/.build. This should not matter in practise unless you fiddle with the symlinks that debhelper creates.
Re: Recommending packages via virtual package
Am 14.04.20 um 10:26 schrieb Markus Frosch: > What are your thoughts on that? Is there any other thread > discussing this? The current bugs for apt touching on virtual > package don't really mean this behavior. I can not reproduce your problem in a sid chroot. When nginx (nginx-full to be precise) is installed, apache2 will not be installed here: > root@pluto:/# apt-cache policy nginx nginx-full > nginx: > Installed: 1.16.1-3 > Candidate: 1.16.1-3 > Version table: > *** 1.16.1-3 500 > 500 http://ftp.de.debian.org/debian sid/main amd64 Packages > 100 /var/lib/dpkg/status > nginx-full: > Installed: 1.16.1-3 > Candidate: 1.16.1-3 > Version table: > *** 1.16.1-3 500 > 500 http://ftp.de.debian.org/debian sid/main amd64 Packages > 100 /var/lib/dpkg/status > root@pluto:/# apt install wordpress > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following additional packages will be installed: > apache2-bin ca-certificates default-mysql-client libaio1 libapache2-mod-php > libapache2-mod-php7.4 libapr1 > libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libargon2-1 libbrotli1 > libconfig-inifiles-perl libcurl4 > libedit2 libgssapi-krb5-2 libjansson4 libjs-cropper libjs-prototype > libjs-scriptaculous libjs-underscore > libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libldap-2.4-2 > libldap-common liblua5.2-0 libmagic-mgc > libmagic1 libnghttp2-14 libpsl5 libreadline5 librtmp1 libsasl2-2 > libsasl2-modules-db libsnappy1v5 libsodium23 > libssh2-1 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-common > mime-support mysql-common openssl > php-common php-gd php-getid3 php-mysql php7.4-cli php7.4-common php7.4-gd > php7.4-json php7.4-mysql > php7.4-opcache php7.4-readline psmisc readline-common > Suggested packages: > apache2-doc apache2-suexec-pristine | apache2-suexec-custom www-browser > php-pear krb5-doc krb5-user file > php-com-dotnet php-mbstring php-rar php-xml php-sqlite3 readline-doc > default-mysql-server > | virtual-mysql-server php-ssh2 > Recommended packages: > apache2 javascript-common libjs-jquery krb5-locales publicsuffix > libsasl2-modules libdbd-mysql-perl > libdbi-perl libterm-readkey-perl file vorbis-tools wordpress-l10n > wordpress-theme-twentytwenty > The following NEW packages will be installed: > apache2-bin ca-certificates default-mysql-client libaio1 libapache2-mod-php > libapache2-mod-php7.4 libapr1 > libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libargon2-1 libbrotli1 > libconfig-inifiles-perl libcurl4 > libedit2 libgssapi-krb5-2 libjansson4 libjs-cropper libjs-prototype > libjs-scriptaculous libjs-underscore > libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libldap-2.4-2 > libldap-common liblua5.2-0 libmagic-mgc > libmagic1 libnghttp2-14 libpsl5 libreadline5 librtmp1 libsasl2-2 > libsasl2-modules-db libsnappy1v5 libsodium23 > libssh2-1 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-common > mime-support mysql-common openssl > php-common php-gd php-getid3 php-mysql php7.4-cli php7.4-common php7.4-gd > php7.4-json php7.4-mysql > php7.4-opcache php7.4-readline psmisc readline-common wordpress > 0 upgraded, 59 newly installed, 0 to remove and 0 not upgraded. > Need to get 24.5 MB of archives. > After this operation, 137 MB of additional disk space will be used. > Do you want to continue? [Y/n] signature.asc Description: OpenPGP digital signature
Re: Recommending packages via virtual package
Am 14.04.20 um 11:49 schrieb Michael Biebl: > Am 14.04.20 um 10:26 schrieb Markus Frosch: > >> What are your thoughts on that? Is there any other thread >> discussing this? The current bugs for apt touching on virtual >> package don't really mean this behavior. > > I can not reproduce your problem in a sid chroot. > When nginx (nginx-full to be precise) is installed, apache2 will not be > installed here: > Please disregard what I said. I forgot that my chroot had Recommends disabled... signature.asc Description: OpenPGP digital signature
Bug#956682: ITP: feedbackd -- DBus service for haptic/visual/audio feedback
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris * Package name: feedbackd Version : 0.0.0+git20200305 Upstream Author : Purism SPC * URL : https://source.puri.sm/Librem5/feedbackd * License : GPL-3+ and LGPL-2.1+ Programming Lang: C Description : DBus service for haptic/visual/audio feedback Feedbackd is a DBus activated daemon that provides haptic/visual/audio feedback based on events. It is a dependency to Phosh, a Wayland shell for mobile devices, which I also plan to package, and as such will be useful for bringing Debian to mobile phones. I take the responsibility for maintaining this package.
Re: trends.debian.net updated
On Sun, Apr 12, 2020 at 09:11:57PM +0200, Ole Streicher wrote: > Wouter Verhelst writes: > > On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote: > >> Adam Borowski writes: > >> > Idea: perhaps we could make no unrestricted (maintainer, team, or QA) > >> > upload > >> > for 10 years a RC bug on its own? That threshold could then be gradually > >> > reduced to eg. 5 years, as worst offenders get fixed. > >> > >> One could deprecate old Standards-Version and require a version not that > >> was not superceded for more than five years. > > > > That's not what Standards-Version means. > > > > You don't get to say "I know my package does not comply with current > > Policy, but the Standards-Version claims an old version of Policy so > > that's fine". You must always be compliant with current policy (in > > unstable), and if policy changes in ways that apply to your package, you > > need to update it. > > > > One of my packages, logtool, hasn't seen an upstream change since the > > early naughties, and as a result there are 7 years between logtool > > 1.2.8-8 and logtool 1.2.8-9. > > > > That however didn't mean it wasn't maintained, just that it didn't need > > any update in 7 years. > > > > The only reason for Standards-Version to exist is so that when you or > > whoever comes after you look at things a few days/weeks/months/years > > down the line, you know what has changed in Policy since it was last > > touched and can use upgrading-checklist.txt > > In my understanding the Standards-Version documents up to which policy > version a package was checked for compliance. Yes. > One could expect from maintainers that they check their packages for > compliance regularly and that they document that. Perhaps, but it is *also* documented that an upload just to bump the Standards-Version is severely frowned upon. If there is no other reason to upload in 7 years, then the Standards-Version will not be updated, and that is perfectly fine. > For a package that had no documented check for seven years it is OK to > file an RC bug in order to clarify the compliance. Hell no. If you find that the 7-year-old package does not comply with policy in some way because it is outdated (or for whatever other reason), then sure, by all means file a bug at correct severity (RC if it is that). But "this package is feature-complete and hasn't required an update in seven years" is a feature, not a bug. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: Recommending packages via virtual package
On Tue, Apr 14, 2020 at 10:26:54AM +0200, Markus Frosch wrote: > Apparently this no longer works. When I install a package like nginx > and then a package recommending a web server, APT will still try to > install apache2. > > > apt install -y nginx > > apt install wordpress Lets ignore for the moment that wordpress actually doesn't have the recommends line which is the TOPIC OF THE THREAD, but has instead a "Depends: apache2 | httpd" among other things (← hint hint): $ apt install wordpress nginx -so Debug::pkgDepCache::Marker=1 […] MarkInstall nginx:amd64 < none -> 1.16.1-3 @un puN Ib > FU=1 […] MarkInstall wordpress:amd64 < none -> 5.4+dfsg1-1 @un puN Ib > FU=1 MarkInstall libapache2-mod-php:amd64 < none -> 2:7.4+75 @un uN Ib > FU=0 MarkInstall libapache2-mod-php7.4:amd64 < none -> 7.4.3-4 @un uN Ib > FU=0 […] MarkInstall apache2:amd64 < none -> 2.4.43-1 @un uN Ib > FU=0 […] So, the reason you get apache2 installed is the second(!) dependency: "libapache2-mod-php | libapache2-mod-php5 | php | php5" which isn't THAT surprising or very hard to find, is it? I would hence ask you to explain a bit better why you think APT is wrong and provide an example which actually shows these characteristics. Otherwise I will apparently be a tiny bit annoyed by this thread. Best regards David Kalnischkies P.S.: For these cases -o Debug::pkgDepCache::AutoInstall=1 shows pretty much the same with less scary details. I just picked Marker as it is literally the first think I try and as I implemented the display of these "@un puN Ib" flags they are a little less scary for me. signature.asc Description: PGP signature
Bug#956705: ITP: python-pydiscourse -- Python library for working with Discourse
Package: wnpp Severity: wishlist Owner: Martin * Package name: python-pydiscourse Version : v1.0.0 Upstream Author : Marc Sibson and contributors * URL : https://github.com/bennylope/pydiscourse * License : MIT Programming Lang: Python Description : Python library for working with Discourse >From the README: > A Python library for working with Discourse. > > This is a fork of the original Tindie version. It was forked > to include fixes, additional functionality, and to distribute > a package on PyPI. > > Goals > > * Exceptional documentation > * Support all supported Python versions > * Provide functional parity with the Discourse API, for the > currently supported version of Discourse (something of a > moving target) > > The order here is important. The Discourse API is itself > poorly documented so the level of documentation in the Python > client is critical.
Re: Recommending packages via virtual package
On Tue, 2020-04-14 at 15:19 +0200, David Kalnischkies wrote: > Lets ignore for the moment that wordpress actually doesn't have the > recommends line which is the TOPIC OF THE THREAD, but has instead a > "Depends: apache2 | httpd" among other things (← hint hint): > > $ apt install wordpress nginx -so Debug::pkgDepCache::Marker=1 > […] > MarkInstall nginx:amd64 < none -> 1.16.1-3 @un puN Ib > FU=1 > […] > MarkInstall wordpress:amd64 < none -> 5.4+dfsg1-1 @un puN Ib > FU=1 > MarkInstall libapache2-mod-php:amd64 < none -> 2:7.4+75 @un uN Ib > FU=0 > MarkInstall libapache2-mod-php7.4:amd64 < none -> 7.4.3-4 @un uN Ib > > FU=0 > […] > MarkInstall apache2:amd64 < none -> 2.4.43-1 @un uN Ib > FU=0 > […] > > So, the reason you get apache2 installed is the second(!) dependency: > "libapache2-mod-php | libapache2-mod-php5 | php | php5" which isn't THAT > surprising or very hard to find, is it? You are right, PHP meta packages are the problem. The effective package was icingaweb2, but I tried to use a more commonly known package for my question. > I would hence ask you to explain a bit better why you think APT is wrong > and provide an example which actually shows these characteristics. > Otherwise I will apparently be a tiny bit annoyed by this thread. Why so passive aggressive here? I asked for help and tried to explain in a short and simple way. I'm not very deep into APTs debugging features in terms of dependencies. Thanks for pointing me in the right direction. Regards Markus -- lazyfro...@debian.org https://lazyfrosch.de
Re: trends.debian.net updated
On Tue, 2020-04-14 at 13:12 +0200, Wouter Verhelst wrote: > On Sun, Apr 12, 2020 at 09:11:57PM +0200, Ole Streicher wrote: [...] > > One could expect from maintainers that they check their packages for > > compliance regularly and that they document that. > > Perhaps, but it is *also* documented that an upload just to bump the > Standards-Version is severely frowned upon. If there is no other reason > to upload in 7 years, then the Standards-Version will not be updated, > and that is perfectly fine. [...] If a package hasn't been uploaded for 7 years, then: * At least some of its binary packages were probably built by the uploader, not on a buildd * If it's written in C or C++, it hasn't been built with all the current hardening options that should be used * Its binary packages probably aren't repoducible * It may not build correctly with the current build tools (failure to build at all would usually be caught and reported, though) I think we should be rebuilding everything at least once per release cycle, so we don't have a nasty surprise when these "mature" packages need bug fixes. Ben. -- Ben Hutchings Everything should be made as simple as possible, but not simpler. - Albert Einstein signature.asc Description: This is a digitally signed message part
Re: trends.debian.net updated
On Tue, Apr 14, 2020 at 05:36:37PM +0100, Ben Hutchings wrote:
> On Tue, 2020-04-14 at 13:12 +0200, Wouter Verhelst wrote:
> > Perhaps, but it is *also* documented that an upload just to bump the
> > Standards-Version is severely frowned upon. If there is no other reason
> > to upload in 7 years, then the Standards-Version will not be updated,
> > and that is perfectly fine.
And for this reason using Standards-Version to measure outdateness of a
package won't work. Also, if it became RC, the obvious "fix" would be a
NMU to bump it, without doing unrelated fixes to the package (as forbidden
by NMU rules).
Thus, I argue that only an unrestricted upload (maintainer, team or QA)
should reset the clock.
> If a package hasn't been uploaded for 7 years, then:
>
> * At least some of its binary packages were probably built by the
> uploader, not on a buildd
> * If it's written in C or C++, it hasn't been built with all the
> current hardening options that should be used
> * Its binary packages probably aren't repoducible
These are just three examples of _current_ topics. Those mature packages
probably still don't have build-arch/indep, or perhaps config.guess or so
on, problems the rest of Debian solved a decade ago.
Upstream code can be considered done, packaging is an on-going process.
> * It may not build correctly with the current build tools (failure to
> build at all would usually be caught and reported, though)
>From time to time we have "cleaning events" such as removal of compat < 5.
That was great for a drive-by review of old packages. Alas, we have a bunch
of well-meaning contributors mass-fixing FTBFS bugs via NMUs. That's good
for preserving packages for use by our users, but not so good for their
quality.
Thus, forcing a person to visit a package every 5/7/10 years would solve
this. If the maintainer is still there, {,s}he knows best whether the
package should be kept, orphaned or removed. If the maintainer is MIA or
doesn't have the slightest bit of tuits to actually maintain the package,
the package can't be said to be maintained at all. In such a case, someone
from the QA team[1] has the opportunity to triage the package.
A package being orphaned means "fixes welcome". A package falsely claimed
to be maintained is "fixes are blackholed".
> I think we should be rebuilding everything at least once per release
> cycle, so we don't have a nasty surprise when these "mature" packages
> need bug fixes.
There's enough automated testing to spot FTBFS, thus rebuilding would only
recompile against updated toolchain. That's a good idea, but I say we need
a human look once in a longer while.
Meow!
[1]. Everyone is a member of QA.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Re: trends.debian.net updated
On 14/04/20 at 19:40 +0200, Adam Borowski wrote: > > I think we should be rebuilding everything at least once per release > > cycle, so we don't have a nasty surprise when these "mature" packages > > need bug fixes. > > There's enough automated testing to spot FTBFS, thus rebuilding would only > recompile against updated toolchain. That's a good idea, but I say we need > a human look once in a longer while. Those packages are also unlikely to have a test suite. They might build, but the resulting binaries might not work. Lucas
Re: Recommending packages via virtual package
On Tue, Apr 14, 2020 at 04:45:55PM +0200, Markus Frosch wrote:
> > I would hence ask you to explain a bit better why you think APT is wrong
> > and provide an example which actually shows these characteristics.
> > Otherwise I will apparently be a tiny bit annoyed by this thread.
>
> Why so passive aggressive here? I asked for help and tried to explain in a
> short and simple way.
Frankly, I was just honest as this thread-style annoys the heck out of me,
but I guess I could have worded that a bit differently to make more obvious
what I mean. So, let me explain where my anger comes from:
You started with:
| not sure if this has been discussed elsewhere, but I recently noticed
| a change in APTs lookup for Recommends. Maybe also for other dependencies.
So, you "asked for help", but not in debugging APT or related, but in finding
where this change/bug in APT is discussed, providing your opinion on why the
change should be fixed/reverted ("policy", "wide spread usage") and asking
others to join in ("What are your thoughts on that?" [that = the change]).
Or in other words: You were asking for help in forming a mob to force the bad
apt devs into behaving (slightly exaggerated for effect).
That your example is both not showing the described problem and easy to
reason about showing that the bug you have postulated doesn't exist is
"just" icing on the "It is obviously APTs fault" cake.
It isn't what you meant to say of course, but you would be surprised how often
that style is used rather than the intended "I have no idea why APT does that
here, could someone please explain it?".
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Re: RFC: Standardizing source package artifacts build paths
Hello, On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote: > Guillem and I have debated this and come to a solution, which we believe > will be able to address the concerns about the path being "hidden". It > also enables us to simplify parts of the migration in some cases. Thank you for your continued efforts! > The short version of that solution is to enable debhelper to expose the > relevant directories where you want it and under debian/.build at the > same time (the latter being a symlink to the former)[1]. Sorry, but don't you mean the former (non-dotdirs) being a symlink to the latter (.build)? -- Sean Whitton signature.asc Description: PGP signature
Re: trends.debian.net updated
On Tue, 2020-04-14 at 20:32 +0200, Lucas Nussbaum wrote: > On 14/04/20 at 19:40 +0200, Adam Borowski wrote: > > > I think we should be rebuilding everything at least once per release > > > cycle, so we don't have a nasty surprise when these "mature" packages > > > need bug fixes. > > > > There's enough automated testing to spot FTBFS, thus rebuilding would only > > recompile against updated toolchain. That's a good idea, but I say we need > > a human look once in a longer while. > > Those packages are also unlikely to have a test suite. They might build, > but the resulting binaries might not work. Which is why I think we need to rebuild anyway, and have users of testing/unstable report such regressions. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
