Packages to install be default for Stretch

[Ansgar Burchardt]

Hi,

[ Please send replies only to boot@ ]

I would like to re-evaluate what we change by default for Stretch, that
is the list of packages with priorities required, important and
standard.  In general my plan involves installing less, taking into
consideration that requirements and expectations what should be
available in containers, chroots, on servers and desktop systems has
changed (at least IMHO).

Some ideas which might need further though:

 * I would really like to not list libraries at a priority greater than
   optional. This tends to accumulate cruft, cf. #758234

   Examples from today's unstable: gcc-4.7-base, gcc-4.8-base,
   gcc-4.9-base and gcc-5-base are at Priority: required.
   libboost-iostreams1.5{4,5}.0 are at Priority: important
   and so on.

   As far as I remember, debootstrap already ignores priorities for
   library packages (Section: libs).

 * It would be nice to have "init" demoted from required to
   important: it is not needed in environments like (buildd) chroots.
   This needs moving the essential bit to sysv-rc (which provides
   invoke-rc.d and update-rc.d) and possibly other changes.

 * I'm wondering if "tasksel(-data)" need to be "important"? I admit not
   having used it outside of d-i. Is the installed version used as part
   of the install process? Or could its priority be lowered to
   "standard" or "optional"?

 * Same for question for "dmidecode": could the priority be lowered to
   "standard"?

Some priority changes which I believe could be implemented:

 * Packages currently at "important":
- cron:
  Not needed in chroot/container environments.
  -> demote to "standard"
- ifupdown, isc-dhcp-client, isc-dhcp-common:
  Not needed in chroot/container environments. Might no longer be
  needed on desktop systems (IIRC NetworkManager has a built-in DHCP
  client in the last release, though not yet used by default).
  -> demote to "standard"
- groff-base, man-db, manpages:
  Not needed in chroot/container environments or many server
  environments.
  -> demote to "standard"
- less:
  Not needed in chroot/container environments.
  -> demote to "standard"
- logrotate, rsyslog:
  -> tempted to demote to "standard", but maybe only in buster
- nfacct:
  No idea why this is at Priority: important.
  -> demote to "optional"
- netcat-traditional:
  No IPv6 support...
  -> demote to "standard", possibly to "optional" in buster
- traceroute, wget:
  Useful for debugging, but not needed in chroot/container
  environments.
  -> demote to "standard"

 * Packages currently at "standard":
- aptitude, aptitude-common:
  There's already apt.
  -> demote to "optional"
- at:
  Rarely used (IMO).
  -> demote to "optional"
- bc, dc:
  Rarely used (IMHO).
  -> demote to "optional"
- dnsutils:
  bind9-host provides a (limited) DNS query interface. No need to
  install both bind9-host and dnsutils by default.
  -> demote to "optional"
- bsd-mailx, exim4*, procmail, mutt:
  Often not useful on desktop systems, has popular alternatives,
  probably not needed in chroot/container environments either.
  -> demote to "optional"
- ftp:
  Brr, ftp.
  -> demote to "optional"
- info, texinfo, install-info:
  I admit having used info only in desperation. Most documentation
  comes in man page format.
  -> demote to "optional"
- host:
  Transitional package.
  -> demote to "extra" (+ Section: oldlibs)
- m4:
  Rarely used (AFAIK). Well, at least outside of auto* and sendmail.
  -> demote to "optional"
- mlocate:
  Rarely used (AFAIK).
  -> demote to "optional"
- nfs-common, rpcbind:
  NFS is not so common to include in every install. One less service
  listening to the network.
  -> demote to "optional"
- patch:
  Does anyone use this w/o having build-essential installed?
  -> demote to "optional"
- time:
  'time' is a builtin in at least bash and zsh.
  -> demote to "optional"
- w3m:
  I think text-mode browsers are not worth including in the default
  install. It is *very* rare to not have another computer to use.
  Plus in the worst case the package is still just an apt-get away.
  -> demote to "optional"
- whois:
  Too special to include in standard install.
  -> demote to "optional"

Any comments and/or suggestion for other changes?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3qurhhm@deep-thought.43-1.org

Re: Packages to install be default for Stretch

[Hideki Yamane]

Hi,

On Tue, 05 May 2015 20:45:09 +0200
Ansgar Burchardt  wrote:
> In general my plan involves installing less, taking into
> consideration that requirements and expectations what should be
> available in containers, chroots, on servers and desktop systems has
> changed (at least IMHO).

 Just a question, is there any summary for this effort?
 (something like "Jessie: xxx MB -> Stretch yyy MB")


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Re: Packages to install be default for Stretch

[Samuel Thibault]

Ansgar Burchardt, le Tue 05 May 2015 20:45:09 +0200, a écrit :
> - info, texinfo, install-info:
>   I admit having used info only in desperation. Most documentation
>   comes in man page format.
>   -> demote to "optional"

Proper autoconf, automake, gcc, etc. documentations only really come in
info format.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150505230920.gc2...@type.youpi.perso.aquilenet.fr

Re: Packages to install be default for Stretch

[Wookey]

