Hi,
Steve Langasek wrote:
Sorry this has taken so long; I spun my wheels on it
for some time because I couldn't quite accept that there were so few
additional requirements that needed to be specified here!
Thanks for your work. :)
[...]
+ tasks at boot time. However, any package
Hi,
On Fri, 04 Mar 2011, Jonathan Nieder wrote:
) I suspect others like it, too, but who knows? Patch attached.
Seconds or objections welcome.
Seconded. It's long and I might have missed some inaccuracies but I think
it's an improvement in clarity.
Cheers,
--
Raphaël Hertzog ◈ Debian
On Thu, Mar 03, 2011 at 04:35:09PM -0600, Jonathan Nieder wrote:
Bill Allombert wrote:
Now preserving interfaces _does_ seem like an objection that's more
important. A policy should like this (potential) one represents a
bug but it is not necessarily more important than the other bug of
On Fri, Mar 04, 2011 at 08:15:28PM -0600, Jonathan Nieder wrote:
Hi,
Ansgar Burchardt noticed:
perl/5.8.0-7 added /etc/perl to @INC:
* Prepend /etc/perl to @INC to provide a standard location for
configuration modules:
But this addition has never been documented in the
On Fri, 04 Mar 2011 20:15:28 -0600, Jonathan Nieder wrote:
I see this has been seconded by
Niko Tyni nt...@debian.org (message #25)
and I imagine that Russ might be willing to second this, but that
still leaves us one DD short[1]. Seconds? Objections?
Clarifications?
diff --git
On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
Hi,
Steve Langasek wrote:
Sorry this has taken so long; I spun my wheels on it
for some time because I couldn't quite accept that there were so few
additional requirements that needed to be specified here!
Thanks for
Bill Allombert wrote:
On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
Maybe policy could allow (but discourage) packages that only support
some non-Sys-V init system as long as they include a dependency
indicating so?
This would be a terrible idea. We would end up with
On Sat, Mar 05, 2011 at 12:19:22AM -0600, Jonathan Nieder wrote:
Hi Russ,
Russ Allbery wrote:
Right, this was the reason why I hadn't committed anything yet. We have
to decide whether we're going to prohibit arch:any - arch:all links
completely to ensure that the binNMU changelog
On Fri, 4 Mar 2011 15:33:00 -0600
Jonathan Nieder jrnie...@gmail.com wrote:
To throw an idea out, I wonder if making the filesystem hierarchy
standard (http://www.pathname.com/fhs/) more visible could have the
same effect? For example, there could be a package providing
READMEs in system
On Fri, 4 Mar 2011 15:49:45 -0600
Jonathan Nieder jrnie...@gmail.com wrote:
What do you propose?
I propose to define the next two things in policy:
- types of documents that must have Debian version;
- how far from document's beginning can version info be placed.
-
Regards,
Hi Sergey,
sergey wrote:
Does Debian policy can recommend something (including READMEs)? Or policy can
only
force something, no recommendations is possible?
Policy sets rules that make sure the system works well. These can be
hard requirements (generally using the word must), which
Hi Jonathan,
Policy sets rules that make sure the system works well.
...
Perhaps the following might provide some inspiration:
http://dep.debian.net/deps/dep0/
I agree that it is a good place for proposals like mine.
But making long well-developed draft and driving it - this is
Hi,
Steve Langasek wrote:
So in this case the pre-dependency
should *not* be set, as it only serves to complicate the upgrade path.
I think this example might deserve a closer look. Documentating the
required dpkg version seems useful for backporters and others who
would use the package in
(-cc: Steve since he is already subscribed to -policy)
Hi Sergey,
sergey wrote:
I agree that it is a good place for proposals like mine.
But making long well-developed draft and driving it - this is
mostly operating system developer's task, not users one.
I think that Debian should have some
14 matches
Mail list logo
