Web lists-archives.com

Re: no{thing} build profiles

>>>>> Wouter Verhelst <wouter@xxxxxxxxxx> writes:
>>>>> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
>>>>> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:


 >>> I think the prerequisite for making a change like this would be for
 >>> the library to be able to surface this transitive requirement in
 >>> metadata so that debhelper could support automatically adding it
 >>> to the dependencies of all linked programs (and I’m not sure that
 >>> sort of collapse of our dependency structure is a good idea).

 >> That would be a bad idea – we don’t want gratuitous dependencies
 >> all around.  Just because I use xfce doesn’t mean I want a daemon
 >> for some old kinds of iApple iJunk

 > Why not?  What does it cost you, other than a few bits on your hard
 > disk, to have those things installed?

 > It is an actual cost for users who do not (want to) understand the
 > technical background in why their iSomething doesn’t communicate with
 > Debian properly, and it costs *us* time in support questions if we
 > have to explain to them that they just need to install this one
 > little thing here that takes a few MB (if that; haven’t checked).

	It works both ways, actually.  I’ve recently seen a problem
	with a newly installed system ending up with /two/ configured
	IPv4 addresses (where one was expected.)  The cause of this
	surprise?  Recommends:¹.

	More specifically, the admin there installed isc-dhcp-client and
	configured interfaces(5) accordingly.  He also installed lxqt,
	which Recommends: cmst, which in turn Depends: connman (entirely
	appropriately, I guess, as the former is a GUI for the latter),
	which /also/ configures network interfaces.

      ¹ Not entirely, obviously.  But the claim that ‘more is better,’
	and leads to ‘lack of surprise’ and a ‘more straightforward user
	experience’ isn’t without a flaw when it comes to practice.

 > My laptop, which has a 240G SSD, is mostly full.  That is, however,
 > *not* because of the amount of software that’s installed; 90% of that
 > storage is in my /home.

 > I suspect that the same is true for most users, and therefore that we
 > just shouldn’t care about it.

	The disk usage is indeed a concern, even if likely minor for an
	average user.  Consider, for instance, that you run a dozens of
	VMs and want Mutt installed on every single one.  Unless you use
	LXC on Btrfs with transparent deduplication there, the gnupg and
	its own dependencies may accumulate into a non-trivial disk usage.

	Alternatively, if you perform incremental block-level backups of
	the root filesystem (and I do), every update to the gnupg package
	(within the archive retention time) – as well as each of its
	unique dependencies – will add the respective Installed-Size: to
	the archive size.

	Another issue is that GnuPG, being called from Mutt automatically
	by default, /does/ increase the attack surface.  Of course, you
	can (remember to) turn it off in the configuration, but the more
	/straightforward/ way to avoid that is /not to install/ the package
	in the first place.  In general, the software that you do /not/
	have installed, is most certainly /not/ going to break.

	Then, there’s the issue of surprise.  The software which hooks
	into other software that you use /can/ surprise you.  For example,
	the bash-completion package makes Bash completion function
	unusable to me; so I usually do not install it at all, and where
	it is installed, I make sure to disable it with ‘complete -r’ in
	my personal configuration.

	To summarize, I’d expect for a non-trivial fraction of experienced
	users to actually put effort into minimizing the amount of
	/code/ installed – precisely to /ensure/ straightforward and
	unsurprising behavior.

	As for GnuPG, well, as Mario points out, – it’s useless unless
	configured by the user, /and/ is prone to result in ‘cryptic’
	error messages even if correctly installed.  In turn, to configure
	GnuPG, the user will presumably have to invoke it directly, or
	perhaps from some UI wrapper, at which point he either will notice
	the absence of the command, /or/ the absence of said wrapper –
	for which it /would/ be entirely reasonable to depend on gnupg.

	So the particular point that Mutt is going to misbehave without
	GnuPG installed is moot: the cause for its misbehavior wouldn’t
	be the lack of GnuPG, but rather the lack of user’s knowledge of
	it – or motivation to use.

FSF associate member #7257  http://am-1.org/~ivan/