t; I think that it explains better the role of these priorities. By the
> way, in the current Policy, the specifications of what the base system
> provides are scattered across the document. I am tempted to open a bug
> about reorganising this for the version 4.0 of the Policy. Do you thi
us important pacakges. With this
patch, we have the nice definition that "required" implements the "essential"
part, and "important" implements the rest of the base. I think that it
explains better the role of these priorities. By the way, in the current
Policy, the
Julien Cristau wrote:
> - debconf-i18n, liblocale-gettext-perl, libtext-charwidth-perl,
> libtext-iconv-perl, libtext-wrapi18n-perl: since debconf 1.5.39 -i18n
> is only a Recommends. Could probably be downgraded to important?
I think so. [1] has some context.
> - mawk: one of the alternat
Jonathan Nieder writes:
> diff --git i/policy.sgml w/policy.sgml
> index 52dbb26a..544308f8 100644
> --- i/policy.sgml
> +++ w/policy.sgml
> @@ -757,16 +757,11 @@
>
> required
>
> - Packages which are necessary for the proper
> - functioning o
Julien Cristau writes:
> As far as I can tell the following packages are Priority: required but
> not Essential: yes (in sid/amd64/main), or (pre-)depended on by an
> Essential package (possibly recursively):
> - debconf-i18n, liblocale-gettext-perl, libtext-charwidth-perl,
> libtext-iconv-per
On Tue, Jul 10, 2012 at 15:31:52 -0700, Russ Allbery wrote:
> Could someone who has the time to put together a script for this check to
> see whether this is actually true? (Namely, that the only thing in
> required are essential packages and their dependencies.)
>
As far as I can tell the follo
Jonathan Nieder writes:
> It still sounds like work, so let's abandon that part of the proposal.
> Maybe we can prepare for it with the following, though?
> @@ -757,16 +757,11 @@
>
> required
>
> - Packages which are necessary for the proper
> -
Charles Plessy wrote:
> Le Tue, Jul 10, 2012 at 01:20:19PM -0500, Jonathan Nieder a écrit :
>> Charles Plessy wrote:
>>> deprecating
>>> either the required or important priority would not render packages buggy
>>> just
>>> for that
Le Tue, Jul 10, 2012 at 01:20:19PM -0500, Jonathan Nieder a écrit :
> Charles Plessy wrote:
>
> > Given that the Priority field in the debian source control file is used only
> > once, when the package is first uploaded to the Debian archive, deprecating
> > either the required or important priori
Charles Plessy wrote:
> Given that the Priority field in the debian source control file is used only
> once, when the package is first uploaded to the Debian archive, deprecating
> either the required or important priority would not render packages buggy just
> for that fact.
Are you referring to
Le Sun, Jul 08, 2012 at 07:52:05PM -0500, Jonathan Nieder a écrit :
>
> In practice, my impression is that "required" usually just means
> pseudo-essential (that is, essential packages and their transitive
> dependencies). Is that impression correct? Would it be worth
> documenting?
>
> A part
Hi Robert,
In 2007, Robert Millan wrote:
> In the definition of priorities, "required" and "important" seem to collide
> with each other. In particular, the part of "required" that reads:
>
> "Packages which are necessary for the proper
On Mon, Dec 10, 2007 at 05:38:50PM +0100, Marc 'HE' Brockschmidt wrote:
> > 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 admi
[Anthony Towns]
> 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
[Agustin Martin]
> #416572: ibritish: Should not have priority standard
We now have aspell, my
>> 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 fro
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 standa
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
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 th
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 tim
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:
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
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
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.
> Alt
> 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, i
"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
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 terr
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."
> Wh
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 achi
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 a
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
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
mfortable 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
On Thu, Nov 22, 2007 at 07:41:10PM +0100, Kurt Roeckx wrote:
> On Thu, Nov 22, 2007 at 04:00:28PM +0100, Robert Millan wrote:
> > Unlike "required", "important" may include packages following other
> > conditions not related to this one (and in fact, most of them aren't), so
> > my proposal is to c
Package: debian-policy
Version: 3.7.2.2
Severity: wishlist
Tags: patch
In the definition of priorities, "required" and "important" seem to collide
with each other. In particular, the part of "required" that reads:
"Packages which are necessary for the prop
On Fri, May 18, 2001 at 11:06:53AM -0400, Adam Di Carlo wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> > Current policy says:
> >
> > <-- snip -->
> >
> > `standard'
> > These packages provide a reasonably small but not too limited
> > character-mode system. Thi
Adrian Bunk <[EMAIL PROTECTED]> writes:
> Current policy says:
>
> <-- snip -->
>
> `standard'
> These packages provide a reasonably small but not too limited
> character-mode system. This is what will install by default if
> the user doesn't select anything
On Fri, 18 May 2001, Anthony Towns wrote:
>...
> Since there's a 'tetex' task, I've also dropped tetex from standard to
> optional: people who want TeX will need to choose the task now.
Current policy says:
<-- snip -->
`standard'
These packages provide a reasonably small but n
On Sat, Dec 16, 2000 at 03:45:59AM +1000, Anthony Towns wrote:
> On Fri, Dec 15, 2000 at 05:22:59PM +0100, Santiago Vila wrote:
> > If not, I object to any change in the priority system until we achieve
> > a consistent system with the current priorities.
> Heh. I don&#x
In general, I like the names and descriptions better than what we have
currently. However, I see a problem with the criterion for "getting
something into common". It is likely that some maintainers will take
it as an insult to have their package "demoted" to common, and to
> I'd think a restricti
the ftpmasters finally get around to
> doing stuff, some things probably need recompiling, and some thought is
> definitely needed as to whether priorities should be raised or lowered.
Of course it isn't "just" but it's "mainly". There are trivial bugs
which are
ce the ftp.debian.org maintainers to fix *all* the bugs
> (not only those of important severity), fine.
This isn't just a matter of having the ftpmasters finally get around to
doing stuff, some things probably need recompiling, and some thought is
definitely needed as to whether priorities should
is contains all packages that conflict with others with
required, important, standard or optional priorities, or are only
likely to be useful if you already know what they are or have
specialised requirements.
By contrast, I think policy's got it exactly right, and t
Anthony Towns:
> For woody, it'd be nice if we could use the Priority field consistently.
It would be even nicer if we could use the override file consistently,
but it seems there is not enough ftp.debian.org manpower to fix the
wrong priorities. I refer to this rule in policy:
Pack
Anthony Towns writes:
> It could be used something like:
>
> * nothing in optional or above can conflict
I think this would be a mistake. This would make all MTAs,
except the one anointed as standard, become extra. I think conflicts
should be permitted in common, optional and extra
On Friday 15 December 2000 15:10, Anthony Towns wrote:
> I'd think a restriction something like ``all `common' packages must be
> included in at least one task'', which means they only get to be common
> if they can convince one of the task maintainers to include their package.
So this is not a su
r package.
Note that if the package isn't in a task, and isn't standard, it can't
be installed without going into dselect (or apt-get, or console-apt or
something equivalent).
> BTW, do you think WindowMaker or Englightenment packages should have
> priorities "Common"
ir packages.
BTW, do you think WindowMaker or Englightenment packages should have
priorities "Common" in such case?
- --
Mariusz Przygodzki| Good judgement comes from experience.
[EMAIL PROTECTED] | Experience comes from bad judgement.
http://www.dune.home.pl
Hello world,
For woody, it'd be nice if we could use the Priority field consistently.
What do people think of something like:
required
-- Essential packages and things they depend on. If you
remove these (and don't replace them with something
Buddha Buck <[EMAIL PROTECTED]> writes:
> if the task-* packages are intended solely for the
> purview of tasksel, why put them in the main
> Packages.gz file? Why not distribute the dependency
> information as part of the tasksel package?
Because that's a huge pain in the butt, doesn't scale, a
23 Oct 2000 08:15:07 -0400,
on Re: Priorities,
Ben Collins <[EMAIL PROTECTED]> wrote:
> I think the task-* packages can be solved pretty easily with some
> guidelines like:
>
> Task packages can define different levels of installation. The
> tasksel pro
Hi
Ben Collins schrieb:
> Task packages can define different levels of installation. The
> tasksel program will follow these rules for each case:
>
> - Minimum, installs everything that the task-* package Depends on
> - Standard, installs everything in Minimum, plus packag
>
> Now, there are some related problems happening. One big one is the
> fact that "Recommends" and "Suggests" have lost their usefulness
> since apt-get came on the scene. I venture to suggest that several of
> the inappropriate task-* packages exist purely to remedy this. If,
> e.g., the Roxe
On Wed, Oct 18, 2000 at 01:05:28PM -0700, Chris Waters wrote:
>
> ~ $ grep-available -P roxen -sPackage|wc -l
>70
I think this is a different problem. There's no reason for every little
Roxen module to be a separate package.
Richard Braakman
On Sat, Oct 14, 2000 at 10:03:08PM -0400, Adam Di Carlo wrote:
> Sorry, I'm not on debian-policy, but since I was one of the ones who
> lobbied for task packages, just a few random thoughts.
(Cc'ed)
> > python
> > - how do I know whether I'm going to write "complicated" apps or not?
> I d
At 11:39 AM 10/19/00 -0700, Chris Waters wrote:
On Wed, Oct 18, 2000 at 10:46:36AM -0400, Deephanphongs, David wrote:
> If task packages can provide choice, why not let them? The
> task-gnome-desktop (or something like that) package was helpful to
> me when I wanted to install gnome, since it's
On Wed, Oct 18, 2000 at 10:46:36AM -0400, Deephanphongs, David wrote:
> If task packages can provide choice, why not let them? The
> task-gnome-desktop (or something like that) package was helpful to
> me when I wanted to install gnome, since it's made up of
> half-a-dozen packages.
Yes, but the
On Tue, Oct 17, 2000 at 12:06:58PM -0700, Joey Hess wrote:
> Yes, task-webserver-roxen should not exist. I have written about this
> before. "I want a web server" is a suitable task, "I want web server
> foo" is not.
I think the problem we're seeing is this: the 'task-' package
namespace is magi
While I mostly agree with Adam, there's one nit I'd like to pick:
On 14-Oct-00, 21:03 (CDT), Adam Di Carlo <[EMAIL PROTECTED]> wrote:
> > * browsing the web (without having to download plugins all the
> > time, having java support, etc)
>
> Well, we do have virtual packages for this.
>
Peter S Galbraith schrieb:
> I don't understand. If you remove task-doc from the list of task
> packages that users can easily pick from, they _will_ have to go
> out of their way to get them installed individually as packages.
Well, may be renaming it to eg task-newbie would be another
solution.
> From: Joey Hess [mailto:[EMAIL PROTECTED]
>
> Anthony Towns wrote:
> > The *task* is really "usable 2d windowing environment for accessing
> > programs", it's not kde, or gnome, or xlib, or motif. Is it really
> > sensible to have the choice between the various windowing toolkits
> > made here?
Joey Hess wrote:
> Anthony Towns wrote:
>
> > doc
> > - eh?? i have to go out of my way to get "General documentation"??
>
> I think I agree with all of these. We should file bugs to get them
> removed.
I don't understand. If you remove task-doc from the list of task
packages that user
Anthony Towns wrote:
> I don't really understand task packages. I'd assume that they're there
> to make it easy for people to do some particular common tasks (setup a
> desktop environment, interact with your computer in japanese, play music,
> do 3d graphics, program).
Right. Have you done a pota
Sorry, I'm not on debian-policy, but since I was one of the ones who
lobbied for task packages, just a few random thoughts.
Anthony Towns writes:
> I don't really understand task packages. I'd assume that they're there
> to make it easy for people to do some particular common tasks (setup a
> de
* Anthony Towns [001009 21:10]:
> Well, which of emacs or vi should be the "preferred" editor?
This is missing the biggest question of all -- which of the various Vi
clones should be THE vi Debian suggests?
Vim, of course.
:)
debian-boot: This is diverging into a discussion of task- packages. It's
probably reasonable to keep discussion on -policy rather than duplicate it
on both lists, I guess.
On Mon, Oct 09, 2000 at 03:56:15PM -0500, Steve Greenland wrote:
> As far as "mutliple preferred packages", my intent is that
those (as
I understand it) is to group various packages that work together. I'm
also bothered (a little) by the "task-webserver-roxen" (why is there no
"task-webserver"?), in that it doesn't offer much guidance (because it
implies the existence of t-w-apache, t-w-boa,
And some of the task- packages should logically conflict with each other,
because they depend or reccomend conflicting packages.
For example, if task-gnome-desktop depended on gdm (which it doesn't
according to my apt-cache), then it and task-kde should be made to
conflict because gdm and kdm con
On Tue, Oct 10, 2000 at 05:18:05AM +1000, Anthony Towns wrote:
> 'common': everything that might reasonably appear in an "ff the
> shelf" install (ie, the contents of all task- packages)
I think that not all task- packages would be "common". There are bound
to be some speciali
> > On 04-Oct-00, 14:27 (CDT), Anthony Towns wrote:
> > > So I wonder if changing it to something more like:
> > > 'important': things that will be on *every* system, except *very*
> > > specialised ones
> > > 'standard': everything that might reasonably appear in an "off the
> > >
cialised ones
> > 'standard': everything that might reasonably appear in an "off the
> > shelf" install
> > 'optional': everything else that doesn't conflict with anything above
> > 'extra': anything rare, or
ht reasonably appear in an "off the
> shelf" install
> 'optional': everything else that doesn't conflict with anything above
> 'extra': anything rare, or conflicting with optional or higher packages
If we're going to mess with p
On Thu, 5 Oct 2000 at 02:11, Branden Robinson wrote about "Re: Priorities":
> Because Ian Jackson, who originally authored that language, likes TeX and
> Emacs, but hates X. Our present definition of "standard" has everything to
> do with his personal preferences.
On Thu, Oct 05, 2000 at 05:27:21AM +1000, Anthony Towns wrote:
> I know a lot of people are annoyed by tetex and emacs being standard
> priority, and I personally find it odd that X isn't "standard" these
> days, especially since it's "more of a piece of infrastructure than an
> application".
Beca
Hi,
I know a lot of people are annoyed by tetex and emacs being standard
priority, and I personally find it odd that X isn't "standard" these
days, especially since it's "more of a piece of infrastructure than an
application". The separation between important and standard also doesn't
seem very cl
A03691
for [EMAIL PROTECTED]; Sat, 12 Jun 1999 14:24:13 -0400
Date: Sat, 12 Jun 1999 14:24:13 -0400
From: Chris Fearnley <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: debian-policy has an unclear statement on dependancies and priorities
Message-ID: <[EMAIL PROTECTED]>
Mime-Version
s
> phraseology would be clearer:
>
> All dependencies in a package MUST have equal or higher priority than
> the package itself. In order to achieve this the priorities of one
> or more packages may have to be adjusted.
I personally think that the original version is cl
Previously Chris Fearnley wrote:
> Lintian Maintainer:
> BTW, do we have software that checks the archive for compliance with this
> part of policy? Does lintian do it? A brief scan at that package suggests
> that this should be added to lintian's wish list.
http://master.debian.org/~wakkerm/rel
sentence. Perhaps this
phraseology would be clearer:
All dependencies in a package MUST have equal or higher priority than
the package itself. In order to achieve this the priorities of one
or more packages may have to be adjusted.
Lintian Maintainer:
BTW, do we have software that checks the
Santiago Vila <[EMAIL PROTECTED]> wrote:
> Also, packages in the base system (i.e. those in base2_1.tgz)
> should not require a package outside of the base system to work, because
> otherwise the base system would be "broken". Whether this "requires"
> is just Depends or both Depends and Recommend
compliance.
>
> I have updated my dependency-checker to also check Depends for
> priorities, and the report is available via www at
> http://master.debian.org/~wakkerma/unmet.html .
Good work!
Yes, a Recommends should be treated the same as a Depend with respect to
DFSG compli
priorities, and the report is available via www at
http://master.debian.org/~wakkerma/unmet.html .
If nobody disagrees with handling Recommends the same as Depends
I'll add this to the scanner.
Wichert.
--
==
This combinati
81 matches
Mail list logo