+++ Samuel Thibault [2015-05-06 01:09 +0200]:
> Ansgar Burchardt, le Tue 05 May 2015 20:45:09 +0200, a écrit :
> > - info, texinfo, install-info:
> >   I admit having used info only in desperation. Most documentation
> >   comes in man page format.
> >   -> demote to "optional"
> 
> Proper autoconf, automake, gcc, etc. documentations only really come in
> info format.

Indeed.

If we are going to have an info reader installed can it please be
pinfo instead of info? It's _so_ much better. 

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506022113.gi24...@halon.org.uk

Re: Packages to install be default for Stretch

[Paul Wise]

On Wed, May 6, 2015 at 2:45 AM, Ansgar Burchardt wrote:

>  * Same for question for "dmidecode": could the priority be lowered to
>"standard"?

As this relates to specific hardware/firmware, this should be moved to
optional and d-i/isenkram/PackageKit/etc should install it when
installing on the right class of systems, based on hw-detect, isenkram
or DEP-11 data.

> - cron:
>   Not needed in chroot/container environments.
>   -> demote to "standard"

A lot of packages ship cron jobs, I guess this means they will need to
depend on cron?

> - logrotate, rsyslog:
>   -> tempted to demote to "standard", but maybe only in buster

Same for this.

> - at:
>   Rarely used (IMO).
>   -> demote to "optional"

I'd keep this at standard.

> - mlocate:
>   Rarely used (AFAIK).
>   -> demote to "optional"

I'd keep this at standard.

> - w3m:
>   I think text-mode browsers are not worth including in the default
>   install. It is *very* rare to not have another computer to use.
>   Plus in the worst case the package is still just an apt-get away.
>   -> demote to "optional"

I'd wager most use of w3m is for local-only web resources on servers.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gkcrpbfnja4cmqel+omnxtghgmdzl+bzauhvpvqzn...@mail.gmail.com

Re: Packages to install be default for Stretch

[Josh Triplett]

Paul Wise wrote:
> On Wed, May 6, 2015 at 2:45 AM, Ansgar Burchardt wrote:
> > - cron:
> >   Not needed in chroot/container environments.
> >   -> demote to "standard"
> 
> A lot of packages ship cron jobs, I guess this means they will need to
> depend on cron?

cron was never "Essential: yes", so if a package depended on it for key
functionality, it already should have depended on cron. And various packages
do.

On the other hand, packages optionally enhanced by a cron job could use
suggests or recommends.

> > - logrotate, rsyslog:
> >   -> tempted to demote to "standard", but maybe only in buster
> 
> Same for this.

Packages that absolutely need a system log daemon should depend on
system-log-daemon, sure. (Also, there should really be a
"default-system-log-daemon", similar to default-mta, to make it easier to
change the default in the future without changing multiple packages.) Most
packages, however, don't absolutely depend on a syslog daemon; they just
benefit from having logging around.

That said, as mentioned in my response, I think rsyslog ought to stay important
until something else replaces it.  Logging of *some* kind is important.

logrotate, on the other hand, is already a Recommends of rsyslog, and I think
that's the strongest dependency it should have from any package.

> > - at:
> >   Rarely used (IMO).
> >   -> demote to "optional"
> 
> I'd keep this at standard.

Why, when it's just an "apt install at" away?  It's one more running
daemon.  Realistically, what fraction of Debian users actually invoke
at, ever, and of those, what fraction will be deeply disturbed by having
to install it first?

> > - mlocate:
> >   Rarely used (AFAIK).
> >   -> demote to "optional"
> 
> I'd keep this at standard.

I'd rather have one less daily cron job indexing files for a command
most people will never run.  Anyone who wants it can trivially install
it.

Also, find on / really doesn't take that long these days, even with a
cold cache.

> > - w3m:
> >   I think text-mode browsers are not worth including in the default
> >   install. It is *very* rare to not have another computer to use.
> >   Plus in the worst case the package is still just an apt-get away.
> >   -> demote to "optional"
> 
> I'd wager most use of w3m is for local-only web resources on servers.

Or reading/previewing HTML on text-only systems, sure.  But that's not
really something that needs to live in standard.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506040210.GA15767@x

Re: Packages to install be default for Stretch

[Alexandre Detiste]

Hi,

Le mardi 5 mai 2015, 21:02:14 Josh Triplett a écrit :
> Paul Wise wrote:
> > On Wed, May 6, 2015 at 2:45 AM, Ansgar Burchardt wrote:
> > > - cron:
> > >   Not needed in chroot/container environments.
> > >   -> demote to "standard"
> > 
> > A lot of packages ship cron jobs, I guess this means they will need to
> > depend on cron?

They already do.

> cron was never "Essential: yes", so if a package depended on it for key
> functionality, it already should have depended on cron. And various packages
> do.
>
> On the other hand, packages optionally enhanced by a cron job could use
> suggests or recommends.

Or could better Depends/Recommends/Suggests on "cron-daemon"

This remind me to dig this mail and ask again
propermy to complete the migration to "cron-daemon"
that got started 5 years ago now that Jessie has been released.

