Refresh the CUPS driver recommends (was: Re: Opt out style recommends)

[Didier 'OdyX' Raboud]

Package: cups
Version: 1.5.2-9

Le vendredi, 8 avril 2016, 10.31:17 Josh Triplett a écrit :
> I'm not going to go through a full analysis here, but here's a *tiny*
> subset of the output on my system, with some annotations:
> 
> (…)
> cups Recommends: printer-driver-gutenprint
> 
> Why does cups recommend some printer drivers and only suggest others?
> For instance, I have printer-driver-hpcups installed instead.

This should indeed be changed. Reporting a bug to keep track.

-- 
Cheers,
OdyX

Re: gitlab package (was Re: Opt out style recommends)

[Michael Lustfield]

On Apr 12, 2016 00:34, "Tollef Fog Heen"  wrote:
>
> ]] Michael Lustfield
>
> > In this particular case, I would suggest first making letsencrypt a
> > Suggests. Then, I would suggest considering snakeoil for the https or
> > just installing with http-only and providing a documented tool for
> > moving to using letsencrypt. You and I both know that we're only
> > talking about a web server configuration... shouldn't the web server
> > be the one suggesting it? ... it doesn't because the web server
> > packages consider SSL/TLS to be its own thing entirely that shouldn't
> > be mixed in with other package deployments.
>
> The web app might well need to know whether it's being accessed over TLS
> or not.  If it is, any cookies it sets should be marked with «secure» so
> they're never sent in plaintext.

An app should know about HTTP vs. HTTPS, yes. However, that's not relevant
to this discussion because an app should be finding that information via a
header the web server sends it. It's one of the standard headers that
nobody pays much attention to. :)

I think party of the problem here is the whole omnibus logic that wants to
configure the whole environment which immediately steps on sys admin toes.

The best thing I can think of is to stick with HTTP out of the box and have
another utility that handles modifying configuration.

You could have all of these prompts (http vs. https; managed certs vs.
letsencrypt) be debconf questions with a post install script that reads
those answers. If nothing was selected, use the default. Otherwise, do
whatever else. This would provide flexibility to rerun and modify later as
well. At least this would be suitable to how gitlab-omnibus likes to
configure itself and it's "modules."

For admins with config management tools, they can pre-answer your debconf
questions and have SSL right away if they so choose. The reconfiguration
can easily be triggered via dpkg reconfigure, which tends to be a first
step for extra config in Debian.

This lets you deploy gitlab out of the box in a manner that is the most
likely to work on all systems and leaves the ability to configure extras to
your heart's content.

Either that or I'm missing something. If I am, please teach me my lesson! :)

Re: Opt out style recommends

[Jakub Wilk]

* Ben Hutchings , 2016-04-11, 02:22:
Would it be useful to have a linker option to omit a NEEDED entry for a 
particular library?  The application could then call 
dlopen("libfoo.so.42", RTLD_NOW|RTLD_GLOBAL) before it starts using the 
library, typically right before calling foo_init(), but it wouldn't 
need to use dlsym().  However this would absolutely depend on lazy 
binding, i.e. the application would break if LD_BIND_NOW was set.


It's kinda possible already: just remove -lfoo from the linker command 
line (and add -Wl,--unresolved-symbols=ignore-all if you're building an 
executable). The downside is that the unresolved symbols will be 
unversioned, and that you have to hardcode soname in the code... which 
means it'll all explode sooner or later.


--
Jakub Wilk

Re: gitlab package (was Re: Opt out style recommends)

[Tollef Fog Heen]

]] Michael Lustfield 

> In this particular case, I would suggest first making letsencrypt a
> Suggests. Then, I would suggest considering snakeoil for the https or
> just installing with http-only and providing a documented tool for
> moving to using letsencrypt. You and I both know that we're only
> talking about a web server configuration... shouldn't the web server
> be the one suggesting it? ... it doesn't because the web server
> packages consider SSL/TLS to be its own thing entirely that shouldn't
> be mixed in with other package deployments.

The web app might well need to know whether it's being accessed over TLS
or not.  If it is, any cookies it sets should be marked with «secure» so
they're never sent in plaintext.

An option that might satisfy everyone is to have a gitlab package and a
gitlab-bells-and-whistles package (or gitlab-minimal and gitlab) where
the latter includes full integration with nginx and letsencrypt and
whatnot, while the former is a more limited package that does the bare
minimum.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: gitlab package (was Re: Opt out style recommends)

[Tollef Fog Heen]

]] Pirate Praveen 

> On 2016, ഏപ്രിൽ 11 3:44:09 PM IST, Tollef Fog Heen  wrote:
> >I'd really like this to be an optional addon, since there's no way you
> >could know how to integrate with how I acquire my certs.  I also
> >question whether it's the job of an application to set up
> >certificates. Does that mean you're configuring various application
> >servers (for vhosting) and TLS terminators too?
> 
> It is optional. I do configure a site for nginx (add virtual host in
> /etc/nginx/sites-available). TLS is enabled when it is selected. I can
> make nginx configuration optional.

I think it should be, nginx is just one of many HTTP servers in the
archive, and just one of many ways to terminate TLS.  (Unless gitlab in
some way depends on nginx specific features.)

> >Minor comment, but hopefully you're asking about TLS and not SSL in any
> >questions you ask the admin.
> 
> Isn't that just semantics? OpenSSL is still not renamed to OpenTLS
> (yes there is gnuTLS). I think SSL term is still widely used referring
> to TLS.

It's true that SSL is still used to refer to both SSL and TLS, but it's
imprecise and we should move away from that usage.  Use TLS if you mean
TLS and SSL/TLS if you mean either.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: gitlab package (was Re: Opt out style recommends)

[Michael Lustfield]

On Mon, Apr 11, 2016 at 3:41 AM, Jonathan Dowland  wrote:
> On Mon, Apr 11, 2016 at 03:18:58PM +0530, Pirate Praveen wrote:
>> 1.Most people in the world including myself thought encryption was an
>> optional thing two years back.
>>
>> 2.automating ssl was not possible before letsencrypt. Now you just need to
>> click/press yes button to get an encrypted service running.
>
> The "normal" way this was done before letsencrypt was with the 'snake oil'
> local SSL CA/cert and self-signing. Obviously not suitable for production use,
> but perfectly fine for an initial install/testing; it is also simpler than
> worrying about talking to LE (especially in a postinst/root/possibly 
> unattended
> context) and a more appropriate initial state for a private/corporate install.
>

I feel like tossing in my two cents as well since this would likely
impact me down the road...

I'm also against a package such as gitlab (or drupal, wordpress,
dokuwiki, etc.) trying to mess around with my TLS certificates. I'm
also very much opposed to it even being a prompt during installation.
I'm well aware that gitlab-ci is a beast (and a kludgy mess... god
save your soul taking on that feller), but an initial installation
should be getting things going and being out of the users face. In
most situations, I would venture a guess that gitlab is sitting on
internal servers and not publicly accessible. That kinda puts a damper
on nice automated ssl with letsencrypt, doesn't it? (k.. not always,
but in the typical situation) However, that old option with
snakeoil... that still works in these environments. I personally use
the letsencrypt infrastructure for some projects, but refuse to use
their incredibly bloated client stuff. I use alternative client tools
that suite my needs much better than the letsencrypt app does.

