Re: Priorities overrides? Extra?

[Philipp Kern]

On 2016-04-10 19:50, Paul Wise wrote:

On Mon, Apr 11, 2016 at 5:49 AM, Philipp Kern wrote:

Maybe it's time to acknowledge that it's mostly busy work at this
point and packages could be authoritative for this kind of information 
(and

handle NEW with a simple list of packages).

I expect the ftpteam will want to put things in NEW when they move
between main/contrib/non-free so a simple list of packages wouldn't be
enough?


Maybe. I'm not sure. main -> {contrib, non-free} could just work. 
Elevating out of non-free would be problematic, of course. This could 
also be implemented as a diff against the current state on import, it 
wouldn't necessarily need to be in a list. But I don't really care. I 
mostly care about sections without components and priorities. ;-)


Kind regards
Philipp Kern

Re: Priorities overrides? Extra?

[Andrey Rahmatullin]

On Sun, Apr 10, 2016 at 10:13:14PM +0200, Ole Streicher wrote:
> >> Question is wich information they cover. For me, "optional" means:
> >> conflict free by policy.
> > You are still mixing two completely separate things.
> Which?
The existence of the override mechanism and the optional vs extra priority
semantics.

> > Changing overrides is a normal procedure.
> For 12.000 packages? Sure, these are less if I leave out oldlibs and
> debug packages, but probably still a few thousands.
We may do this by implementing #759260.

> >> For a field that is -- as you said -- pure informational (and where the
> >> wrong setting could be mentioned just by filing a bug).
> > By saying "informational" I meant that the override value is what matters,
> > not the field in the package.
> So what is the field in the package for?
Well, it sets the initial value of the override. I think ideally it should
be the primary source of this information but we are not there yet and I
don't know if something is done in that direction.

> >> Sure. The problem arises f.e. with my package: it is really special, and
> >> you would not like to install it unless you know what it is for.
> > You should use "optional" for such packages.
> Sure. As there are hundreds of other packages which are in the blends.
Well, either you are considering them buggy or you aren't. In the former
case you may want to fix those bug, in the latter one you don't do
anything with it.

> >> > See also #759260 for discussions about dropping extra completely.
> >> 
> >> I would not drop it completely, since it provides the useful information
> >> "may have conflicts with other packages".
> > I'm not sure who would find this information useful.
> > Note that according to the bug discussion this distinction was caused only
> > by a requirement to be able to co-install all optional packages which is
> > not useful at all.
> 
> "Optional" packages are conflict free by policy. So, if we provide a few
> default installations of Blends via tasksel, we can be sure that there
> will be no conflict, as long as all tasks are Priority "optional".
I'm not sure a task that installs a lot of arbitrarily chosen unrelated
packages is useful either.

> The problem is not to install *all* packages, but to be able to install
> *every* package without the risk of having a conflict (not sure if my
> englisch is good enoough here): how else can I make sure that if someone
> chooses at installation time that he wants to have f.e. "Debian Astro"
> installed, that none of the included packages have conflicts? 
I thought the task of making a distribution out of a bunch of packages
involves more than just running a script that show which packages can be
coinstalled.


> > You can also behave like many packagers do: don't pretend that optional
> > and extra priorities are different and that the policy (still) has
> > different requirements about them. I don't see any downsides with that.
> 
> As I wrote: The distinction is good for things that are done by first
> install. Imagine some newcomer who selects the "Debian Games" pure blend
> during the Debian installation and is then left alone with the
> resolution of package conflicts. I'd call that a desaster.
I don't know how do pure blemnds work but it's obvious to me that this
situation with resolving conflicts should not be possible. But I'm not
sure it's a good idea to just trust priorities for that.


-- 
WBR, wRAR

Re: Priorities overrides? Extra?

[Paul Wise]

On Mon, Apr 11, 2016 at 5:49 AM, Philipp Kern wrote:

> Maybe it's time to acknowledge that it's mostly busy work at this
> point and packages could be authoritative for this kind of information (and
> handle NEW with a simple list of packages).

I expect the ftpteam will want to put things in NEW when they move
between main/contrib/non-free so a simple list of packages wouldn't be
enough?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Priorities overrides? Extra?

[Philipp Kern]

On 2016-04-10 07:08, Ole Streicher wrote:

Jakub Wilk  writes:

* Ole Streicher , 2016-04-10, 14:22:

When I look into the "overrides" file for debian stretch:
http://ftp.debian.org/debian/indices/override.stretch.main.gz
I find there more than 48.000 overrides; which means that almost
*all* packages are overridden.

Exactly _all_ binary packages are in the override file.

Yes, but why?


Because it's an implementation detail of the archive software that NEW 
processing create an override entry for every binary package. The 
presence of the override entry determines if the package is (subject to) 
NEW or not.


It used to be the case that uploads are costly and back then overrides 
were decoupled from the in-package content as it could change more often 
than the package. It might still make sense that there's a possibility 
to bump a package's priority independently from the package. As in, for 
instance: The distribution wants the priority of $library to be higher 
than it usually would be if considered independently ("optional", as for 
almost every other package), mostly because of transitive dependencies. 
But outside of any core set this functionality is rarely used. And I 
think no-one actively tends to override mismatches on the ftp-master 
side. In the end what happens is that people file bugs when the 
mismatches appear on the tracker one way or the other. Maybe it's time 
to acknowledge that it's mostly busy work at this point and packages 
could be authoritative for this kind of information (and handle NEW with 
a simple list of packages).


Kind regards
Philipp Kern