https://lists.debian.org/debian-devel/2014/10/msg00474.html 
 
Alexandre Detiste


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/30446027.mNS7mfypdK@antec

Re: Packages to install be default for Stretch

[Paul Wise]

On Wed, May 6, 2015 at 12:02 PM, Josh Triplett wrote:

> Why, when it's just an "apt install at" away?  It's one more running
> daemon.  Realistically, what fraction of Debian users actually invoke
> at, ever, and of those, what fraction will be deeply disturbed by having
> to install it first?

The wording of the priorities in policy leads me to believe it should
be priority important rather than standard actually.

> Or reading/previewing HTML on text-only systems, sure.

As we recommend HTML as the default documentation format for Debian,
it would be strange to not have a viewer for that documentation on
every system.

https://www.debian.org/doc/debian-policy/ch-docs.html#s12.4

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6Hf8CXmQhWjD3xqZTQgx=z8Dkg1uNYo=9d6femsxvi...@mail.gmail.com

Re: Packages to install be default for Stretch

[Johannes Schauer]

Quoting Paul Wise (2015-05-06 08:17:58)
> On Wed, May 6, 2015 at 12:02 PM, Josh Triplett wrote:
> > Why, when it's just an "apt install at" away?  It's one more running
> > daemon.  Realistically, what fraction of Debian users actually invoke
> > at, ever, and of those, what fraction will be deeply disturbed by having
> > to install it first?
> 
> The wording of the priorities in policy leads me to believe it should
> be priority important rather than standard actually.

because at is expected to be present on a Unix system?

If Ansgar's idea was to take into consideration the changed requirements and
expectations nowadays when deciding about package priorities, then policy §2.5
should probably be changed to reflect these new requirements and expectations
as well.

> > Or reading/previewing HTML on text-only systems, sure.
> 
> As we recommend HTML as the default documentation format for Debian,
> it would be strange to not have a viewer for that documentation on
> every system.
> 
> https://www.debian.org/doc/debian-policy/ch-docs.html#s12.4

Maybe *-doc packages shipping HTML documentation should also
Recommends/Suggests www-browser? That would solve this, no?

cheers, josch


signature.asc
Description: signature

Re: Packages to install be default for Stretch

[Ansgar Burchardt]

Paul Wise  writes:
>> - cron:
>>   Not needed in chroot/container environments.
>>   -> demote to "standard"
>
> A lot of packages ship cron jobs, I guess this means they will need to
> depend on cron?

They already have to depend on cron if it is required for proper
operation (or recommend it). But there are also alternatives like
anacron that might be more appropriate on common systems (say desktop
or laptop systems).

But I admit "cron" was very close on the "maybe only demote in buster"
list.

>> - w3m:
>>   I think text-mode browsers are not worth including in the default
>>   install. It is *very* rare to not have another computer to use.
>>   Plus in the worst case the package is still just an apt-get away.
>>   -> demote to "optional"
>
> I'd wager most use of w3m is for local-only web resources on servers.

But is this enough reason to keep w3m at priority standard? Personally I
would rather use "ssh -D" or such than bothering with a rather limited
text-mode browser.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq0m417o@deep-thought.43-1.org

Re: Packages to install be default for Stretch

[Riku Voipio]

On Wednesday, May 6, 2015 5:21:14 AM EEST, Wookey wrote:

+++ Samuel Thibault [2015-05-06 01:09 +0200]:

Ansgar Burchardt, le Tue 05 May 2015 20:45:09 +0200, a écrit :

- info, texinfo, install-info:
  I admit having used info only in desperation. Most documentation
  comes in man page format.
  -> demote to "optional"


Proper autoconf, automake, gcc, etc. documentations only really come in
info format.



Indeed.



If we are going to have an info reader installed can it please be
pinfo instead of info? It's _so_ much better. 


I don't think that is a convincing reason to install info/pinfo as part of 
standard. I read gcc docs always online with a web browser, yet I don't 
insist chromium/firefox or even lynx being standard priority.


Checking the popcon[1] https://qa.debian.org/popcon.php?package=texinfo

We see that info is ranked 115 on installed list, yet it is also ranked at 
position 15 in "old" list (installed but not being used).


Riku,
brb, apt-get removing info and texinfo ffrom my systems...

[1] insert here the usual disclaimer that popcon is not to be taken as 
authorative source of anything, just to provide general idea

Riku



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1e65606b-0cc7-46fa-9889-b70f60521...@iki.fi

Re: Packages to install be default for Stretch