If anything, shouldn't it be the web server (nginx, tengine, etc.)
that would "suggest" letsencrypt? They won't recommend/suggest that
package because SSL is a separate thing entirely. I would dare say, at
this point, most admins that care about encryption also implement
automation tools such as salt and ansible and already have well tested
systems in place for certificates.

In this particular case, I would suggest first making letsencrypt a
Suggests. Then, I would suggest considering snakeoil for the https or
just installing with http-only and providing a documented tool for
moving to using letsencrypt. You and I both know that we're only
talking about a web server configuration... shouldn't the web server
be the one suggesting it? ... it doesn't because the web server
packages consider SSL/TLS to be its own thing entirely that shouldn't
be mixed in with other package deployments.

tl;dr .. my opinion: letsencrypt should be a suggests; gitlab should
do either https or do a self-signed cert; and letsencrypt integration
should come post-install
Just my opinions/thoughts. :)

Re: gitlab package (was Re: Opt out style recommends)

[Pirate Praveen]

On 2016, ഏപ്രിൽ 11 3:44:09 PM IST, Tollef Fog Heen  wrote:
>Is that why we've been pushing for SSH over telnet for twenty years
>now?

I should clarify, importance of https and end to end encryption was not 
considered widely. There were a minority pushing for encryption. But is is more 
mainstream idea now.

>I'd really like this to be an optional addon, since there's no way you
>could know how to integrate with how I acquire my certs.  I also
>question whether it's the job of an application to set up
>certificates. Does that mean you're configuring various application
>servers (for vhosting) and TLS terminators too?

It is optional. I do configure a site for nginx (add virtual host in 
/etc/nginx/sites-available). TLS is enabled when it is selected. I can make 
nginx configuration optional.

>> And for those who do not want it, the default is 'no' for both ssl
>and
>> letsencrypt.
>
>Minor comment, but hopefully you're asking about TLS and not SSL in any
>questions you ask the admin.

Isn't that just semantics? OpenSSL is still not renamed to OpenTLS (yes there 
is gnuTLS). I think SSL term is still widely used referring to TLS.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: gitlab package (was Re: Opt out style recommends)

[Jonathan Dowland]

On Mon, Apr 11, 2016 at 03:18:58PM +0530, Pirate Praveen wrote:
> 1.Most people in the world including myself thought encryption was an
> optional thing two years back. 
> 
> 2.automating ssl was not possible before letsencrypt. Now you just need to
> click/press yes button to get an encrypted service running.

The "normal" way this was done before letsencrypt was with the 'snake oil'
local SSL CA/cert and self-signing. Obviously not suitable for production use,
but perfectly fine for an initial install/testing; it is also simpler than
worrying about talking to LE (especially in a postinst/root/possibly unattended
context) and a more appropriate initial state for a private/corporate install.

Re: gitlab package (was Re: Opt out style recommends)

[Pirate Praveen]

On 2016, ഏപ്രിൽ 11 3:35:56 PM IST, Vincent Bernat  wrote:
>In this case, this could be done centrally, for example in the
>letsencrypt package.

With debhelper integration like we do for init scripts or systemd. If 
debian/.letsencrypt is present, it should take care of the 
remaining.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: gitlab package (was Re: Opt out style recommends)

[Debian/GNU]

On 2016-04-11 11:48, Pirate Praveen wrote:
> It would be a good time to add letsencrypt support to php-horde and every 
> other service dealing with sensitive data like passwords.

no, seriously not.
i am all for having all web traffic encrypted. that's why the web-server
package *may* push for encryption (by suggesting letsencrypt or whatever).
however, it is none of the web-application's business.
and gitlab is just that: a web-application.


fgmsdr
IOhannes

Re: gitlab package (was Re: Opt out style recommends)

[Tollef Fog Heen]

]] Pirate Praveen 

> 1.Most people in the world including myself thought encryption was an
> optional thing two years back.

Is that why we've been pushing for SSH over telnet for twenty years now?

> 2.automating ssl was not possible before letsencrypt. Now you just
> need to click/press yes button to get an encrypted service running.

I'd really like this to be an optional addon, since there's no way you
could know how to integrate with how I acquire my certs.  I also
question whether it's the job of an application to set up
certificates. Does that mean you're configuring various application
servers (for vhosting) and TLS terminators too?

> And for those who do not want it, the default is 'no' for both ssl and
> letsencrypt.

Minor comment, but hopefully you're asking about TLS and not SSL in any
questions you ask the admin.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: gitlab package (was Re: Opt out style recommends)

[Vincent Bernat]

 ❦ 11 avril 2016 15:18 +0530, Pirate Praveen  :

> 2.automating ssl was not possible before letsencrypt. Now you just
> need to click/press yes button to get an encrypted service running.
>
> And for those who do not want it, the default is 'no' for both ssl and 
> letsencrypt.
>  
> It would be a good time to add letsencrypt support to php-horde and
> every other service dealing with sensitive data like passwords.

In this case, this could be done centrally, for example in the
letsencrypt package.
-- 
"... an experienced, industrious, ambitious, and often quite often
picturesque liar."
-- Mark Twain


signature.asc
Description: PGP signature

Re: gitlab package (was Re: Opt out style recommends)

[Pirate Praveen]

On 2016, ഏപ്രിൽ 11 1:35:39 PM IST, "IOhannes m zmölnig (Debian/GNU)" 
 wrote:
>Isn't it how every other service doing it?
>
>yes sure.
>
>but if i install other web-services (e.g. php-horde) they don't bother
>me with setting up an enrypted webservice.
>the only reasonable package that should suggest ways of encrypting
>seems
>to be the webserver (apache2, nginx,...)
>

I think php-horde was packaged before Snowden revelations and letsencrypt. 

1.Most people in the world including myself thought encryption was an optional 
thing two years back. 

2.automating ssl was not possible before letsencrypt. Now you just need to 
click/press yes button to get an encrypted service running.

And for those who do not want it, the default is 'no' for both ssl and 
letsencrypt.
 
It would be a good time to add letsencrypt support to php-horde and every other 
service dealing with sensitive data like passwords.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: gitlab package (was Re: Opt out style recommends)

[Debian/GNU]

On 2016-04-10 03:55, Pirate Praveen wrote:
>>
>> while i really appreciate all the work you are doing for the gitlab
>> package, i honestly have the feeling that you are trying to make too
>> many decisions on behalf of the system administrator who wants to
>> install gitlab.
> 
> I just want the service up and running after you install gitlab. Isn't it how 
> every other service doing it?

yes sure.

but if i install other web-services (e.g. php-horde) they don't bother
me with setting up an enrypted webservice.
the only reasonable package that should suggest ways of encrypting seems
to be the webserver (apache2, nginx,...)

> 
>> i really don't see any compelling reason why a package like gitlab
>> should force me to use any special means to encrypt my connection.
> 
> It does not. Even earlier with letsencrypt in depends, it asks in post 
> install if letsencrypt should be used. Now it is in recommends and you can 
> just skip letsencrypt.

cool. thank you.

>> there are a number of reasons to use the Debian gitlab packages over
>> the
>> ones provided by upstream (e.g. omnibus), and one of them is being able
>> to chose the components i would like to have on my system (or not).
> 
> It is just the first attempt and making all components optional is in my 
> todo. Patches to speed it up is welcome.
> 
> nginx is already made optional in last update. Next is database.

i see.
since you were basically starting from this huge monolithic
installation, it makes sense to first get the package running and then
factor out as much as possible.

