(-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
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
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 i
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 cor
On Fri, 4 Mar 2011 15:49:45 -0600
Jonathan Nieder 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, Sergey
--
To UNSU
On Fri, 4 Mar 2011 15:33:00 -0600
Jonathan Nieder 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 directories contai
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 chan
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 w
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!
>
> T
On Fri, 04 Mar 2011 20:15:28 -0600, Jonathan Nieder wrote:
> I see this has been seconded by
>
> Niko Tyni (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 a/perl-policy
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 documen
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
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 Deve
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 packa
14 matches
Mail list logo
