Recommends-If-Manual: ?
> Russ Allbery writes: > Ivan Shmakov writes: > Adam Borowski writes: >>> libtasn1-doc: libtasn1-6-dev >>> * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is), >>> pulled in by a very-widespread library (gnutls) >> That’s Abstract Syntax Notation One (or ASN.1), and while I use it >> all the time (notation, that is; not this specific library at the >> moment), I see no reason for a -dev package to depend on a -doc one >> any stronger than with a mere Suggests:. > We have some specific Policy about this: > https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional […] > package should declare at most a Suggests on package-doc. Otherwise, > package should declare at most a Recommends on package-doc. > If you feel that this should cap the dependency at Suggests across > the board, feel free to submit a bug against debian-policy. Actually, no, “transitively bad” above seems like a correct assessment. While I dislike adding any more complexity to APT dependencies, can there perhaps be a separate Recommends-If-Manual: list of packages to only be installed when the depending package is marked as manually installed (as per apt-mark(8); and when recommended packages are otherwise considered for installing, as per APT::Install-Recommends)? To ensure backward compatibility, this condition would have to also apply for the packages also in the Recommends: list. Moreover, for one release cycle, any packages with Recommends-If-Manual: would have to have that same dependencies duplicated in Recommends: as well. […] -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Bug#864646: ITP: golang-github-dcso-bloom -- highly efficient Bloom filter library for Go
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: golang-github-dcso-bloom Version : 0.0~git20170609.0.48c97c2-1 Upstream Author : DCSO GmbH * URL : https://github.com/DCSO/bloom * License : BSD-3-clause Programming Lang: Go Description : highly efficient Bloom filter library for Go This toolkit provides a very efficient implementation of Bloom filters for the Go language. It also provides a command line tool that can be used to easily create Bloom filters with desired capacity and false positive probability. Values can be added to filters through standard input, which makes it easy to use the tool in a pipeline workflow.
Bug#864653: ITP: node-stream-http -- Streaming http in the browser
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-stream-http Version : 2.7.1 Upstream Author : John Hiesey * URL : https://github.com/jhiesey/stream-http#readme * License : Expat Programming Lang: JavaScript Description : Streaming http in browser context This module is an implementation of Node's native http module for the browser. It tries to match Node's API and behavior as closely as possible, but some features aren't available, since browsers don't give nearly as much control over requests. This is heavily inspired by, and intended to replace, http-browserify. . Node.js is an event-based server-side JavaScript engine.
Re: Too many Recommends (in particular on mail-transport-agent)
On Fri, Jun 09, 2017 at 03:21:25PM +0100, Ben Hutchings wrote: > On Fri, 2017-06-09 at 03:02 -0400, Anthony DeRobertis wrote: > [...] > > firmware-linux Recommends: amd64-microcode > > firmware-linux-nonfree Recommends: amd64-microcode > > > > This machine has an Intel CPU. It should probably recommend > > intel-microcode | amd64-microcode instead of both. Though we are > > talking about an Installed-Size of 68 here. > [...] > > Then APT would never automatically install amd64-microcode. True. Apt doesn't really have a good solution to that. The only thing I've seen is Recommends: cpu-microcode-all | cpu-microcode and having a cpu-microcode-all package that Depends on both, and having the two real package Provides cpu-microcode. If I remember correctly, Xorg did this at one point for video drivers (maybe still does). Of course—for the under 100K being saved here, only Rube Goldberg would approve.
Re: Too many Recommends (in particular on mail-transport-agent)
On Mon, 12 Jun 2017, Anthony DeRobertis wrote: > Of course—for the under 100K being saved here, only Rube Goldberg would > approve. It is a bit less than 1MiB saved on an AMD system when you purge intel-microcode, but even that is likely to not be considered worth the cost of the extra (empty) cpu-microcode-all package. Besides, it is not like these packages waste valuable resources when installed on a system they don't support, either: by default, once installed, they detect the processor vendor and go inactive when it doesn't match the one they are for. That said, if anyone provides a compelling reason to switch to the cpu-microcode-all + virtual cpu-microcode scheme (as in: give examples of how the behavior changes on widely used package managers), and gets the buy-in from the firmware-nonfree package, I will deploy it for amd64-microcode and intel-microcode. -- Henrique Holschuh
Bug#864689: ITP: node-read-only-stream -- wrap a readable/writable stream to be read-only
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-read-only-stream Version : 2.0.0 Upstream Author : James Halliday (http://substack.net) * URL : https://github.com/substack/read-only-stream * License : Expat Programming Lang: JavaScript Description : wrap a nodejs readable/writable stream to be read-only This module allow one to use a readable/writable stream internally but to expose just the readable part of that internal stream. . A stream is an abstract interface for working with streaming data in Node.js. There are many stream objects provided by Node.js. For instance, a request to an HTTP server and process.stdout are both stream instances. Node.js is an event-based server-side JavaScript engine. signature.asc Description: This is a digitally signed message part.
xvi patch to generate UDEB for Debian-Installer
Niltze [Hello]-
If anyone finds it useful, of course, attached please find a patch to
generate a small xvi UDEB -- suitable for embedding in d-i.
from git:
< https://github.com/martinwguy/xvi >
Best Professional Regards
--
Jose R R
http://metztli.it
-
Download Debian-Reiser4 for AMD64 https://sf.net/projects/debian-reiser4/
-
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
-
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!
From b981d84eff3265bca9f37a35ad0d3168b358f744 Mon Sep 17 00:00:00 2001
From: Metztli Information Technology
Date: Mon, 12 Jun 2017 07:42:53 -0700
Subject: [PATCH] Enabled generation of UDEB for Debian-Installer (d-i)
---
debian/changelog | 7 +++
debian/control | 9 +
debian/rules | 4 +++-
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 293380b..105637c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xvi (2.50-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Enabled generation of UDEB for Debian-Installer (d-i)
+
+ -- Metztli Information Technology Mon, 12 Jun 2017 04:39:05 -0700
+
xvi (2.50-1) unstable; urgency=low
* Release 2.50. See RELNOTES-2.50 for a detailed list of changes.
diff --git a/debian/control b/debian/control
index 896c5dc..b0ab835 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,15 @@ Maintainer: Martin Guy
Build-Depends: debhelper (>= 4.0.0), libncurses5-dev
Standards-Version: 3.6.2
+Package: xvi-udeb
+XC-Package-Type: udeb
+Section: debian-installer
+Priority: optional
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: xvi - udeb
+ Do not install it on a normal system.
+
Package: xvi
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
diff --git a/debian/rules b/debian/rules
index 49e7bdb..c86b3d4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,7 +11,6 @@
-
CFLAGS = -g
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -53,6 +52,7 @@ install: build
dh_installdirs
$(MAKE) install DESTDIR=$(CURDIR)/debian/xvi
+ $(MAKE) install DESTDIR=$(CURDIR)/debian/xvi-udeb
# Build architecture-independent files here.
@@ -68,6 +68,8 @@ binary-arch: build install
# dh_install
dh_installmenu
# dh_installman
+# Remove the info-bloat from -udeb
+ -rm -rf debian/xvi-udeb/usr/share
dh_link
dh_strip
dh_compress
--
2.11.0
-all driver packages
Anthony DeRobertis wrote: The only thing I've seen is Recommends: cpu-microcode-all | cpu-microcode and having a cpu-microcode-all package that Depends on both, and having the two real package Provides cpu-microcode. If I remember correctly, Xorg did this at one point for video drivers (maybe still does). It does (xserver-xorg-video-all, xserver-xorg-input-all); there's also va-driver-all, vdpau-driver-all (two video-acceleration interfaces) and printer-driver-all. We are considering introducing opencl-icd-all. However, those involve Depends relationships (where an -all package is needed to allow the option of only installing one) and/or multiple depending/recommending packages and a changing set of providers (making it desirable to be able to make such changes in one central place). Hence, I agree that it wouldn't be worth it for *-microcode. There's also the AppStream modalias mechanism, which can actually pick the right one for the current hardware, but the tools that process it aren't always installed: https://lists.debian.org/debian-devel-announce/2016/11/msg8.html https://lists.debian.org/debian-devel/2017/03/msg00165.html