> 
> Its already 8.5.8. Three new gems are required for 8.6 and we are already 
> working on it.
> 

fantastic.

famtsd
IOhannes

Re: Opt out style recommends

[Paul Wise]

On Mon, Apr 11, 2016 at 9:22 AM, Ben Hutchings wrote:

> Binding *is* lazy by default, but loading of NEEDED libraries is eager
> since ELF dynamic symbol references don't say which library they're
> expected to be resolved in (perhaps the best *and* worst feature of ELF
> dynamic linking).  If we made the absence of a NEEDED library non-
> fatal, that would put off failure until the application used a symbol
> from the missing library, but at that point I don't think there's any
> good way for the application to handle failure gracefully.

Apparently Solaris has support for optional shared libraries. It seems
like something that would be useful to have on Linux/glibc.

https://lists.debian.org/debian-devel/2015/02/msg00261.html
https://sourceware.org/ml/libc-help/2013-02/msg00017.html
http://comments.gmane.org/gmane.comp.handhelds.tizen.devel/4892

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Opt out style recommends

[Ben Hutchings]

On Sun, 2016-04-10 at 13:35 -0700, Russ Allbery wrote:
[...]
> The major place where this breaks down is with shared
> libraries, since, due to how dynamic linking works, even shared libraries
> only used in specific dconfigurations have to be listed in Depends.  But,
> because the shared library may be unused other than by mapping it during
> process startup, all of its dependencies (of any strength) that don't
> interfere with startup mapping should be deprioritized.
> 
> In other words, the root of the problem is that we're forced to take
> artificially strong dependencies that aren't warranted by the
> functionality of the library due to the implementation of dynamic linking
> and the fact we want startup binding instead of lazy binding on first call
> (for some justifiably good reasons).

Binding *is* lazy by default, but loading of NEEDED libraries is eager
since ELF dynamic symbol references don't say which library they're
expected to be resolved in (perhaps the best *and* worst feature of ELF
dynamic linking).  If we made the absence of a NEEDED library non-
fatal, that would put off failure until the application used a symbol
from the missing library, but at that point I don't think there's any
good way for the application to handle failure gracefully.

Would it be useful to have a linker option to omit a NEEDED entry for a
particular library?  The application could then call
dlopen("libfoo.so.42", RTLD_NOW|RTLD_GLOBAL) before it starts using the
library, typically right before calling foo_init(), but it wouldn't
need to use dlsym().  However this would absolutely depend on lazy
binding, i.e. the application would break if LD_BIND_NOW was set.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

signature.asc
Description: This is a digitally signed message part

Re: Opt out style recommends

[Russ Allbery]

Tollef Fog Heen  writes:
> ]] Russ Allbery 

>> I think a more correct fix would (unfortunately) involve a new binary
>> package field that we don't currently have: Depends-Shallow (for lack
>> of a better term) that acts like Depends *except* disables Recommends
>> processing for anything below the shallow dependencies in the tree.  So
>> if everything you're installing only Depends-Shallow on
>> libimobiledevice4, you don't get the recommendation; if anything
>> straight depends on it, you do.

> I think I want something like Recommends that get less and less weight
> the further they get from something you explicitly requested. Direct
> recommends: 1 point, One step indirect, 0.8 point, two steps 0.8^2
> points, etc.  One point or more -> install.  You can then also do things
> like adding together scores, so if A, B and C all suggests D, you might
> get that, even if none of them would pull it in by themselves.

> (Weights are obviously pulled out of thin air, experimentation would be
> needed to find sensible values.)

Distance is being used as a proxy for "likely to interfere with the
usability of the program."  It's not a bad proxy, but it would be ideal if
we could directly annotate this, since often the maintainers involved know
exactly what weight should be placed.  There are some long dependency
chains that actually need a strong dependency the whole way.

And largely maintainers can do that annotation, using Depends, Recommends,
and Suggests.  The major place where this breaks down is with shared
libraries, since, due to how dynamic linking works, even shared libraries
only used in specific configurations have to be listed in Depends.  But,
because the shared library may be unused other than by mapping it during
process startup, all of its dependencies (of any strength) that don't
interfere with startup mapping should be deprioritized.

In other words, the root of the problem is that we're forced to take
artificially strong dependencies that aren't warranted by the
functionality of the library due to the implementation of dynamic linking
and the fact we want startup binding instead of lazy binding on first call
(for some justifiably good reasons).

-- 
Russ Allbery (r...@debian.org)   

Re: Opt out style recommends

[Tollef Fog Heen]

]] Russ Allbery 

> I think a more correct fix would (unfortunately) involve a new binary
> package field that we don't currently have: Depends-Shallow (for lack of a
> better term) that acts like Depends *except* disables Recommends
> processing for anything below the shallow dependencies in the tree.  So if
> everything you're installing only Depends-Shallow on libimobiledevice4,
> you don't get the recommendation; if anything straight depends on it, you
> do.

I think I want something like Recommends that get less and less weight
the further they get from something you explicitly requested. Direct
recommends: 1 point, One step indirect, 0.8 point, two steps 0.8^2
points, etc.  One point or more -> install.  You can then also do things
like adding together scores, so if A, B and C all suggests D, you might
get that, even if none of them would pull it in by themselves.