Re: Priorities overrides? Extra?

[Ole Streicher]

Andrey Rahmatullin  writes:
> On Sun, Apr 10, 2016 at 08:34:18PM +0200, Ole Streicher wrote:
>> Question is wich information they cover. For me, "optional" means:
>> conflict free by policy.
> You are still mixing two completely separate things.

Which?

>> > One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
>> > #373603 in 2006 and fixed back by #706164 in 2013.
>> 
>> Yes; this is the reason why I had it in some of my first packages, from
>> where it was copied and pasted to other new packages.
>> 
>> The problem is that I cannot set it back on my own. I have to ask
>> ftp-master and put them more load on their shoulders.
> Changing overrides is a normal procedure.

For 12.000 packages? Sure, these are less if I leave out oldlibs and
debug packages, but probably still a few thousands.

>> For a field that is -- as you said -- pure informational (and where the
>> wrong setting could be mentioned just by filing a bug).
> By saying "informational" I meant that the override value is what matters,
> not the field in the package.

So what is the field in the package for?

>> Sure. The problem arises f.e. with my package: it is really special, and
>> you would not like to install it unless you know what it is for.
> You should use "optional" for such packages.

Sure. As there are hundreds of other packages which are in the blends.

>> > See also #759260 for discussions about dropping extra completely.
>> 
>> I would not drop it completely, since it provides the useful information
>> "may have conflicts with other packages".
> I'm not sure who would find this information useful.
> Note that according to the bug discussion this distinction was caused only
> by a requirement to be able to co-install all optional packages which is
> not useful at all.

"Optional" packages are conflict free by policy. So, if we provide a few
default installations of Blends via tasksel, we can be sure that there
will be no conflict, as long as all tasks are Priority "optional".

The problem is not to install *all* packages, but to be able to install
*every* package without the risk of having a conflict (not sure if my
englisch is good enoough here): how else can I make sure that if someone
chooses at installation time that he wants to have f.e. "Debian Astro"
installed, that none of the included packages have conflicts? If they
were all priority "optional" (and we would file/fix the policy
violations), we could.

Usage by the Debian installer/tasksel is IMO one of the ue cases for the
distinction between "extra" and "optional": If a package is "extra", it
has either the risk of introducing a package conflict, or it is so
special that there is no reason to be installed by a common task.

>> -- either since they are really too special, or since they may have
>> conflicts. So, to get the Debian Blends into the installer, what should
>> I do? 
> See? That's why your package should be priority: optional.

 as thousands other packages. I'd have no problems to file a bug
report for each of these against ftp-masters, but I would like to hear
opinions about that first.

> You can also behave like many packagers do: don't pretend that optional
> and extra priorities are different and that the policy (still) has
> different requirements about them. I don't see any downsides with that.

As I wrote: The distinction is good for things that are done by first
install. Imagine some newcomer who selects the "Debian Games" pure blend
during the Debian installation and is then left alone with the
resolution of package conflicts. I'd call that a desaster.

Best regards

Ole

Re: Priorities overrides? Extra?

[Holger Levsen]

On Mon, Apr 11, 2016 at 12:24:55AM +0500, Andrey Rahmatullin wrote:
> You can also behave like many packagers do: don't pretend that optional
> and extra priorities are different and that the policy (still) has
> different requirements about them. I don't see any downsides with that.

or simply ask the ftp-masters to adopt the overrides as needed. It's a
<1min change and they are happy to maintain that file.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Priorities overrides? Extra?

[Andrey Rahmatullin]

On Sun, Apr 10, 2016 at 08:34:18PM +0200, Ole Streicher wrote:
> > Note that you mix two completely different questions in your email.
> >
> > On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
> >> http://ftp.debian.org/debian/indices/override.stretch.main.gz
> >> 
> >> I find there more than 48.000 overrides; which means that almost *all*
> >> packages are overridden.
> >> 
> >> What is the reason for that? I would expect that overriding is something
> >> exceptional, but not the common way to set the priority?
> > I guess that's an implementation detail of the archive software. Priority
> > fields in the packages are only informational, that's all.
> 
> Question is wich information they cover. For me, "optional" means:
> conflict free by policy.
You are still mixing two completely separate things.

> > One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
> > #373603 in 2006 and fixed back by #706164 in 2013.
> 
> Yes; this is the reason why I had it in some of my first packages, from
> where it was copied and pasted to other new packages.
> 
> The problem is that I cannot set it back on my own. I have to ask
> ftp-master and put them more load on their shoulders.
Changing overrides is a normal procedure.

> For a field that is -- as you said -- pure informational (and where the
> wrong setting could be mentioned just by filing a bug).
By saying "informational" I meant that the override value is what matters,
not the field in the package.

> > Yet another one is the bad policy wording about "likely to be useful
> > if you already know what they are" (see #660249 about dropping that).
> Sure. The problem arises f.e. with my package: it is really special, and
> you would not like to install it unless you know what it is for.
You should use "optional" for such packages.

> > See also #759260 for discussions about dropping extra completely.
> 
> I would not drop it completely, since it provides the useful information
> "may have conflicts with other packages".
I'm not sure who would find this information useful.
Note that according to the bug discussion this distinction was caused only
by a requirement to be able to co-install all optional packages which is
not useful at all.

> My problem here is that, according to the policy, no "extra" programs
> should be installed by the Debian installer
I don't think the policy says or means anything about the Debian
installer.

> -- either since they are really too special, or since they may have
> conflicts. So, to get the Debian Blends into the installer, what should
> I do? 
See? That's why your package should be priority: optional.

> I could create bugs for all affected packages (of the blends, and their
> dependencies), which would end up in maybe 1000 bug reports (or commits,
> if they are team maintained). However, at some point I would have to ask
> the ftp-masters to change all these priorities, and I am not sure
> whether they are too happy with it.
You can also behave like many packagers do: don't pretend that optional
and extra priorities are different and that the policy (still) has
different requirements about them. I don't see any downsides with that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Priorities overrides? Extra?

[Ole Streicher]

Andrey Rahmatullin  writes:
> Note that you mix two completely different questions in your email.
>
> On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
>> http://ftp.debian.org/debian/indices/override.stretch.main.gz
>> 
>> I find there more than 48.000 overrides; which means that almost *all*
>> packages are overridden.
>> 
>> What is the reason for that? I would expect that overriding is something
>> exceptional, but not the common way to set the priority?
> I guess that's an implementation detail of the archive software. Priority
> fields in the packages are only informational, that's all.

Question is wich information they cover. For me, "optional" means:
conflict free by policy.

> One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
> #373603 in 2006 and fixed back by #706164 in 2013.

Yes; this is the reason why I had it in some of my first packages, from
where it was copied and pasted to other new packages.

The problem is that I cannot set it back on my own. I have to ask
ftp-master and put them more load on their shoulders. For a field that
is -- as you said -- pure informational (and where the wrong setting
could be mentioned just by filing a bug).

> Yet another one is the bad policy wording about "likely to be useful
> if you already know what they are" (see #660249 about dropping that).

Sure. The problem arises f.e. with my package: it is really special, and
you would not like to install it unless you know what it is for.

However, it is an dependency of other programs, and they are *not*
special anymore. But by policy they would be required to be "extra" as
well.

> See also #759260 for discussions about dropping extra completely.

I would not drop it completely, since it provides the useful information
"may have conflicts with other packages". I would just like to see how
we can get back to get it useful and how we can people take it seriously.

My problem here is that, according to the policy, no "extra" programs
should be installed by the Debian installer -- either since they are
really too special, or since they may have conflicts. So, to get the
Debian Blends into the installer, what should I do? I could create bugs
for all affected packages (of the blends, and their dependencies), which
would end up in maybe 1000 bug reports (or commits, if they are team
maintained). However, at some point I would have to ask the ftp-masters
to change all these priorities, and I am not sure whether they are too
happy with it.

Best regards

Ole

Re: Priorities overrides? Extra?

[Ole Streicher]

Andrey Rahmatullin  writes:
> Note that you mix two completely different questions in your email.
>
> On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
>> http://ftp.debian.org/debian/indices/override.stretch.main.gz
>> 
>> I find there more than 48.000 overrides; which means that almost *all*
>> packages are overridden.
>> 
>> What is the reason for that? I would expect that overriding is something
>> exceptional, but not the common way to set the priority?
> I guess that's an implementation detail of the archive software. Priority
> fields in the packages are only informational, that's all.

Question is wich information they cover. For me, "optional" means:
conflict free by policy.

> One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
> #373603 in 2006 and fixed back by #706164 in 2013.

Yes; this is the reason why I had it in some of my first packages, from
where it was copied and pasted to other new packages.

The problem is that I cannot set it back on my own. I have to ask
ftp-master and put them more load on their shoulders. For a field that
is -- as you said -- pure informational (and where the wrong setting
could be mentioned just by filing a bug).

> Yet another one is the bad policy wording about "likely to be useful
> if you already know what they are" (see #660249 about dropping that).

Sure. The problem arises f.e. with my package: it is really special, and
you would not like to install it unless you know what it is for.

However, it is an dependency of other programs, and they are *not*
special anymore. But by policy they would be required to be "extra" as
well.

> See also #759260 for discussions about dropping extra completely.

I would not drop it completely, since it provides the useful information
"may have conflicts with other packages". I would just like to see how
we can get back to get it useful and how we can people take it seriously.

My problem here is that, according to the policy, no "extra" programs
should be installed by the Debian installer -- either since they are
really too special, or since they may have conflicts. So, to get the
Debian Blends into the installer, what should I do? I could create bugs
for all affected packages (of the blends, and their dependencies), which
would end up in maybe 1000 bug reports (or commits, if they are team
maintained). However, at some point I would have to ask the ftp-masters
to change all these priorities, and I am not sure whether they are too
happy with it.

Best regards

Ole

Re: Priorities overrides? Extra?

[Andrey Rahmatullin]

Note that you mix two completely different questions in your email.

On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
> http://ftp.debian.org/debian/indices/override.stretch.main.gz
> 
> I find there more than 48.000 overrides; which means that almost *all*
> packages are overridden.
> 
> What is the reason for that? I would expect that overriding is something
> exceptional, but not the common way to set the priority?
I guess that's an implementation detail of the archive software. Priority
fields in the packages are only informational, that's all.

> Looking into the priorities, I found:
> 
>  66 required
>  64 important
>  86 standard
>   34854 optional
>   13191 extra
> 
> which means that almost one third of the packages is priority
> "extra". From the policy, I would expect that the main reasons to give
> the priority "extra" are either a conflict with another package, or the
> dependency on a package with priority "extra".
One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
#373603 in 2006 and fixed back by #706164 in 2013. Yet another one is the
bad policy wording about "likely to be useful if you already know what
they are" (see #660249 about dropping that).

See also #759260 for discussions about dropping extra completely.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Priorities overrides? Extra?

