Rob Browning writes:
> Bill Allombert writes:
>
>> What to do for ascii :
>>
>> emacs24 --batch -Q -l ./README-css.el -l org -l org-ascii
>> --visit Process.org --funcall org-export-as-ascii
>>
Attached is a better patch series that fixes the ascii export,
and deals with all the (unused) TeX cr
Tim Wootton writes:
> My understanding was this is the correct approach unless doing so
> breaches policy, which this (and apparently many others ) does.
No, priorities for library packages are basically ignored. They've
essentially never changed how we choose compilation options in the past.
Simon McVittie writes:
> a better way to achieve the same result with fewer steps and more
> automation would be:
> * a cron job (jenkins.debian.net?) installs the required, important,
> standard sets (which is something we probably want to test anyway)
> * people who are interested in whether
On Sun, Nov 02, 2014 at 05:53:14AM +0100, Marco d'Itri wrote:
> On Nov 01, Bill Allombert wrote:
>
> > Is there alternative documents describing the interfaces for packages to
> > interoperate with systemd, and transition documents available for packagers
> > and
> > users that need to adapt to
Hi,
Bill Allombert:
> What I do not understand is, how this affect debootstrap ?
>
Debootstrap (by default) fetches everything-in-important, and then adds any
un-satisfied dependencies which these packages need.
Installation variants instead get everything-in-mandatory,
plus e.g. apt and build-e
On 13/11/14 12:34, Bill Allombert wrote:
> For me priority are purely metadata provided by the override file.
> Policy does not require software to use them in anyway, I think.
Policy does not require software to use them; but in practice, software
does use them, and so changing a Priority has obs
On Thu, Nov 13, 2014 at 01:24:32PM +0100, Matthias Urlichs wrote:
> [ re-post, signed ]
>
> I'd like to formally propose the following Policy change to fix the
> "depend on packages with lower dependencies" non-problem.
>
> This does simplify current practice, but unfortunately not Policy itself,
[ re-post, signed ]
I'd like to formally propose the following Policy change to fix the
"depend on packages with lower dependencies" non-problem.
This does simplify current practice, but unfortunately not Policy itself,
as adhering to policy shouldn't allow you to break debootstrap. :-P
This cha
Hi,
Simon McVittie:
> On 13/11/14 09:59, Matthias Urlichs wrote:
> > I'd like to suggest the following Policy change to fix the "depend
> > on packages with lower dependencies" non-problem.
> >
> > This does simplify current practice, but unfortunately not Policy
> > itself, as adhering to policy
On 13/11/14 09:59, Matthias Urlichs wrote:
> I'd like to suggest the following Policy change to fix the "depend
> on packages with lower dependencies" non-problem.
>
> This does simplify current practice, but unfortunately not Policy
> itself, as adhering to policy shouldn't allow you to break
> d
Package: debian-policy
Followup-For: Bug #758234
I'd like to suggest the following Policy change to fix the
"depend on packages with lower dependencies" non-problem.
This does simplify current practice, but unfortunately not Policy itself,
as adhering to policy shouldn't allow you to break deboot
On 13/11/14 03:29, Russ Allbery wrote:
> Tim Wootton writes:
>
>> or just build without the dependency in the 1st place like it used to
>> be. After all it's not like it adds anything that's essential.
> No, including the dependency is the right approach and is consistent with
> how Debian has alw
Hi,
Tim Wootton:
> or just build without the dependency in the 1st place like it used to be.
> After all it's not like it adds anything that's essential.
>
Most dependencies don't add anything that's "essential" in the strict
sense. The vast majority of uses of computers aren't essential either,
13 matches
Mail list logo