(Weights are obviously pulled out of thin air, experimentation would be
needed to find sensible values.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: gitlab package (was Re: Opt out style recommends)

[Pirate Praveen]

On 2016, ഏപ്രിൽ 10 12:28:29 AM IST, "IOhannes m zmölnig (Debian/GNU)" 
 wrote:
>hi,
>
>On 04/08/2016 05:33 AM, Pirate Praveen wrote:
>> See #819854 for a background.
>> 
>> Currently gitlab recommends letsencrypt, it means someone has to opt
>in for letsencrypt by running something like
>> 
>> apt-get install gitlab letsencrypt
>> 
>> But I would like letsencrypt to be available by default (postinst
>asks if they want t
>
>while i really appreciate all the work you are doing for the gitlab
>package, i honestly have the feeling that you are trying to make too
>many decisions on behalf of the system administrator who wants to
>install gitlab.

I just want the service up and running after you install gitlab. Isn't it how 
every other service doing it?

>i really don't see any compelling reason why a package like gitlab
>should force me to use any special means to encrypt my connection.

It does not. Even earlier with letsencrypt in depends, it asks in post install 
if letsencrypt should be used. Now it is in recommends and you can just skip 
letsencrypt.

>there are a number of reasons to use the Debian gitlab packages over
>the
>ones provided by upstream (e.g. omnibus), and one of them is being able
>to chose the components i would like to have on my system (or not).

It is just the first attempt and making all components optional is in my todo. 
Patches to speed it up is welcome.

nginx is already made optional in last update. Next is database.

>but the way the package is heading seems to take away choices rather
>than give me additional ones: e.g. using upstream's gitlab-ce omnibus
>packages i am *free* to choose whatever method i like to setup an
>encrypted webserver (allowing me to e.g. setup a gitlab instance that
>is
>not accessible from the public internet - something that is impossible
>with letsencrypt afaict).

Already covered. You can choose not to use letsencrypt.

>i would love if the gitlab package in Debian was as *minimal* as
>possible giving *me* (the admin) the freedom to choose the largest
>possible set of components - probably (and likely) at the expense that
>I
>(the admin) will need to setup quite a lot of things myself.

Already answered.

>i guess there are *many* things to setup and this might make it
>impossible for newbee administrators to setup their own gitlab
>instance.
>but i think that there are ways to accomodate both the seasoned admin
>(probably in a corporate environment dictating whatever policies) and
>the any random developer (who want an instance for their personal use
>without worrying too much about administration).

Making all components optional will do it.
And the configuration files are there to do more tweaking.

>e.g. instead of making the 'gitlab' package work magic and conjure the
>perfect configuration for any usecase, you could instead:
>
>- add *good* documentation; with configuration examples, step-by-step
>instructions to setup whatever additional service,...
>- provide an *additional* package ("gitlab-to-go", but please cose a
>better name :-)) which depends on 'gitlab' (and other packages like
>'letsencrypt') and which does the magic to provide the "it just works"
>experience for selected use-cases.
>
>i really hope that this will simplify your work as a maintainer of such
>a complex package. (or put otherwise: i think that the quest to come up
>with a satisfying configuration for all potential users is NP-complete
>and will indefinitely stall further packaging or make the package
>unusable for some users or both)
>
>a nice side effect might be that it would allow Debian gitlab packages
>follow upstream more closely (e.g. Debian currently has
>gitlab-8.4.3+dfst-12 whereas upstream currently has 8.6.4 (and the 8.4
>series is at bugfix release 8.4.7; the numbers might be a bit
>misleading
>though, as Debian might not be affected by a few bugs that triggered
>there own bugfix release).

Its already 8.5.8. Three new gems are required for 8.6 and we are already 
working on it.

>
>anyhow, thanks again for doing all the work to bring us gitlab.
>
>fgmards
>IOhannes

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Opt out style recommends

[Henrique de Moraes Holschuh]

On Fri, 08 Apr 2016, Russ Allbery wrote:
> So, where this goes wrong is the upower -> libimobiledevice4 dependency.
> As you say, the dependency is correct (or at least correct-ish): we don't
> want to dlopen everything and try to push all those patches upstream.  But
> this is the weakest link of this whole chain, yet has the strongest
> dependency.
> 
> I think a more correct fix would (unfortunately) involve a new binary
> package field that we don't currently have: Depends-Shallow (for lack of a
> better term) that acts like Depends *except* disables Recommends
> processing for anything below the shallow dependencies in the tree.  So if
> everything you're installing only Depends-Shallow on libimobiledevice4,
> you don't get the recommendation; if anything straight depends on it, you
> do.

Make it "downgrades recommends to suggests" and it might even work well.

But since there exists recommends one is much better off never downgrading,
we might end up needing a recommends-strong field as well that would never
be downgraded, to avoid the need to upgrade such recommends to depends.

At least it would end there with two extra headers (or some other way to
annotate recommends dependency headers in these two ways), so it is still
something that looks like it could work.

But how much of a trouble would such changes cause for the dependency
solvers?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

gitlab package (was Re: Opt out style recommends)

[Debian/GNU]

hi,

On 04/08/2016 05:33 AM, Pirate Praveen wrote:
> See #819854 for a background.
> 
> Currently gitlab recommends letsencrypt, it means someone has to opt in for 
> letsencrypt by running something like
> 
> apt-get install gitlab letsencrypt
> 
> But I would like letsencrypt to be available by default (postinst asks if 
> they want t

while i really appreciate all the work you are doing for the gitlab
package, i honestly have the feeling that you are trying to make too
many decisions on behalf of the system administrator who wants to
install gitlab.

i really don't see any compelling reason why a package like gitlab
should force me to use any special means to encrypt my connection.
there are a number of reasons to use the Debian gitlab packages over the
ones provided by upstream (e.g. omnibus), and one of them is being able
to chose the components i would like to have on my system (or not).

but the way the package is heading seems to take away choices rather
than give me additional ones: e.g. using upstream's gitlab-ce omnibus
packages i am *free* to choose whatever method i like to setup an
encrypted webserver (allowing me to e.g. setup a gitlab instance that is
not accessible from the public internet - something that is impossible
with letsencrypt afaict).

i would love if the gitlab package in Debian was as *minimal* as
possible giving *me* (the admin) the freedom to choose the largest
possible set of components - probably (and likely) at the expense that I
(the admin) will need to setup quite a lot of things myself.

i guess there are *many* things to setup and this might make it
impossible for newbee administrators to setup their own gitlab instance.
but i think that there are ways to accomodate both the seasoned admin
(probably in a corporate environment dictating whatever policies) and
the any random developer (who want an instance for their personal use
without worrying too much about administration).

e.g. instead of making the 'gitlab' package work magic and conjure the
perfect configuration for any usecase, you could instead:

- add *good* documentation; with configuration examples, step-by-step
instructions to setup whatever additional service,...
- provide an *additional* package ("gitlab-to-go", but please cose a
better name :-)) which depends on 'gitlab' (and other packages like
'letsencrypt') and which does the magic to provide the "it just works"
experience for selected use-cases.

i really hope that this will simplify your work as a maintainer of such
a complex package. (or put otherwise: i think that the quest to come up
with a satisfying configuration for all potential users is NP-complete
and will indefinitely stall further packaging or make the package
unusable for some users or both)

a nice side effect might be that it would allow Debian gitlab packages
follow upstream more closely (e.g. Debian currently has
gitlab-8.4.3+dfst-12 whereas upstream currently has 8.6.4 (and the 8.4
series is at bugfix release 8.4.7; the numbers might be a bit misleading
though, as Debian might not be affected by a few bugs that triggered
there own bugfix release).


anyhow, thanks again for doing all the work to bring us gitlab.

fgmards
IOhannes




signature.asc
Description: OpenPGP digital signature

Re: Opt out style recommends

[Adam Borowski]

On Sat, Apr 09, 2016 at 08:34:24AM +, Sune Vuorela wrote:
> On 2016-04-09, Jonas Smedegaard  wrote:
> > I disagree that we need a new field: Simply lower to at most suggest the =
> > daemon: It is for the daemon to declare a stronger dependency.
> > Anyone needing the daemon can install the daemon - you shouldn't expect =
> > libraries to pull in daemons (just as you shouldn't expect documentation =
> > to pull in binaries).
> 
> Sometimes, the daemon is an implementation detail of the library. Or a
> hard requirement for the library to function. Sometimes it is even a
> hard requirement for the library to not crash.

Right, it may be a hard requirement for the library.  It may be not a
requirement for an user of the library, if that library is pulled only
for an obscure feature.  The problem is, dependencies are transitive.

And in most languages it's tedious to make a library optional at runtime.

So some solution would be nice, be it Russ' new field or my moving such
dependencies away from libraries.

-- 
A tit a day keeps the vet away.

Re: Opt out style recommends

[Jonas Smedegaard]

Quoting Sune Vuorela (2016-04-09 10:34:24)
> On 2016-04-09, Jonas Smedegaard  wrote:
>> I disagree that we need a new field: Simply lower to at most suggest 
>> the = daemon: It is for the daemon to declare a stronger dependency. 
>> Anyone needing the daemon can install the daemon - you shouldn't 
>> expect = libraries to pull in daemons (just as you shouldn't expect 
>> documentation = to pull in binaries).
>
> Sometimes, the daemon is an implementation detail of the library. Or a
> hard requirement for the library to function. Sometimes it is even a
> hard requirement for the library to not crash.

Such (rare, I suspect) cases would require Depends, not Recommends as is 
discussed in this here, I believe.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Opt out style recommends

[Sune Vuorela]

On 2016-04-09, Jonas Smedegaard  wrote:
> I disagree that we need a new field: Simply lower to at most suggest the =
> daemon: It is for the daemon to declare a stronger dependency.
> Anyone needing the daemon can install the daemon - you shouldn't expect =
> libraries to pull in daemons (just as you shouldn't expect documentation =
> to pull in binaries).

Sometimes, the daemon is an implementation detail of the library. Or a
hard requirement for the library to function. Sometimes it is even a
hard requirement for the library to not crash.

/Sune

Re: Opt out style recommends

[Jonas Smedegaard]

Quoting Russ Allbery (2016-04-09 03:20:25)
> Adam Borowski  writes:
>> Like:
>> xfce4-power-manager -> upower -> libimobiledevice4 -> usbmuxd
>
>> Is the recommendation from libimobiledevice4 to usbmuxd valid?  Sure 
>> it is -- the library is useless without the daemon.
[...]
> So, where this goes wrong is the upower -> libimobiledevice4 
> dependency. As you say, the dependency is correct (or at least 
> correct-ish): we don't want to dlopen everything and try to push all 
> those patches upstream.  But this is the weakest link of this whole 
> chain, yet has the strongest dependency.
>
> I think a more correct fix would (unfortunately) involve a new binary 
> package field that we don't currently have: Depends-Shallow (for lack 
> of a better term) that acts like Depends *except* disables Recommends 
> processing for anything below the shallow dependencies in the tree.  
> So if everything you're installing only Depends-Shallow on 
> libimobiledevice4, you don't get the recommendation; if anything 
> straight depends on it, you do.

I disagree that we need a new field: Simply lower to at most suggest the 
daemon: It is for the daemon to declare a stronger dependency.

Anyone needing the daemon can install the daemon - you shouldn't expect 
libraries to pull in daemons (just as you shouldn't expect documentation 
to pull in binaries).


>> And, many maintainers could take this as an attack: "what, my package 
>> is useless?!?".  Like, openssh-server -> libwrap0 -> tcpd.  I'd say 
>> pretty much anyone today uses other means for limiting access to ssh; 
>> tcpd does have near-universal popcon (95.79%!) but protocols listed 
>> in its description (telnet ftp rsh rlogin finger) and complete dearth 
>> of new bug reports (it received tons in the past) make me think it's 
>> not actually used anymore.
> 
> I still use tcpd for openssh-server.  (This is not an argument for 
> keeping the chain, just a data point.)  tcpd, unlike iptables, can 
> whitelist domains.  It's weak security, but it's good for defense in 
> depth and making the constant brute force attacks die down a bit.

I agree it is no argument for keeping the chain: Those using tcpd can 
install that - or install a metapackage that depends on or recommends 
it.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Opt out style recommends

[Ole Streicher]

Håkon Alstadheim  writes:
> Den 08. april 2016 19:31, skrev Josh Triplett:
>> emacs24-common Recommends: emacs24-el
>>
>> I don't think all but the most unusual configurations need the elisp
>> source of the functionality already provided by the main emacs24
>> package.  Emacs/elisp developers will want this.
>>
>>
> There is often two sides to such arguments:
> - An editor needs a scripting and configuration language. emacs has
> elisp. If you want to be able to see what knobs are available for
> adjusting, you look at the source. When your scripts have errors, you
> want to be able to view source to find out what you did wrong.

As you describe it, the source file have a similar function as the debug
files for a library, which are (for a good reason) also not set as
Recommends.

Emacs (and many of its lisp libraries) are quite stable today; so in the
rare case of an error, you could just add the source later and re-run
the problem.

> - If you will never be scripting emacs, you are better off with pico or
> nano as an editor.

I use emacs since >20 years, and love it. However, I *very* rarely do
emacs scripting, and almost never outside of some configuration. Sorry,
I don't see this as an argument.

To do scripting, you also usually don't need the sources.

For me, the lisp source are really unused, and I think that I am not a
rare, exceptional case.

Best regards

Ole

Re: Opt out style recommends

[Håkon Alstadheim]

Den 08. april 2016 19:31, skrev Josh Triplett:

 

> emacs24-common Recommends: emacs24-el
>
> I don't think all but the most unusual configurations need the elisp
> source of the functionality already provided by the main emacs24
> package.  Emacs/elisp developers will want this.
>
>
There is often two sides to such arguments:
- An editor needs a scripting and configuration language. emacs has
elisp. If you want to be able to see what knobs are available for
adjusting, you look at the source. When your scripts have errors, you
want to be able to view source to find out what you did wrong.
- If you will never be scripting emacs, you are better off with pico or
nano as an editor.

In other words: not all of the things you mention are quick no-brainers
to get changed :-/

Re: Opt out style recommends

[Russ Allbery]

Josh Triplett  writes:
> Wookey wrote:
>> +++ Josh Triplett [2016-04-08 10:31 -0700]:

>>>  For instance,
>>> "If  is a build tool, command-line tool, or library, 
>>> already provides documentation in man, info, or text format, and
>>> -doc provides HTML or other formats,  should have a
>>> 'Suggests: -doc'.  Otherwise,  should have a
>>> 'Recommends: -doc'."

>> That seems a sensible default position.

> Would you be willing to make this Policy proposal on my behalf?  IANADD.

You don't have to be a Debian Developer to make a Policy proposal, just to
second.

-- 
Russ Allbery (r...@debian.org)   

Re: Opt out style recommends

[Russ Allbery]

Adam Borowski  writes:

> Like:
> xfce4-power-manager -> upower -> libimobiledevice4 -> usbmuxd

> Is the recommendation from libimobiledevice4 to usbmuxd valid?  Sure it is
> -- the library is useless without the daemon.

> Is the dependency from upower to libimobiledevice4 valid?  It is -- using
> dlopen for every optional feature would require massive amounts of work.

> Is the dependency from xfce4-power-manager to upower valid?  Certainly --
> x-p-m is merely a GUI that needs upower for everything.

> But, wanting to suspend my computer doesn't mean I own an iPod or want a
> daemon that's useless for non-iPod-users!

So, where this goes wrong is the upower -> libimobiledevice4 dependency.
As you say, the dependency is correct (or at least correct-ish): we don't
want to dlopen everything and try to push all those patches upstream.  But
this is the weakest link of this whole chain, yet has the strongest
dependency.

I think a more correct fix would (unfortunately) involve a new binary
package field that we don't currently have: Depends-Shallow (for lack of a
better term) that acts like Depends *except* disables Recommends
processing for anything below the shallow dependencies in the tree.  So if
everything you're installing only Depends-Shallow on libimobiledevice4,
you don't get the recommendation; if anything straight depends on it, you
do.

> And, many maintainers could take this as an attack: "what, my package is
> useless?!?".  Like, openssh-server -> libwrap0 -> tcpd.  I'd say pretty
> much anyone today uses other means for limiting access to ssh; tcpd does
> have near-universal popcon (95.79%!) but protocols listed in its
> description (telnet ftp rsh rlogin finger) and complete dearth of new
> bug reports (it received tons in the past) make me think it's not
> actually used anymore.

I still use tcpd for openssh-server.  (This is not an argument for keeping
the chain, just a data point.)  tcpd, unlike iptables, can whitelist
domains.  It's weak security, but it's good for defense in depth and
making the constant brute force attacks die down a bit.

-- 
Russ Allbery (r...@debian.org)   

Re: Opt out style recommends

[Josh Triplett]

Wookey wrote:
> +++ Josh Triplett [2016-04-08 10:31 -0700]:
> > I wonder if debian-policy section 12 should talk about the desired
> > package relationship between  and -doc? 
> 
> The world has changed since the policy was originally written. I do
> like to have -doc package for most things installed and find it
> very annoying that often the 'help' in an app just takes you to a
> web-page somewhere, which is particulaly galling when you have no net
> connection, or only an expensive one.

If the app has a help option or built-in help, then the help should
absolutely be a Recommends.

