[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#353277: ndiswrapper in main



On 3/1/06, Raphael Hertzog <hertzog@debian.org> wrote:
> On Wed, 01 Mar 2006, Raul Miller wrote:
> > Let's grant that any "moving to contrib" will only happing in unstable/testing
> > (and future stable) releases of debian.
> >
> > Do you see a problem with moving these to contrib?  After all, everything
>
> Honestly I don't care enough about either those libs or ndiswrapper to
> oppose to the move to contrib. But I've given my interpretation of the
> policy and my rationale why they can/should be kept in main.
>
> Now, you use that input how you want and you make up your own opinion.

Ok, correct me if I'm wrong, here's how I'm understanding what you
wrote: You feel that the contents of the "contrib" section mentioned in the
social contract should be mechanically determined by debian package
headers, and not by a more general concept of dependency?

If that's not your point, I don't understand your input.

> > in conjunction with non-free software.  Why do you think these other packages
> > should not go in contrib?
>
> Because they are DFSG-free, they have no explicit dependencies on a non-free
> package and because they're not (installation) wrapper.

It sounds to me like you're saying that all packages in contrib could
be moved to main simply by removing the explicit dependencies in
their package headers?

> > We have to make assumptions about how software is normally
> > used to define reasonable values for dpkg headers like Depends:
>
> We're speaking of software of the user that is not packaged by us. I don't
> see how a dpkg Depends field is relevant here.

I don't see why you think the Depends field is the entire issue when
we're talking about "contrib".

--
Raul



Reply to: