Charles Plessy <[EMAIL PROTECTED]> writes:
> I think that if we were shipping a package whose description says
> "Install this and you will have your 3D working" and which would
> automatically download non-free software, we would indeed cheat our
> users.
>
> On the other hand, if a package is d
Le Wed, Aug 06, 2008 at 07:37:47PM -0700, Russ Allbery a écrit :
>
> I think it would be very surprising to have installation of a package from
> the main distribution area result in downloading non-free software from
> elsewhere, which is a common case for contrib packages.
Le Thu, Aug 07, 2008
Charles Plessy <[EMAIL PROTECTED]> writes:
> In the end, the contrib category is free software
The works in 'contrib' are free software. That's not enough for them
to be in 'main', because 'main' is defined as more than just an
arbitrary collection of free software. 'main' is the Debian operating
Charles Plessy <[EMAIL PROTECTED]> writes:
> In the end, the contrib category is free software, so why not simply
> downgrade it as a priority level, lower than "extra"?
I'm assuming that you mean doing this instead of keeping it as a separate
distribution area.
> This would solve the problem fo
Le Wed, Aug 06, 2008 at 10:07:01PM -0300, Stefano Zacchiroli a écrit :
>
> A user can be rightfully puzzled by such a situation: is the _source_
> package she is downloading part of Debian or not?
Hi Stefano, Jörg, and everybody.
In the end, the contrib category is free software, so why not simp
On Thu, Aug 07, 2008 at 01:28:49AM +0100, Adeodato Simó wrote:
> I do think that allowing packages in main to provide binaries in contrib
> is useful, so I'd like to hear what the benefits would be if we'd agree
> to lose it.
I have no idea if there are technical benefits in dropping the support
f
* Julien Cristau [Wed, 06 Aug 2008 21:38:00 +0200]:
> On Wed, Aug 6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote:
> > Now, the idea would be to deprecate this feature, used by 8 packages in
> > unstable, dropping complications in the database backend and the pool
> > layout which we would want t
vegetable dr
Sender: "TECO DRYER" <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Thu, 7 Aug 2008 00:09:10 +0300
Message-ID: <[EMAIL PROTECTED]>
X-Priority: 3 (Normal)
Importance: Normal
Teco Industry is in the business of
On Wed, Aug 06, 2008 at 08:47:50PM +0200, Joerg Jaspert wrote:
>
> But before we take a final decision I want to hear more input on it. So
> here are your 5 seconds, please give input. :)
To me, this sounds like a step in the right direction to unfuzzy the
distinction between Debian itself (main)
Joerg Jaspert <[EMAIL PROTECTED]> writes:
> Now, the idea would be to deprecate this feature, used by 8 packages in
> unstable, dropping complications in the database backend and the pool
> layout which we would want to avoid.
>
> Yes, it would require those packages to have a new (additional, may
On Wed, Aug 6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote:
> Now, the idea would be to deprecate this feature, used by 8 packages in
> unstable, dropping complications in the database backend and the pool
> layout which we would want to avoid.
>
Maybe you could tell us what the benefit of dropp
Hi
currently our archive has the feature(?) that a source package in component a
(like main) can build a binary package in component b (like contrib).[1]
Now, this feature is blocking (or making it way harder) to do some
database re-designs we want to do for the central archive database, so
we lo
On Wed, Aug 6, 2008 at 7:01 AM, Graeme Brett Houston BSc
<[EMAIL PROTECTED]> wrote:
> Hi could a pre-compiled debian package be released that would allow qemu
> to run with the pci-proxy patch to allow pci logging of pci devices
> without hardware documentation such as the Sun SunPCi devices etc &
Hi could a pre-compiled debian package be released that would allow qemu
to run with the pci-proxy patch to allow pci logging of pci devices
without hardware documentation such as the Sun SunPCi devices etc & the
appropriate kernel image.
As such it would be particularly good if the qemu-pciproxy
14 matches
Mail list logo