> But I agree that this is now the exception rather than the norm and a
> lot of the time recommends for a second copy of the docs is too strong.
> 
> >  For instance,
> > "If  is a build tool, command-line tool, or library, 
> > already provides documentation in man, info, or text format, and
> > -doc provides HTML or other formats,  should have a
> > 'Suggests: -doc'.  Otherwise,  should have a
> > 'Recommends: -doc'."
> 
> That seems a sensible default position.

Would you be willing to make this Policy proposal on my behalf?  IANADD.

- Josh Triplett

Re: Opt out style recommends

[Wookey]

+++ Josh Triplett [2016-04-08 10:31 -0700]:
> I wonder if debian-policy section 12 should talk about the desired
> package relationship between  and -doc? 

The world has changed since the policy was originally written. I do
like to have -doc package for most things installed and find it
very annoying that often the 'help' in an app just takes you to a
web-page somewhere, which is particulaly galling when you have no net
connection, or only an expensive one.

But I agree that this is now the exception rather than the norm and a
lot of the time recommends for a second copy of the docs is too strong.

>  For instance,
> "If  is a build tool, command-line tool, or library, 
> already provides documentation in man, info, or text format, and
> -doc provides HTML or other formats,  should have a
> 'Suggests: -doc'.  Otherwise,  should have a
> 'Recommends: -doc'."

That seems a sensible default position.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Opt out style recommends

[Adam Borowski]

On Fri, Apr 08, 2016 at 09:51:18PM +0200, Jonas Smedegaard wrote:
> Quoting Adam Borowski (2016-04-08 21:05:23)
> > On Thu, Apr 07, 2016 at 11:49:38PM -0400, Harlan Lieberman-Berg wrote:
> >> [1]: I say default here, but really, systems which turn off 
> >> installing things which are Recommended are almost unusuable; I know 
> >> for a while it was the policy of #debian to just turn away people who 
> >> had done that because the system would be in such a strange state.
> >
> > To the contrary, I'd say Recommends chains have ran amok to the point 
> > installing Recommends without thinking leads to insanity.
> >
> > When you install package X, its Recommends are indeed usually helpful.  
> > The Recommends of a random library package X pulls almost never are.
> 
> Please file bugs against libraries with too aggressive recommendations - 
> that's the way forward (not avoiding recommendations altogether).

The problem here is that for the library itself the recommendation does make
sense.  It's only when some user of the library gets pulled by a completely
unrelated package when the recommendation becomes bad.  The dependency chain
involved can be very long -- are recommends supposed to change because
something on the other end of Debian changed?

Like:
xfce4-power-manager -> upower -> libimobiledevice4 -> usbmuxd

Is the recommendation from libimobiledevice4 to usbmuxd valid?  Sure it is
-- the library is useless without the daemon.

Is the dependency from upower to libimobiledevice4 valid?  It is -- using
dlopen for every optional feature would require massive amounts of work.

Is the dependency from xfce4-power-manager to upower valid?  Certainly --
x-p-m is merely a GUI that needs upower for everything.

But, wanting to suspend my computer doesn't mean I own an iPod or want a
daemon that's useless for non-iPod-users!

Unfortunately, because of metapackages fixing this is not as easy as "obey
only direct recommendations".  On the other hand, having a recommendation
suddenly become bad because of an unrelated change to an unrelated package
far away doesn't sound reasonable to me.


Is there an agreed-upon policy?  Because I wouldn't want to start filing
hundreds or thousands of bug reports without a consensus.

And, many maintainers could take this as an attack: "what, my package is
useless?!?".  Like, openssh-server -> libwrap0 -> tcpd.  I'd say pretty much
anyone today uses other means for limiting access to ssh; tcpd does have
near-universal popcon (95.79%!) but protocols listed in its description
(telnet ftp rsh rlogin finger) and complete dearth of new bug reports (it
received tons in the past) make me think it's not actually used anymore. 
But, to get the Recommends removed I'd need to wage such a war against every
maintainer of such a library package!

So, what about this rule:
"a library should not recommend/depend on non-libraries, the dependency
should come from actual programs or metapackages".
Thus, it'd be up to openssh-server to consider how strongly it suggests
tcpd, up to scanner software or maybe gnome-meta to pull in colord, up to
dose-extra not librpm3 to consider rpm, etc.  Maintainers of libraries
tend to have grossly inflated view of importance of their software, so
I believe users of those libraries can provide more accurate
recommendations.


Meow!
-- 
A tit a day keeps the vet away.

Re: Opt out style recommends

[Jonas Smedegaard]

Quoting Adam Borowski (2016-04-08 21:05:23)
> On Thu, Apr 07, 2016 at 11:49:38PM -0400, Harlan Lieberman-Berg wrote:
>> [1]: I say default here, but really, systems which turn off 
>> installing things which are Recommended are almost unusuable; I know 
>> for a while it was the policy of #debian to just turn away people who 
>> had done that because the system would be in such a strange state.
>
> To the contrary, I'd say Recommends chains have ran amok to the point 
> installing Recommends without thinking leads to insanity.
>
> When you install package X, its Recommends are indeed usually helpful.  
> The Recommends of a random library package X pulls almost never are.

Please file bugs against libraries with too aggressive recommendations - 
that's the way forward (not avoiding recommendations altogether).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Opt out style recommends

[Manuel A. Fernandez Montecelo]

2016-04-08 18:31 Josh Triplett:


Agreed.  I turned off Recommends years ago on all my systems, because it
installs too many things I don't want (by both the mild "takes up
space" criteria and in many cases the "don't want an extra daemon
running" criteria).

Here's a Python script (using python-apt, which you'll need installed)
that will find and print all unsatisfied Recommends on your system:

#!/usr/bin/python
import apt
c = apt.Cache()
for pkg in c:
   if pkg.installed is not None:
   for rd in pkg.candidate.get_dependencies("Recommends"):
   if not rd.installed_target_versions:
   print pkg, rd


There's also:

 aptitude (ncurses) -> Views -> Audit recommendations

 (with explanations/rdeps in the panel at the bottom)


or its equivalent in the command line (without the explanation):

 aptitude search '!~v!~i~RBrecommends:~i'


Cheers.
--
Manuel A. Fernandez Montecelo 

Re: Opt out style recommends

[Adam Borowski]

On Thu, Apr 07, 2016 at 11:49:38PM -0400, Harlan Lieberman-Berg wrote:
> [1]: I say default here, but really, systems which turn off installing
> things which are Recommended are almost unusuable; I know for a while it
> was the policy of #debian to just turn away people who had done that
> because the system would be in such a strange state.

To the contrary, I'd say Recommends chains have ran amok to the point
installing Recommends without thinking leads to insanity.

When you install package X, its Recommends are indeed usually helpful.  The
Recommends of a random library package X pulls almost never are.