[Marco d'Itri]

On May 05, Ansgar Burchardt  wrote:

> I would like to re-evaluate what we change by default for Stretch, that
Me too.

Let's look at the problem from a different point of view. This is what
I remove when building cloud images for my employer's infrastructure:

dpkg --purge \
  discover discover-data libdiscover2 installation-report laptop-detect \
  nano tasksel tasksel-data task-english acpi acpid acpi-support-base \
  isc-dhcp-client isc-dhcp-common eject \
  nfacct libmnl0 libnetfilter-acct1 emacsen-common libsigc++-2.0-0c2a \
  pciutils usbutils libpci3 libusb-1.0-0 \
  dictionaries-common iamerican ibritish ienglish-common ispell wamerican

(And I wonder where emacsen-common comes from...)

Maybe hw-detect should differentiate between phisical and virtual 
targets?

So, another obvious candidate for demotion are ispell and friends.

>  * It would be nice to have "init" demoted from required to
>important: it is not needed in environments like (buildd) chroots.
We systemd maintainers strongly agree.

>  * Same for question for "dmidecode": could the priority be lowered to
>"standard"?
I think that this is fine, as long as it is still available in d-i.
But laptop-detect (which I do not understand why it is being installed 
on something that is very obviously not a laptop) depends on it.

> - logrotate, rsyslog:
>   -> tempted to demote to "standard", but maybe only in buster
Maybe rsyslog, but I do not think that we can do without logrotate even 
if nobody looks at the logs.
OTOH, why should it be explicitly installed? Everything that uses it 
already depends on it.

> - nfacct:
>   No idea why this is at Priority: important.
>   -> demote to "optional"
Even extra... This is a very niche package and I have no idea why it is 
being installed everywhere!

> - dnsutils:
>   bind9-host provides a (limited) DNS query interface. No need to
>   install both bind9-host and dnsutils by default.
>   -> demote to "optional"
I disagree about this one: the installed size is only 374 kB and host 
is not really a replacement for dig, which is invaluable when you 
actually need to troubleshoot DNS issues (even just looking at the 
difference between NXDOMAIN and SERVFAIL when a domain does not 
resolve, or even worse DNSSEC issues...).

> - bsd-mailx, exim4*, procmail, mutt:
>   Often not useful on desktop systems, has popular alternatives,
>   probably not needed in chroot/container environments either.
>   -> demote to "optional"
Everything that needs them already depends on them.
Also, can we finally replace exim with postfix as the default for 
stretch? :-)

> - mlocate:
>   Rarely used (AFAIK).
>   -> demote to "optional"
I think that it is useful enough that is deserves to be standard.

> - w3m:
>   I think text-mode browsers are not worth including in the default
>   install. It is *very* rare to not have another computer to use.
Agreed.

> - whois:
>   Too special to include in standard install.
>   -> demote to "optional"
As the maintainer I think that I have to agree...

-- 
ciao,
Marco


pgp9GMJBbeCEQ.pgp
Description: PGP signature

Re: Packages to install be default for Stretch

[Marco d'Itri]

On May 06, Josh Triplett  wrote:

> That said, as mentioned in my response, I think rsyslog ought to stay 
> important
> until something else replaces it.  Logging of *some* kind is important.
We have journald. :-)

> Why, when it's just an "apt install at" away?  It's one more running
> daemon.  Realistically, what fraction of Debian users actually invoke
> at, ever, and of those, what fraction will be deeply disturbed by having
> to install it first?
Very few, I agree. Let's demote at.

> I'd rather have one less daily cron job indexing files for a command
> most people will never run.  Anyone who wants it can trivially install
> it.
The impact on the system is minimal since it uses nice and ionice.
I would rather keep mlocate.

-- 
ciao,
Marco


pgpRj6jUAXoeA.pgp
Description: PGP signature

Re: Packages to install be default for Stretch