[Ole Streicher]

Santiago Vila  writes:
> On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
>> What is the idea behind the current structure?
>
> It all depends on what you call "specialized requirements".
>
> Unless we rely on popcon to decide what's special and what's not,
> this will remain very subjective.
>
> IMHO, we could well get rid of the "special requirements" thing and
> make "optional" maximally useful by raising as many packages as we can
> from extra to optional.
>
> The only rule which is currently useful is the "no conflicts between
> optional packages". This has also the good property of being objective.

Ack. This would mark 12.000 more packages as "optional". Why don't we do
that?

Best regards

Ole

Re: Priorities overrides? Extra?

[Santiago Vila]

On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:

> What is the idea behind the current structure?

It all depends on what you call "specialized requirements".

Unless we rely on popcon to decide what's special and what's not,
this will remain very subjective.

IMHO, we could well get rid of the "special requirements" thing and
make "optional" maximally useful by raising as many packages as we can
from extra to optional.

The only rule which is currently useful is the "no conflicts between
optional packages". This has also the good property of being objective.

Thanks.

Re: Priorities overrides? Extra?

[Ole Streicher]

Jakub Wilk  writes:
> * Ole Streicher , 2016-04-10, 14:22:
>>When I look into the "overrides" file for debian stretch:
>>
>>http://ftp.debian.org/debian/indices/override.stretch.main.gz
>>
>> I find there more than 48.000 overrides; which means that almost
>> *all* packages are overridden.
>
> Exactly _all_ binary packages are in the override file.

Yes, but why?

> That doesn't mean that that every single package had their priority or
> section actually changed.

But I repeatedly experienced that when I change the priority in the
package, it is not changed in the archive. liberfa1 is an example here.

Probably the most common case is like this one: the priority in the
package changed, but the overrides file keeps it at the old value, so
they actually differ. What is the use of this? Why can't I change the
Priority of my packages on my own? This seems to make a change
extra->optional unnecessarily complicated, and involves the
always-overloaded ftp-master in a process where I don't see a policy
risk.

Best regards

Ole

Re: Priorities overrides? Extra?

[Jakub Wilk]

* Ole Streicher , 2016-04-10, 14:22:

When I look into the "overrides" file for debian stretch:

http://ftp.debian.org/debian/indices/override.stretch.main.gz

I find there more than 48.000 overrides; which means that almost *all* 
packages are overridden.


Exactly _all_ binary packages are in the override file.

That doesn't mean that that every single package had their priority or 
section actually changed.


--
Jakub Wilk

Re: priorities

[Michael Banck]

On Mon, Dec 10, 2007 at 05:38:50PM +0100, Marc 'HE' Brockschmidt wrote:
> Anthony Towns <[EMAIL PROTECTED]> writes:
> > Priority: standard currently contains:
> >
> > at, bc, dc, lsof, file, less, sharutils, strace
> > dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois
> > doc-debian, doc-linux-text
> > exim, mailx, mutt, procmail, mime-support, mpack
> > gettext-base, locales
> > pciutils
> > perl (not just perl-base), python
> > reportbug
> > selinux policy
> >
> > That seems a pretty reasonable set of functionality to put on all Debian
> > boxes (unless the admin specifically says otherwise), afaics.
> 
> Well, moving away from exim to nullmailer or something like that has
> been discussed a few times. procmail is pretty weird in there, as only
> few people still use procmail. Just like w3m or mutt - those may look
> reasonable for a Unix admin, but a standard user will never touch them.

I think we should move most of that into a "Unix" (or "GNU" or whatever)
task, that old-timers can install.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Marc 'HE' Brockschmidt]

Anthony Towns <[EMAIL PROTECTED]> writes:
> On Sun, Nov 11, 2007 at 07:12:35PM +0100, Marc 'HE' Brockschmidt wrote:
>> I believe it to be one of the more important bits of a standard Unix
>> *desktop* installation - but this just reminds me of the fact that I'm
>> quite uncomfortable with keeping a system like package priorities around
>> for much longer. Diverging use-cases (like in this case) show that one
>> definition of "standard" isn't really helpful anymore.
> Haven't we more or less already moved away from priorities as meaning
> anything particularly important?

Yes, but we still enforce the formal requirements.

> We have:
>
>   required/essential -- stuff that can't be removed: libc, dpkg, etc
>   important -- the rest of base, stuff necessary to bootstrap and
>   recover a usable and useful system

I have to admit that I don't see why we can't merge those two. At the
moment, these packages are in required without being marked as
essential:
debconf debconf-i18n dselect e2fslibs gcc-4.2-base initscripts libacl1
libattr1 libblkid1 libc6 libcap1 libcomerr2 libdb4.3 libdevmapper1.02.1
libgcc1 liblocale-gettext-perl libncurses5 libpam-modules libpam-runtime
libpam0g libselinux1 libsepol1 libslang2 libss2 libstdc++6
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libuuid1
lsb-base makedev mawk passwd procps sysv-rc tzdata zlib1g

I don't see what makes those required-but-not-important or why the
packages in important aren't required.

>   optional -- all the good software in the world
>   extra -- obscure stuff
>
> All the really important questions are which bits of "optional" (and
> occassionally extra) are useful for a given user.
>
> I'm not sure if there's any point to continuing to try to make sure that
> nothing >= optional conflicts with anything else >= optional.