I somehow still haven't set APT::Get::Install-Recommends "false", but most
of the time at the apt install prompt I go "WTF?", re-run apt with
--no-install-recommends, read the list and only then maybe install them.

-- 
A tit a day keeps the vet away.

Re: Opt out style recommends

[Josh Triplett]

Adrien CLERC wrote:
> Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit :
> > [1]: I say default here, but really, systems which turn off installing
> > things which are Recommended are almost unusuable; I know for a while
> > it was the policy of #debian to just turn away people who had done
> > that because the system would be in such a strange state.
> While I think installing recommended packages by default is a good
> choice, disabling it is also a really good option on servers. Installing
> every recommended packages is sometimes the best way to bloat your system.

Agreed.  I turned off Recommends years ago on all my systems, because it
installs too many things I don't want (by both the mild "takes up
space" criteria and in many cases the "don't want an extra daemon
running" criteria).

Here's a Python script (using python-apt, which you'll need installed)
that will find and print all unsatisfied Recommends on your system:

#!/usr/bin/python
import apt
c = apt.Cache()
for pkg in c:
if pkg.installed is not None:
for rd in pkg.candidate.get_dependencies("Recommends"):
if not rd.installed_target_versions:
print pkg, rd

I'm not going to go through a full analysis here, but here's a *tiny*
subset of the output on my system, with some annotations:

aptitude Recommends: aptitude-doc-en | aptitude-doc

Why would all but the most unusual configurations need an HTML version
of the manual installed?  aptitude already ships a text version in
/usr/share/doc/aptitude/README, and includes a menu option inside
aptitude to display that.  The HTML version is also available online.
So only people who 1) want the HTML manual and 2) want it available
offline need one of these packages installed.

https://bugs.debian.org/820452

autogen Recommends: autogen-doc

I only have autogen installed as a build-dependency of grub.  Also,
autogen already includes its documentation in info format; autogen-doc
just provides precompiled PostScript and HTML.

I wonder if debian-policy section 12 should talk about the desired
package relationship between  and -doc?  For instance,
"If  is a build tool, command-line tool, or library, 
already provides documentation in man, info, or text format, and
-doc provides HTML or other formats,  should have a
'Suggests: -doc'.  Otherwise,  should have a
'Recommends: -doc'."

brasero Recommends: brasero-cdrkit

This one makes a bit of sense, since GUI tools should try to have all
their functionality work automatically.  (Odd that brasero-cdrkit itself
only Depends on the tools needed for audio CDs but Recommends the tools
for DVD authoring.)  On the other hand, since the gnome metapackage
pulls in brasero, this directly adds a pile of packages to standard
desktop installs.

cron Recommends: exim4 | postfix | mail-transport-agent

Subject of a great deal of debate.  I've worked on patches to make cron
capable of logging output rather than send email.  I'm hopeful that
someday a default Debian install (of either standard or a full desktop)
will not include a running MTA, even with the default configuration that
has Recommends enabled.  But for now, I'm glad that at least nothing I
have installed has a hard Depends on an MTA.

cups Recommends: printer-driver-gutenprint

Why does cups recommend some printer drivers and only suggest others?
For instance, I have printer-driver-hpcups installed instead.

devscripts Recommends: at

Don't want an extra daemon running, and I don't use the only tool that
wants this.

dict Recommends: gawk

Not actually used by the "dict" tool, but by a separate tool "colorit"
that dict ships, unrelated except that they come from the same upstream
source package.  Perhaps dict could split out colorit into a separate
binary package?  https://bugs.debian.org/573608

emacs24-common Recommends: emacs24-el

I don't think all but the most unusual configurations need the elisp
source of the functionality already provided by the main emacs24
package.  Emacs/elisp developers will want this.

empathy Recommends: telepathy-haze

I only have empathy installed because GNOME depends on it.

evolution Recommends: bogofilter | spamassassin

I only have evolution itself installed because GNOME depends on it; I
certainly don't need additional dependencies for its optional
spam-filtering plugins.

gdb Recommends: gdbserver