[Marco d'Itri]

On May 06, Ansgar Burchardt  wrote:

> But is this enough reason to keep w3m at priority standard? Personally I
> would rather use "ssh -D" or such than bothering with a rather limited
> text-mode browser.
Agreed.

-- 
ciao,
Marco


pgppFLgum_uM8.pgp
Description: PGP signature

Re: Packages to install be default for Stretch

[Martin Zobel-Helas]

Hi, 

On Tue May 05, 2015 at 20:45:09 +0200, Ansgar Burchardt wrote:
>  * Packages currently at "important":
> - cron:
>   Not needed in chroot/container environments.
>   -> demote to "standard"

RC.

| important
| Important programs, including those which one would expect to find on
| any Unix-like system. If the expectation is that an experienced Unix
| person who found it missing would say "What on earth is going on, where
| is foo?", it must be an important package.[6] Other packages without
| which the system will not run well or be usable must also have priority
| important. This does not include Emacs, the X Window System, TeX or any
| other large applications. The important packages are just a bare minimum
| of commonly-expected and necessary tools.

cron is part of POSIX.

http://www.unix.com/apropos-man/posix/1/cron/

We had a similar discussion about this recently with the package 'ed',
as there is a bug against 'ed' which wants it back in 'important'
(#776413 and #776557).

So either we fix the policy or cron needs to stay in 'important'.

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506093459.gl9...@ftbfs.de

Re: Packages to install be default for Stretch

[Ansgar Burchardt]

On 05/06/2015 11:34 AM, Martin Zobel-Helas wrote:
> On Tue May 05, 2015 at 20:45:09 +0200, Ansgar Burchardt wrote:
>>  * Packages currently at "important":
>> - cron:
>>   Not needed in chroot/container environments.
>>   -> demote to "standard"
> 
> RC.
> 
> | important
> | Important programs, including those which one would expect to find on
> | any Unix-like system. If the expectation is that an experienced Unix
> | person who found it missing would say "What on earth is going on, where
> | is foo?", it must be an important package.[6] Other packages without
> | which the system will not run well or be usable must also have priority
> | important. This does not include Emacs, the X Window System, TeX or any
> | other large applications. The important packages are just a bare minimum
> | of commonly-expected and necessary tools.
> 
> cron is part of POSIX.

The problem here is what the expectations of an experienced UNIX person
are... I hopefully count as having some experience, but I don't expect
cron to be available everywhere (unlike say awk); I would still expect
it to be part of a "reasonably small but not too limited character-mode
system" (that is "standard" priority).

Note that I believe this has changed over time: with the advent of VMs
and containers the expectations what a system should minimally provide
have become smaller.

I'll not comment on where I see emacs and vim ;)

> http://www.unix.com/apropos-man/posix/1/cron/

Note that this also includes the following requirement:

| If standard output and standard error are not redirected by commands |
executed from the crontab entry, any generated output or errors shall |
be mailed, via an implementation-defined method, to the user.

That requires something to deliver mail. However I really don't think we
want a MTA to be at "important" priority.

> So either we fix the policy or cron needs to stay in 'important'.

"at", "m4", "mailx", ... are also not at "important", though required by
POSIX.

But as admitted earlier, I am not totally sure about "cron". Maybe we
should keep it at "important" at least for stretch and revisit it in the
buster cycle; not sure yet.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5549eb1a.6020...@debian.org

Re: Packages to install be default for Stretch

[Paul Wise]

On Wed, May 6, 2015 at 6:21 PM, Ansgar Burchardt wrote:
> On 05/06/2015 11:34 AM, Martin Zobel-Helas wrote:
>> cron is part of POSIX.
>
> The problem here is what the expectations of an experienced UNIX person are...

Perhaps unix/posix tasks would satisfy such folks.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6FdCWn7c5iqPhZyMe=9m+aippavxuojqornakhns2f...@mail.gmail.com

Re: Packages to install be default for Stretch

[Neil Williams]

On Wed, 6 May 2015 18:26:19 +0800
Paul Wise  wrote:

> On Wed, May 6, 2015 at 6:21 PM, Ansgar Burchardt wrote:
> > On 05/06/2015 11:34 AM, Martin Zobel-Helas wrote:
> >> cron is part of POSIX.
> >
> > The problem here is what the expectations of an experienced UNIX
> > person are...
> 
> Perhaps unix/posix tasks would satisfy such folks.

Tasks may well be a good solution.

There are two discussions here:

0: What do we want by default in a chroot or other container?

1: What do we want by default in a "work/Unix/POSIX environment"?

The minimum should be enough to get a working chroot (and that is
likely to involve an editor of some kind but either no daemons or only
minimal daemons).

Those who want more can specify different options to debootstrap (for
example) to include tasks.

We have --variant=buildd already.

It could be similar in DI - standard system utilities could include
more packages than a simple debootstrap would provide, like cron and
others.

Maybe we need to split the discussion based on what should be in a
minimal debootstrap and what should be in standard system utilities in
DI?

-- 


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



pgptbr0OC7p5p.pgp
Description: OpenPGP digital signature

Re: Packages to install be default for Stretch

[Marco d'Itri]

On May 06, Ansgar Burchardt  wrote:

> Note that I believe this has changed over time: with the advent of VMs
> and containers the expectations what a system should minimally provide
> have become smaller.
The differences between VMs and "normal" servers are very small, limited 
only to a few packages needed for hardware support and detection.
The differences between regular Linux systems and containers is large 
enough that I do not believe that one default can satisfy the needs 
of both.

-- 
ciao,
Marco


pgp76UrMOjITI.pgp
Description: PGP signature

Re: Packages to install be default for Stretch

[Steve McIntyre]

On Wed, May 06, 2015 at 06:26:19PM +0800, Paul Wise wrote:
>On Wed, May 6, 2015 at 6:21 PM, Ansgar Burchardt wrote:
>> On 05/06/2015 11:34 AM, Martin Zobel-Helas wrote:
>>> cron is part of POSIX.
>>
>> The problem here is what the expectations of an experienced UNIX person 
>> are...
>
>Perhaps unix/posix tasks would satisfy such folks.

IIRC we agreed on such a thing the last time we had this discussion?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506110626.gc7...@einval.com

Re: Packages to install be default for Stretch

[Vincent Lefevre]

On 2015-05-06 12:21:14 +0200, Ansgar Burchardt wrote:
> On 05/06/2015 11:34 AM, Martin Zobel-Helas wrote:
> > cron is part of POSIX.
> 
> The problem here is what the expectations of an experienced UNIX person
> are... I hopefully count as having some experience, but I don't expect
> cron to be available everywhere (unlike say awk); I would still expect
> it to be part of a "reasonably small but not too limited character-mode
> system" (that is "standard" priority).

Personally I expect cron to be any on my machines, but it is not that
bad if it not installed. At least the user could wonder at the same
time whether he needs something more, such as anacron.

And if it is missing, the user would notice it when he first tries
to use it. It is not like if it were some hidden feature.

> Note that I believe this has changed over time: with the advent of VMs
> and containers the expectations what a system should minimally provide
> have become smaller.
> 
> I'll not comment on where I see emacs and vim ;)

But why is "nano" important? I suspect that most users use emacs or vim.

> > http://www.unix.com/apropos-man/posix/1/cron/
> 
> Note that this also includes the following requirement:
> 
> | If standard output and standard error are not redirected by commands |
> executed from the crontab entry, any generated output or errors shall |
> be mailed, via an implementation-defined method, to the user.
> 
> That requires something to deliver mail. However I really don't think we
> want a MTA to be at "important" priority.
> 
> > So either we fix the policy or cron needs to stay in 'important'.
> 
> "at", "m4", "mailx", ... are also not at "important", though required by
> POSIX.

And I certainly wouldn't see c99 as "important", also required by POSIX.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506120929.ga8...@ypig.lip.ens-lyon.fr

Re: Packages to install be default for Stretch

[Martin Zobel-Helas]

Hi, 

On Wed May 06, 2015 at 14:09:30 +0200, Vincent Lefevre wrote:
> > Note that I believe this has changed over time: with the advent of VMs
> > and containers the expectations what a system should minimally provide
> > have become smaller.
> > 
> > I'll not comment on where I see emacs and vim ;)
> 
> But why is "nano" important? I suspect that most users use emacs or vim.

ed needs to go back into important, so we can drop the other editors? 

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506122106.gm9...@ftbfs.de

Re: Packages to install be default for Stretch

[Bastian Blank]

On Wed, May 06, 2015 at 02:21:06PM +0200, Martin Zobel-Helas wrote:
> ed needs to go back into important, so we can drop the other editors? 

We have vim-tiny in important, which provides "ex", aka mostly ed.

Bastian

-- 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506133753.ga17...@shell.waldi.eu.org

Re: Packages to install be default for Stretch

[Vincent Lefevre]

On 2015-05-06 11:21:13 +0200, Marco d'Itri wrote:
> On May 05, Ansgar Burchardt  wrote:
> > - nfacct:
> >   No idea why this is at Priority: important.
> >   -> demote to "optional"
> Even extra... This is a very niche package and I have no idea why it is 
> being installed everywhere!

It seems that some developers don't know what they're doing, or
something is completely broken in the Debian system, because it
is claimed to be set to extra in November 2014, when this bug
was closed:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758229

This bug should be reopened.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506140918.gb13...@ypig.lip.ens-lyon.fr

Re: Packages to install be default for Stretch

[Neil Williams]

On Wed, 6 May 2015 16:09:18 +0200
Vincent Lefevre  wrote:

> On 2015-05-06 11:21:13 +0200, Marco d'Itri wrote:
> > On May 05, Ansgar Burchardt  wrote:
> > > - nfacct:
> > >   No idea why this is at Priority: important.
> > >   -> demote to "optional"
> > Even extra... This is a very niche package and I have no idea why
> > it is being installed everywhere!
> 
> It seems that some developers don't know what they're doing, or
> something is completely broken in the Debian system, because it
> is claimed to be set to extra in November 2014, when this bug
> was closed:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758229
> 
> This bug should be reopened.

https://packages.qa.debian.org/n/nfacct.html
There were override disparities found in suite unstable:
nfacct: Override says net - important, .deb says net - extra

After changing the priority in the package, the uploader would have
received email warning that the override does not match and explaining
how to get the override updated if the change in the package was
correct.

It is also in the developer reference:
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#override-file

So, no, there isn't something broken - the uploader needs to file the
bug as set out in the developer reference.

(BTW - the problems section doesn't transfer to the tracker version, so
this notice is only available in the PTS.)

-- 


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



pgpbSsmD_sdov.pgp
Description: OpenPGP digital signature

Re: Packages to install be default for Stretch

[Marco d'Itri]

On May 06, Neil Williams  wrote:

> So, no, there isn't something broken - the uploader needs to file the
> bug as set out in the developer reference.
And please have this fixed in stable as well.

-- 
ciao,
Marco


pgp6i77j5JMCo.pgp
Description: PGP signature

Re: Packages to install be default for Stretch

[Vincent Lefevre]

On 2015-05-06 15:23:58 +0100, Neil Williams wrote:
> So, no, there isn't something broken - the uploader needs to file the
> bug as set out in the developer reference.

Thanks for the information. To make sure that it is done and since
bugs.debian.org didn't show any such bug, I've just filed such a bug,
with the uploader in Cc.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506150045.gc13...@ypig.lip.ens-lyon.fr

Re: Packages to install be default for Stretch

[Dimitri John Ledkov]

On 5 May 2015 at 19:45, Ansgar Burchardt  wrote:
>  * Packages currently at "important":
> - cron:
>   Not needed in chroot/container environments.

Hm, i'd say it's not needed full-stop. There are systemd timer units
and e.g. systemd-cron that satisfy the need for periodic execution,
with persistence available across reboots to mimic anacron like jobs
(OnCalendar & Persistent options in systemd.timer units).

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANBHLUixx_cEnsXOVgRKtdmibS_nywAPZbm=j1k-qrnhwlo...@mail.gmail.com

Re: Packages to install be default for Stretch

[Hideki Yamane]

On Wed, 6 May 2015 14:17:58 +0800
Paul Wise  wrote:
> it would be strange to not have a viewer for that documentation on
> every system.
> 
> https://www.debian.org/doc/debian-policy/ch-docs.html#s12.4

 Probably minimal container (and embedded) systems don't need to have docs
 and viewers, IMO. Demoting some packages' priority can carry smaller and
 better system for them. 

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150509210810.3eecb0bd6e27162f7199a...@debian.or.jp

Re: Packages to install be default for Stretch

[Zack Weinberg]

I'd like to provide a data point.  On servers that I maintain, this is
the complete list of manually-installed packages, excluding packages
related to what the server actually _does_ -- that is, this, and
nothing else, are what I consider vital to have available on a generic
server that no one logs into except for maintenance.

This is a virtual machine guest configuration, running a completely
monolithic kernel provided from outside the image, hence the absence
of most hardware-configuration-related packages.  Note also that I
always turn off auto-installation of recommended packages, and that
this particular server was upgraded from wheezy to jessie in the most
straightforward fashion, which *didn't* install systemd, and I haven't
bothered changing it.

bind9-host (†)
bsd-mailx (†)
debsums
dnsutils (†)
iputils-ping
less
locales (*)
logcheck
logcheck-database
lsof
monit
needrestart
netcat-traditional (†)
nullmailer
nvi (‡)
openntpd
openssh-client
openssh-server
resolvconf
strace
udev (*)
ufw
unattended-upgrades
unbound
whois
wget

(*) - I don't understand why nothing depends on these.
(†) - I am confused by the number of overlapping packages that do this
job, and may not have picked the optimal ones.
(‡) - vim is insufficiently bug-compatible with Solaris 2.5 vi for my fingers.

Relative to the default install, the interesting bits, I think, are:

+ network and system diagnostic tools
+ unattended upgrade mechanism
+ monit (maybe systemd can replace this, but I'm not comfortable
enough with it yet)
+ openntpd
+ unbound
+ nullmailer
- all documentation
- at
- tasksel
- exim
- miscellaneous command-line tools that I can install if I ever need
them (e.g. bzip2, cpio)

The full package list (again, minus packages defining what the server
actually _does_) is attached.

zw


package.list
Description: Binary data

Re: Packages to install be default for Stretch

[Hideki Yamane]

Hi,

On Tue, 05 May 2015 20:45:09 +0200
Ansgar Burchardt  wrote:
> I would like to re-evaluate what we change by default for Stretch, that
> is the list of packages with priorities required, important and
> standard.  In general my plan involves installing less, taking into
> consideration that requirements and expectations what should be
> available in containers, chroots, on servers and desktop systems has
> changed (at least IMHO).

 Some package are useful in users' environment but tasksel or similar
 tool can solve it. I agree for whole suggestion.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150510120836.87cbf7183cf19909fdf40...@debian.or.jp

Re: Packages to install be default for Stretch

[Cyril Brulebois]

Hi,

Ansgar Burchardt  (2015-05-05):
> [ Please send replies only to boot@ ]
> 
> I would like to re-evaluate what we change by default for Stretch, that
> is the list of packages with priorities required, important and
> standard.  In general my plan involves installing less, taking into
> consideration that requirements and expectations what should be
> available in containers, chroots, on servers and desktop systems has
> changed (at least IMHO).

You've approached me/us a while ago, and I asked for a delay so that we
had a chance to release an Alpha before touching priorities. D-I Stretch
Alpha 1 being out, feel free to start moving things forward.

> Some ideas which might need further though:
> 
>  * I would really like to not list libraries at a priority greater than
>optional. This tends to accumulate cruft, cf. #758234
> 
>Examples from today's unstable: gcc-4.7-base, gcc-4.8-base,
>gcc-4.9-base and gcc-5-base are at Priority: required.
>libboost-iostreams1.5{4,5}.0 are at Priority: important
>and so on.
> 
>As far as I remember, debootstrap already ignores priorities for
>library packages (Section: libs).

[ snip ]

>  * It would be nice to have "init" demoted from required to
>important: it is not needed in environments like (buildd) chroots.
>This needs moving the essential bit to sysv-rc (which provides
>invoke-rc.d and update-rc.d) and possibly other changes.

One has to be extra careful with that one.

>  * I'm wondering if "tasksel(-data)" need to be "important"? I admit not
>having used it outside of d-i. Is the installed version used as part
>of the install process? Or could its priority be lowered to
>"standard" or "optional"?

Let's pretend I don't know how d-i & tasksel work. Looking at
src:pkgsel, I see the udeb has a postinst that calls the following:
| in-target sh -c "tasksel --new-install --debconf-apt-progress='--from 
$tasksel_start --to $tasksel_end --logstderr'" || aptfailed

so it looks to me the installed tasksel is used. Which isn't too
surprising anyway since (besides all tasks) src:tasksel ships tasksel
and tasksel-data binaries, which are both (not-u)debs.

>  * Same for question for "dmidecode": could the priority be lowered to
>"standard"?

Looking at all our packages, dmidecode seems to be used by
installation-report (report-hw script), but it could be added to Depends
or Recommends there…

> Some priority changes which I believe could be implemented:

[ I haven't looked at those. ]

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Packages to install be default for Stretch

[Dodie Delosa]

I'm Dodie Delosa you are the ones who did this I'll be in touch 814-550-4318

cron-daemon WAS: Packages to install be default for Stretch

[Geert Stappers]

On Wed, May 06, 2015 at 07:51:57AM +0200, Alexandre Detiste wrote:
> Le mardi 5 mai 2015, 21:02:14 Josh Triplett a écrit :
> > Paul Wise wrote:
> > > On Wed, May 6, 2015 at 2:45 AM, Ansgar Burchardt wrote:
> > > > - cron:
> > > >   Not needed in chroot/container environments.
> > > >   -> demote to "standard"
> > > 
> > > A lot of packages ship cron jobs, I guess this means they will need to
> > > depend on cron?
> 
> They already do.
> 
> > cron was never "Essential: yes", so if a package depended on it for key
> > functionality, it already should have depended on cron. And various packages
> > do.
> >
> > On the other hand, packages optionally enhanced by a cron job could use
> > suggests or recommends.
> 
> Or could better Depends/Recommends/Suggests on "cron-daemon"
> 
> This remind me to dig this mail and ask again
> propermy to complete the migration to "cron-daemon"
> that got started 5 years ago now that Jessie has been released.
> 
> https://lists.debian.org/debian-devel/2014/10/msg00474.html 
>  

Where Russ Allbery says:

| I think this would be a good thing to fix,
| but it's rather late to do this for jessie.


Updating the subject line is what I can do here ...  done.


Groeten
Geert Stappers
-- 
Leven en laten leven


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506063926.gm23...@gpm.stappers.nl

emacsen-common (was: Packages to install be default for Stretch)

[Vincent Lefevre]

On 2015-05-06 11:21:13 +0200, Marco d'Itri wrote:
> dpkg --purge \
>   discover discover-data libdiscover2 installation-report laptop-detect \
>   nano tasksel tasksel-data task-english acpi acpid acpi-support-base \
>   isc-dhcp-client isc-dhcp-common eject \
>   nfacct libmnl0 libnetfilter-acct1 emacsen-common libsigc++-2.0-0c2a \
>   pciutils usbutils libpci3 libusb-1.0-0 \
>   dictionaries-common iamerican ibritish ienglish-common ispell wamerican
> 
> (And I wonder where emacsen-common comes from...)

dictionaries-common dependency:

dictionaries-common (1.23.4) unstable; urgency=low

  * debian/control:
- Depend on (emacsen-common >= 2.0.8) as required by new
  emacsen-common policy. This should not be a problem at all, since
  emacsen-common is now a tiny package. No longer conflict with older
  emacsen-common (Closes: #736572).
- Fix dictionaries-common-dev dependency on dictionaries-common.

 -- Agustin Martin Domingo   Thu, 22 May 2014 12:37:14 
+0200

but I wonder why a policy of package B would dictate a A->B dependency.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150506135954.ga13...@ypig.lip.ens-lyon.fr

Re: emacsen-common (was: Packages to install be default for Stretch)

[Henrique de Moraes Holschuh]

On Wed, May 6, 2015, at 10:59, Vincent Lefevre wrote:
> On 2015-05-06 11:21:13 +0200, Marco d'Itri wrote:
> > dpkg --purge \
> >   discover discover-data libdiscover2 installation-report laptop-detect \
> >   nano tasksel tasksel-data task-english acpi acpid acpi-support-base \
> >   isc-dhcp-client isc-dhcp-common eject \
> >   nfacct libmnl0 libnetfilter-acct1 emacsen-common libsigc++-2.0-0c2a \
> >   pciutils usbutils libpci3 libusb-1.0-0 \
> >   dictionaries-common iamerican ibritish ienglish-common ispell wamerican
> > 
> > (And I wonder where emacsen-common comes from...)
> 
> dictionaries-common dependency:
> 
> dictionaries-common (1.23.4) unstable; urgency=low
> 
>   * debian/control:
> - Depend on (emacsen-common >= 2.0.8) as required by new
>   emacsen-common policy. This should not be a problem at all, since
>   emacsen-common is now a tiny package. No longer conflict with older
>   emacsen-common (Closes: #736572).
> - Fix dictionaries-common-dev dependency on dictionaries-common.
> 
>  -- Agustin Martin Domingo   Thu, 22 May 2014 12:37:14 
> +0200
> 
> but I wonder why a policy of package B would dictate a A->B dependency.

Because package B is one of the target users of the functionality provided by 
package A.

-- 
  "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 de Moraes Holschuh 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1431025670.876648.264132669.02ebd...@webmail.messagingengine.com