I don't see the point of doing that anymore. On i386, sid has 3123
packages in extra and 18178 in optional. The policy says "This is all
the software that you might reasonably want to install if you didn't
know what it was and don't have specialized requirements. This is a much
larger system and includes the X Window System, a full TeX distribution,
and many applications." about optional. Over 18000 binary packages don't
sound like that.

> Priority: standard currently contains:
>
>   at, bc, dc, lsof, file, less, sharutils, strace
>   dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois
>   doc-debian, doc-linux-text
>   exim, mailx, mutt, procmail, mime-support, mpack
>   gettext-base, locales
>   pciutils
>   perl (not just perl-base), python
>   reportbug
>   selinux policy
>
> That seems a pretty reasonable set of functionality to put on all Debian
> boxes (unless the admin specifically says otherwise), afaics.

Well, moving away from exim to nullmailer or something like that has
been discussed a few times. procmail is pretty weird in there, as only
few people still use procmail. Just like w3m or mutt - those may look
reasonable for a Unix admin, but a standard user will never touch them.

Marc
-- 
BOFH #339:
manager in the cable duct


pgp4yq3ijQjJV.pgp
Description: PGP signature

Re: priorities (was: Re: RFC: cups as "default" printing system for lenny?)

[Agustin Martin]

On Fri, Dec 07, 2007 at 12:01:43AM +1000, Anthony Towns wrote:
> Kind of reviving an old thread, but anyway:
> It also includes, but afaics, probably doesn't need to (anymore):
> 
>   ispell, dictionaries-common, iamerican, ibritish, wamerican

#416572: ibritish: Should not have priority standard 

Only wamerican was originally intended for standard, because former
wamerican maintainer considered that a basic english wordlist should be
present in a system. dictionaries-common is standard only because is
needed by wamerican. I have been thinking at various ways to lower
the standard size, but am still undecided about the best choice, if
wamerican is to remain standard.

a) Splitting a new 'dictionaries-common-base' package containing
   things meant only for wordlists (and so for wamerican) and some
   things that are better here for simplicity.  
b) Having a wamerican-standard package that is the same as normal
   wamerican, but without the dictionaries-common integration stuff.
   With proper conflicts/provides wamerican would replace it as soon
   as another wordlist or an ispell/myspell/aspell dict is installed.

Still need to make some tests about this.

-- 
Agustin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[NN_il_Confusionario]

On Fri, Dec 07, 2007 at 07:28:22PM +1000, Anthony Towns wrote:
> both required and base in the same list, so you have to look for the split
> yourselve (zlibg1 and adduser atm), but that's not too hard hopefully.

Yes it is not _hard_, but it is exactly this sort of dependency hunting
that is uselessy time consuming, since for each _released_ debian (etch,
sarge, woody, ...) such a list is fixed and "already known"; having to
rediscover it each time is not the smartest thing.