Doesn't actually seem likely that most users of gdb will use gdbserver
on the system they install gdb on.  (Might use it on a target system,
but the target system probably won't need gdb installed.)  Bug filed.

hoichess Recommends: xboard >= 4.2.7-1 | scid

I'd guess that far more users have hoichess installed as a dependency of
gnome-games (which includes its own frontend) than use it with xboard or
scid.  Bug filed.

inkscape Recommends: libgnomevfs2-extra

How would people know if they need this or not?  It also doesn't seem to
have particularly excessive dependencies, and those it does have are
already pulled in by other paths.  

Re: Opt out style recommends

[Neil Williams]

On Fri, 8 Apr 2016 10:47:16 +0200
Adrien CLERC  wrote:

> >> It makes me think I'd love a system where Apt::Install-Recommends
> >> could be set to "ask" and let apt ask me if I want the recommended
> >> packages for my current request.  
> > apt already shows you which packages are to be brought in as
> > Recommends on every invocation and unless you use the -y option you
> > get the option to quit. You can already choose to quit and call apt
> > with the --no-install-recommends option for this specific
> > invocation of apt. 
> This involves a lot of keypresses, and I'm incredibly lazy ;)
> I was just wondering if apt could be more interactive, or if it is a
> design choice not to ask too many questions.

If you want interactive, use aptitude or synaptic.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpZ08fn8x7ew.pgp
Description: OpenPGP digital signature

Re: Opt out style recommends

[Adrien CLERC]

Le 08/04/2016 10:10, Neil Williams a écrit :
> On Fri, 8 Apr 2016 09:58:04 +0200
> Adrien CLERC  wrote:
>
>> Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit :
>>> [1]: I say default here, but really, systems which turn off
>>> installing things which are Recommended are almost unusuable; I
>>> know for a while it was the policy of #debian to just turn away
>>> people who had done that because the system would be in such a
>>> strange state. Sincerely,   
>> While I think installing recommended packages by default is a good
>> choice, disabling it is also a really good option on servers.
>> Installing every recommended packages is sometimes the best way to
>> bloat your system.
>>
>> It makes me think I'd love a system where Apt::Install-Recommends
>> could be set to "ask" and let apt ask me if I want the recommended
>> packages for my current request.
> apt already shows you which packages are to be brought in as Recommends
> on every invocation and unless you use the -y option you get the
> option to quit. You can already choose to quit and call apt with the
> --no-install-recommends option for this specific invocation of apt.
>
This involves a lot of keypresses, and I'm incredibly lazy ;)
I was just wondering if apt could be more interactive, or if it is a
design choice not to ask too many questions.

Adrien

Re: Opt out style recommends

[Johannes Schauer]

Hi,

Quoting Pirate Praveen (2016-04-08 09:48:59)
> On 2016, ഏപ്രിൽ 8 12:42:30 PM IST, Tiago Ilieve  wrote:
> >Maybe you can use an environment that's a little bit closer to a
> >standard system installation (at least to a point where you can expect
> >normal APT behavior), like a Docker or LXC container, which are
> >lighter than complete virtual machines. That's what I've been doing to
> >test packages.
> >
> >It's even easier to use them with Vagrant, as you can see in this[1]
> >repository.
> 
> Can you run lxc or docker inside an OpenVZ instance?

if not, then there is also schroot which is a chroot manager with cool features
like not needing sudo to enter a chroot or support for overlayfs.

Though with schroot (because it's basically a chroot frontend) you don't get as
much isolation as you'd get with lxc or docker which also separate the network
or process namespaces from the host for you.

On the other hand, (because it's basically a chroot frontend) I see no reason
why it shouldn't work on an OpenVZ instance.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Opt out style recommends

[Neil Williams]

On Fri, 8 Apr 2016 09:58:04 +0200
Adrien CLERC  wrote:

> Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit :
> > [1]: I say default here, but really, systems which turn off
> > installing things which are Recommended are almost unusuable; I
> > know for a while it was the policy of #debian to just turn away
> > people who had done that because the system would be in such a
> > strange state. Sincerely,   
> While I think installing recommended packages by default is a good
> choice, disabling it is also a really good option on servers.
> Installing every recommended packages is sometimes the best way to
> bloat your system.
> 
> It makes me think I'd love a system where Apt::Install-Recommends
> could be set to "ask" and let apt ask me if I want the recommended
> packages for my current request.

apt already shows you which packages are to be brought in as Recommends
on every invocation and unless you use the -y option you get the
option to quit. You can already choose to quit and call apt with the
--no-install-recommends option for this specific invocation of apt.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpuIpmE3_iQt.pgp
Description: OpenPGP digital signature

Re: Opt out style recommends

[Adrien CLERC]

Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit :
> [1]: I say default here, but really, systems which turn off installing
> things which are Recommended are almost unusuable; I know for a while
> it was the policy of #debian to just turn away people who had done
> that because the system would be in such a strange state. Sincerely, 
While I think installing recommended packages by default is a good
choice, disabling it is also a really good option on servers. Installing
every recommended packages is sometimes the best way to bloat your system.

It makes me think I'd love a system where Apt::Install-Recommends could
be set to "ask" and let apt ask me if I want the recommended packages
for my current request.

Adrien

Re: Opt out style recommends

[Pirate Praveen]

On 2016, ഏപ്രിൽ 8 12:42:30 PM IST, Tiago Ilieve  wrote:
>Maybe you can use an environment that's a little bit closer to a
>standard system installation (at least to a point where you can expect
>normal APT behavior), like a Docker or LXC container, which are
>lighter than complete virtual machines. That's what I've been doing to
>test packages.
>
>It's even easier to use them with Vagrant, as you can see in this[1]
>repository.

Can you run lxc or docker inside an OpenVZ instance?

>Regards,
>Tiago.
>
>[1]: https://github.com/myhro/vagrant-docker

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Opt out style recommends

[Tiago Ilieve]

Pirate,

On 8 April 2016 at 02:30, Pirate Praveen  wrote:
> I use 'cowbuilder --login' chroot to test gitlab installs on a clean system.

Maybe you can use an environment that's a little bit closer to a
standard system installation (at least to a point where you can expect
normal APT behavior), like a Docker or LXC container, which are
lighter than complete virtual machines. That's what I've been doing to
test packages.

It's even easier to use them with Vagrant, as you can see in this[1] repository.

Regards,
Tiago.

[1]: https://github.com/myhro/vagrant-docker

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Opt out style recommends

[Pirate Praveen]

On Friday 08 April 2016 10:52 AM, Paul Wise wrote:
> Yes, pbuilder/sbuild both disable recommends by default. I doubt
> anything will build-depend on gitlab though :)
> 

I use 'cowbuilder --login' chroot to test gitlab installs on a clean system.



signature.asc
Description: OpenPGP digital signature

Re: Opt out style recommends

[Jonas Smedegaard]

Quoting Pirate Praveen (2016-04-08 06:27:26)
> On 2016, ഏപ്രിൽ 8 9:22:58 AM IST, Paul Wise  wrote:
> >Only if the sysadmin has disabled recommends, usually they are opt-out
> >by default.
> 
> I was thinking the same, but when tried it in a cowbuilder --login 
> chroot, letsencrypt was not installed. May be that is 
> cowbuilder/pbuilder defaults.

It is: Recent versions of pbuilder adds /etc/apt/apt.conf.d/15pbuilder
which disables recommends.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Opt out style recommends

[Paul Wise]

On Fri, Apr 8, 2016 at 12:27 PM, Pirate Praveen wrote:

> I was thinking the same, but when tried it in a cowbuilder --login chroot, 
> letsencrypt was not installed. May be that is cowbuilder/pbuilder defaults.

Yes, pbuilder/sbuild both disable recommends by default. I doubt
anything will build-depend on gitlab though :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Opt out style recommends

[Pirate Praveen]

On 2016, ഏപ്രിൽ 8 9:22:58 AM IST, Paul Wise  wrote:
>Only if the sysadmin has disabled recommends, usually they are opt-out
>by default.

I was thinking the same, but when tried it in a cowbuilder --login chroot, 
letsencrypt was not installed. May be that is cowbuilder/pbuilder defaults.

Thanks for the confirmation.

>> But I would like letsencrypt to be available by default (postinst
>asks if
>> they want to use letsencrypt, there is no way to install letsencrypt
>after
>> that question).
>
>What about `dpkg-reconfigure gitlab`?

I have not tested it yet. I'll test it.

>> May be we could add a field like Optional, which will be like Depends
>unless
>> removed manually.
>
>That is exactly what Recommends means, unless you configure your
>system to treat it like Suggests (which many sysadmins do).

Like I said above, cowbuilder defaults to not installing recommends.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Opt out style recommends

[Harlan Lieberman-Berg]

Pirate Praveen  writes:
> Currently gitlab recommends letsencrypt, it means someone has to opt in for 
> letsencrypt by running something like

Hello!

By default [1], apt will install packages which are Recommended when you
install the first one.

If gitlab Recommends letsencrypt, it will install letsencrypt when the
user installs gitlab.  "Suggests" is the weaker version of what you
describe, where the user is given the name of the package during the
install prompt, but has to manually install it.

[1]: I say default here, but really, systems which turn off installing
things which are Recommended are almost unusuable; I know for a while it
was the policy of #debian to just turn away people who had done that
because the system would be in such a strange state.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Re: Opt out style recommends

[Paul Wise]

On Fri, Apr 8, 2016 at 11:33 AM, Pirate Praveen wrote:
> See #819854 for a background.
>
> Currently gitlab recommends letsencrypt, it means someone has to opt in for
> letsencrypt by running something like
>
> apt-get install gitlab letsencrypt

Only if the sysadmin has disabled recommends, usually they are opt-out
by default.

> But I would like letsencrypt to be available by default (postinst asks if
> they want to use letsencrypt, there is no way to install letsencrypt after
> that question).

What about `dpkg-reconfigure gitlab`?

> May be we could add a field like Optional, which will be like Depends unless
> removed manually.

That is exactly what Recommends means, unless you configure your
system to treat it like Suggests (which many sysadmins do).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Opt out style recommends

[Pirate Praveen]

See #819854 for a background.

Currently gitlab recommends letsencrypt, it means someone has to opt in for 
letsencrypt by running something like

apt-get install gitlab letsencrypt

But I would like letsencrypt to be available by default (postinst asks if they 
want to use letsencrypt, there is no way to install letsencrypt after that 
question).

So those who don't want it can run something like

apt-get install gitlab -letsencrypt

The other solution was something like dbconfig-no-thanks for letsencrypt 
(letsencrypt-no-thanks), but letsencrypt maintainers don't think its a good 
idea.

May be we could add a field like Optional, which will be like Depends unless 
removed manually.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.