In pratice, the fastest solution for me has been up to now to use
debootstrap, then install deborphan in the chroot to purge things. And
finally a tar of the "essential" chroot (without
var/cache/apt/archives/*.deb var/lib/apt/lists/*_{Release,Packages} and
so on). But then Murphy assures that sooner or later you will need a new
architecture or a new release or to install a machine without access to
the machine where the tar is saved ...

However, many tanks for your patch.

-- 
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Anthony Towns]

On Fri, Dec 07, 2007 at 08:25:05AM +0100, NN_il_Confusionario wrote:
> Question: is there somewhere on the net a script (*) such that:
> * it installs required/essential packages (_all_ of them but _only_
>   them) of such a release as a chroot in that directory

You could create a variant for debootstrap. That's not very hard,
depending on your mood:

# cp /usr/share/debootstrap/scripts/sid my-sid
# patch  Every time I do someting like that, too much time is spent for
> dependency hunting. Ad every time I forget to save the list of packages :-(

debootstrap --print-debs will give you a list of packages. It includes
both required and base in the same list, so you have to look for the split
yourselve (zlibg1 and adduser atm), but that's not too hard hopefully.

Cheers,
aj



signature.asc
Description: Digital signature

Re: priorities

[Anthony Towns]

On Thu, Dec 06, 2007 at 11:03:08PM -0600, Manoj Srivastava wrote:
> Frankly, I suggest we look at the list of Unix commands as
>  specified by the SUS -- which can also be seen at:
>http://en.wikipedia.org/wiki/List_of_Unix_programs
> So -- how many of the standard unix commands as defined by that
>  page are not part of the standard section?

I guess one of the the things I wonder every now and then
is whether we really should be keeping standard as implying a
... traditional/historical/whatever Unix system, with pr and lpr and tcsh
and bc and dc and whatever else that people would traditionally expect,
instead of moving them to a task that can be installed only by people
who actually know what they are, and then making sure we provide a real
Unix system in that case. But by the looks of things there's still not
much need for a change there, at least at this point.

Cheers,
aj



signature.asc
Description: Digital signature

Re: priorities

[NN_il_Confusionario]

On Fri, Dec 07, 2007 at 04:37:57PM +0900, Michal ??iha?? wrote:
> On Fri, 7 Dec 2007 08:25:05 +0100
> NN_il_Confusionario <[EMAIL PROTECTED]> wrote:
> > * it installs required/essential packages (_all_ of them but _only_
> >   them) of such a release as a chroot in that directory
> Isn't minimal flavour in cdeboostrap doing this?

the man page says:

   minimal
  Installs  essential and apt. 

so it should do _almost_ what I asked, but not exactly: at least apt and
its dependencies are added to dpkg and its dependencies.

-- 
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Michal Čihař]

Hi

On Fri, 7 Dec 2007 08:25:05 +0100
NN_il_Confusionario <[EMAIL PROTECTED]> wrote:

> Question: is there somewhere on the net a script (*) such that:
> 
> * it accepts two parameters: a debian release (etch, sarge, woody, ...)
>   and an (empty) directory;
> 
> * it installs required/essential packages (_all_ of them but _only_
>   them) of such a release as a chroot in that directory
> 
> ? [Mybe also a third parameter will be useful, the architecture]
> 
> (*) complete and explicit lists to use with debootstrap are a solution.
> (debootstrap by default installs quite more than really
> required/essential packages).
> 
> Every time I do someting like that, too much time is spent for
> dependency hunting. Ad every time I forget to save the list of packages :-(

Isn't minimal flavour in cdeboostrap doing this? So the script would
be: "cdebootstrap -f minimal sid /tmp/foobar".

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: priorities

[NN_il_Confusionario]

On Thu, Dec 06, 2007 at 10:26:11AM -0600, Manoj Srivastava wrote:
> On Fri, 7 Dec 2007 00:01:43 +1000, Anthony Towns <[EMAIL PROTECTED]> said: 
> > * required/essential -- stuff that can't be removed: libc, dpkg,etc
> 
> Packages which are required to be present for the packaging
>  system to be able to install additional packages.  This means dpkg and
>  everything dpkg itself needs

Question: is there somewhere on the net a script (*) such that:

* it accepts two parameters: a debian release (etch, sarge, woody, ...)
  and an (empty) directory;

* it installs required/essential packages (_all_ of them but _only_
  them) of such a release as a chroot in that directory

? [Mybe also a third parameter will be useful, the architecture]

(*) complete and explicit lists to use with debootstrap are a solution.
(debootstrap by default installs quite more than really
required/essential packages).

Every time I do someting like that, too much time is spent for
dependency hunting. Ad every time I forget to save the list of packages :-(

-- 
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Yves-Alexis Perez]

On jeu, 2007-12-06 at 23:11 +0100, Bernd Zeimetz wrote:
> Although csh is the standard on a lot of systems, including OSX

OSX uses bash by default since Panther (10.3).
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Manoj Srivastava]

On Fri, 7 Dec 2007 12:28:55 +1000, Anthony Towns <[EMAIL PROTECTED]> said: 

> On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote:
>> On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]>
>> said:
>> > I use "time" in benchmarking scripts.
>> I do not find the built in time to be a substitute for the good old
>> fashioned time command. Observe:

> Why are either of those reasons to have /usr/bin/time on every Debian
> machine? We're not talking about removing the package entirely...

The passage you are quoting is not meant to offer justification
 for keeping time in standard. It was meant to refure the statement that
 time is now a builtin in most shells.

The point I am making is that the built in command of the same
 name as /usr/bin/time is a pale shade of the original, and in no way an
 adequate substitute.

Now, the justification is that it has always been a part of
 UNIX, as far back I I can remember (Which means about '83 -- though I
 honestly only recall the executable /usr/bin/time on Ultrix, circa
 '88).

Frankly, I suggest we look at the list of Unix commands as
 specified by the SUS -- which can also be seen at:
   http://en.wikipedia.org/wiki/List_of_Unix_programs

From that page, time has been in UNIX since AT&T version 3.

So -- how many of the standard unix commands as defined by that
 page are not part of the standard section?

manoj
-- 
The difference between genius and stupidity is that genius has its
limits.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Ben Pfaff]

Anthony Towns <[EMAIL PROTECTED]> writes:

> On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote:
>> On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]> said: 
>> > I use "time" in benchmarking scripts. 
>> I do not find the built in time to be a substitute for the good
>>  old fashioned time command. Observe:
>
> Why are either of those reasons to have /usr/bin/time on every Debian
> machine? We're not talking about removing the package entirely...

It's hard for me to believe that a standard Unix utility should
not be in "standard" or perhaps even in "important".  As policy
says about the "important" priority, "we are trying to produce,
amongst other things, a free Unix."

But, as with almost every other program, if it's not installed, I
can install it quickly and conveniently, so it's frankly not
worth much arguing either way from my point of view.
-- 
Ben Pfaff 
http://benpfaff.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Anthony Towns]

On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote:
> On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]> said: 
> > I use "time" in benchmarking scripts. 
> I do not find the built in time to be a substitute for the good
>  old fashioned time command. Observe:

Why are either of those reasons to have /usr/bin/time on every Debian
machine? We're not talking about removing the package entirely...

(For comparison: nc/telnet are basic diagnostic tools to investigate why
you can't run apt-get, reportbug, an email program and a web browser are
needed for contacting remote humans if you get into problems installing
or recovering a Debian system)

Cheers,
aj



signature.asc
Description: Digital signature

Re: priorities

[Ben Pfaff]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]> said: 
>
>> I use "time" in benchmarking scripts. 
>
> I do not find the built in time to be a substitute for the good
>  old fashioned time command.  [...]

Which is one reason why I wrote the above, in support of keeping
"time" at Priority: standard.  Perhaps I was not explicit enough.
-- 
Ben Pfaff 
http://benpfaff.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Manoj Srivastava]

On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]> said: 

> I use "time" in benchmarking scripts. 

I do not find the built in time to be a substitute for the good
 old fashioned time command. Observe:

__> time sleep 20
Real: 20.03s User: 0.00s System: 0.00s Percent: 0% Cmd: sleep 20
__> /usr/bin/time sleep 20
0.00user 0.00system 0:20.01elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+188minor)pagefaults 0swaps
__> time -v sleep 2   
zsh: command not found: -v
[3]4136 exit 127   -v sleep 2
Real: 0.00s User: 0.00s System: 0.00s Percent: 0% Cmd: -v sleep 2
__> /usr/bin/time -v sleep 2
Command being timed: "sleep 2"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.00
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 0
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 192
Voluntary context switches: 3
Involuntary context switches: 0
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

manoj
-- 
Men never make passes at girls wearing glasses. Dorothy Parker
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Russ Allbery]

Bernd Zeimetz <[EMAIL PROTECTED]> writes:

>> Having a /bin/csh falls into "present on all Unix systems and likely to
>> provoke WTF reactions if not there."  Also, I'm pretty sure that tcsh
>> is very comfortably the second-most-used interactive shell, way ahead
>> of zsh, on Linux systems.

> Although csh is the standard on a lot of systems, including OSX, it is
> 'bashed' for being bad in Debian's policy. But I wanted to send a bug
> about that anyway...

It should be bashed for scripting.  It's a horrible scripting shell with a
bunch of problems, starting with but not limited to its I/O redirection
support.

Interactive shells have different needs, though, and Policy doesn't say
anything about using csh as an interactive shell that I'd seen (if I'm
wrong, please do point it out).

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Bernd Zeimetz]

> Having a /bin/csh falls into "present on all Unix systems and likely to
> provoke WTF reactions if not there."  Also, I'm pretty sure that tcsh is
> very comfortably the second-most-used interactive shell, way ahead of
> zsh, on Linux systems.

Although csh is the standard on a lot of systems, including OSX, it is
'bashed' for being bad in Debian's policy. But I wanted to send a bug
about that anyway...

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Ben Pfaff]

"brian m. carlson" <[EMAIL PROTECTED]> writes:

> On Fri, Dec 07, 2007 at 04:51:29AM +1000, Anthony Towns wrote:
>>On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote:
>>> Anthony Towns <[EMAIL PROTECTED]> writes:
>>> >   time (???)
>>> Likewise.  time is a standard Unix program.
>>
>>And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly
>>useful most of the time... (not dash though)
>
> I've never seen anyone use either dash or posh as their default shell,
> and IME time is only used in interactive shells, so this might not be
> that important.  IMHO it could be relegated to optional.

I use "time" in benchmarking scripts.
-- 
Ben Pfaff 
http://benpfaff.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[brian m. carlson]

On Fri, Dec 07, 2007 at 04:51:29AM +1000, Anthony Towns wrote:

On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote:

Anthony Towns <[EMAIL PROTECTED]> writes:
>time (???)
Likewise.  time is a standard Unix program.


And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly
useful most of the time... (not dash though)


I've never seen anyone use either dash or posh as their default shell, 
and IME time is only used in interactive shells, so this might not be 
that important.  IMHO it could be relegated to optional.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: priorities

[Russ Allbery]

Anthony Towns <[EMAIL PROTECTED]> writes:
> On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote:

>>> tcsh (people who remember what it is know how to install it)

>> Having a /bin/csh falls into "present on all Unix systems and likely to
>> provoke WTF reactions if not there."  

> Which isn't a requirement for "standard", but hey...

Yeah, it's the definition of important, and I could make an argument that
having /bin/csh in important would be justified.  But on the other hand,
it's bad for scripting and probably should generally be discouraged, so.
Standard seems like a reasonable compromise.  :)

> I find it pretty surprising that somewhere between 1 in 8 systems
> (vote/max(inst)) and 1 in 5 systems ((vote+old)/vote) still have tcsh
> used recently tbh.

Up until fairly recently, it was the only interactive shell with decent
programmable completion other than zsh.  (bash's has been substandard
compared to tcsh for many years, although I think in recent years it's
gotten a lot closer.)  And zsh is a little intimidating to get started
with.

I still use tcsh as an interactive shell in large part because I can't
figure out how to duplicate certain behaviors that my fingers are very
used to in bash, although it's probably possible at this point.  bash used
to have a hard time with stuff like:

complete pubswtrawl 'n%--recheck%D:/afs/.ir/pubsw/ADMIN/links/%'
complete cvs 'p/1/(add commit diff log remove status update)/'

>> >time (???)
>> Likewise.  time is a standard Unix program.

> And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly
> useful most of the time... (not dash though)

True.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Anthony Towns]

On Thu, Dec 06, 2007 at 10:26:11AM -0600, Manoj Srivastava wrote:
> > I'm not sure if there's any point to continuing to try to make sure
> > that nothing >= optional conflicts with anything else >= optional.
> Hmm.  Can you elaborate on this, please? Is it because it is too
>  hard to achieve this? Or you think this is something unattainable even
>  in theory? It is a nice invariant, if only we could get it to hold for
>  Debian.

I don't have any statistics to back the following up.

I don't think we have been doing it very thoroughly for years now, so
at best it's something that's often true, but not always (eg, there's
only one mail-transport-agent of priority optional or higher -- except
there's actually three: exim4-daemon-light (standard), exim4-daemon-heavy
and nbsmtp).

It requires us to choose a winner amongst similar packages that use
Conflicts instead of alternatives, when really we'd rather leave that
up to our users (or people maintaining derivative distros, or tasksel
or whatever).

I don't think it serves an actual point -- back in the day saying "install
everything of priority optional or above" was a feasible way of getting
a really powerful and useful Debian system. That's not really plausible
anymore thanks to the sheer amount of software.

> > optional -- all the good software in the world
> > extra -- obscure stuff
> If we are removing the invariant that everything in optional
>  should not conflict with anything else in optional, and extra is where
>  the conflicing packages go, is there any reason to retain extra as a
>  distinct section?

Being able to classify software as "Unless you have a really special need,
you don't want this" still seems somewhat useful to me. I also somewhat
like the idea of having your average free software package in main at
a higher priority than your average non-free software package.

Cheers,
aj


signature.asc
Description: Digital signature

Re: priorities

[Anthony Towns]

On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote:
> Anthony Towns <[EMAIL PROTECTED]> writes:
> > It also includes, but afaics, probably doesn't need to (anymore):
> > ispell, dictionaries-common, iamerican, ibritish, wamerican
> > m4, texinfo (???)
> texinfo possibly for info and dating from the days of needing to have an
> info reader to get real documentation for many of the GNU tools?

But texinfo only includes:
/usr/bin/texi2pdf
/usr/bin/texindex
/usr/bin/texi2dvi
/usr/bin/ginstall-info
/usr/bin/makeinfo

The info browser is in the info package (which is priority:important)...

> > mtools (access unmounted msdos filesystems, not NTFS though)
> Probably obsolete at this point.

> > pidentd (is IDENT still used on today's internet, with all its NAT?)
> > openbsd-inetd  (needed by pidentd)
> identd is still used somewhat, mostly with IRC, but it's almost certainly
> optional rather than standard.

> > tcsh (people who remember what it is know how to install it)
> Having a /bin/csh falls into "present on all Unix systems and likely to
> provoke WTF reactions if not there."  

Which isn't a requirement for "standard", but hey...

> Also, I'm pretty sure that tcsh is
> very comfortably the second-most-used interactive shell, way ahead of
> zsh, on Linux systems.

#rank nameinst  vote   old recent no-files
2 bash   69802 58316  2596  8885 5
305   mailx  62713 16369 30995 15343 6
438   tcsh   60057  9042 37123 13886 6
488   mutt   59151  7662 32588 18895 6
555   mtools 60985  6035 40222 14723 5
570   reportbug  61436  5780 40836 14816 4
588   time   61236  5539 41423 14267 7
885   dash   11100  2615  7604   876 5 
1014  zsh 3801  2002  1366   431 2

Of course, there's half a zillion different zsh packages that should have
their stats combined, but whatever.

I find it pretty surprising that somewhere between 1 in 8 systems
(vote/max(inst)) and 1 in 5 systems ((vote+old)/vote) still have tcsh
used recently tbh.

> > time (???)
> Likewise.  time is a standard Unix program.

And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly
useful most of the time... (not dash though)

Cheers,
aj



signature.asc
Description: Digital signature

Re: priorities

[Manoj Srivastava]

On Fri, 7 Dec 2007 00:01:43 +1000, Anthony Towns <[EMAIL PROTECTED]> said: 

> Haven't we more or less already moved away from priorities as meaning
> anything particularly important? We have:

> * required/essential -- stuff that can't be removed: libc, dpkg,etc

Packages which are required to be present for the packaging
 system to be able to install additional packages.  This means dpkg and
 everything dpkg itself needs; if these packages are gone, the system
 can't repair itself, and can not move to a more tenable state.

> * important -- the rest of base, stuff necessary to bootstrap
>   and recover a usable and useful system

The subset of the OS required to boot and be able to install
 further packages. Note that just required packages might not constitue
 a bootable system.

> * standard -- a minimal collection of useful stuff we'd like to
>   see on every Debian system

> optional -- all the good software in the world
> extra -- obscure stuff

If we are removing the invariant that everything in optional
 should not conflict with anything else in optional, and extra is where
 the conflicing packages go, is there any reason to retain extra as a
 distinct section?

> I'm not sure if there's any point to continuing to try to make sure
> that nothing >= optional conflicts with anything else >= optional.

Hmm.  Can you elaborate on this, please? Is it because it is too
 hard to achieve this? Or you think this is something unattainable even
 in theory? It is a nice invariant, if only we could get it to hold for
 Debian.

manoj
-- 
Hacking's just another word for nothing left to kludge.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: priorities

[Russ Allbery]

Anthony Towns <[EMAIL PROTECTED]> writes:

> It also includes, but afaics, probably doesn't need to (anymore):
>
>   ispell, dictionaries-common, iamerican, ibritish, wamerican
>   m4, texinfo (???)

texinfo possibly for info and dating from the days of needing to have an
info reader to get real documentation for many of the GNU tools?

>   mtools (access unmounted msdos filesystems, not NTFS though)

Probably obsolete at this point.

>   nfs-common, portmap (enables mounting NFS shares)
>   pidentd (is IDENT still used on today's internet, with all its NAT?)
>   openbsd-inetd  (needed by pidentd)

identd is still used somewhat, mostly with IRC, but it's almost certainly
optional rather than standard.

>   tcsh (people who remember what it is know how to install it)

Having a /bin/csh falls into "present on all Unix systems and likely to
provoke WTF reactions if not there."  Also, I'm pretty sure that tcsh is
very comfortably the second-most-used interactive shell, way ahead of
zsh, on Linux systems.

Lots of us old-timers haven't made the leap for our interactive shell
yet.  :)  And it's probably more common among the average user than among
DDs, since DDs are more likely to be interested in playing with the latest
and greatest stuff.

>   time (???)

Likewise.  time is a standard Unix program.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]