Bug#955005: Relax requirements to copy copyright notices into d/copyright
No, I missed this. We're on the same page.
Bug#955005: Relax requirements to copy copyright notices into d/copyright
Hello Sam, On Wed 01 Apr 2020 at 05:11AM -04, Sam Hartman wrote: > I think there is another use of debian/copyright beyond just documenting > what ends up in the binaries. > I think that if I read debian/copyright in a source package, I should > expect to understand the licenses I need to comply with when dealing > with the source package. > > So for example if the package requires GPL-3 code during its build, and > by policy I don't want to deal with GPL-3 I should know I have a problem > only from reading debian/copyright. > > > So I think you need to talk about more than just binaries. As I mentioned in my e-mail opening the bug, I do not believe that my proposal changes anything at all about the requirements to document licenses in d/copyright, only copyright notices. Please take another look and let me know if my patch somehow changes the requirements to document licenses in a way I did not intend. -- Sean Whitton signature.asc Description: PGP signature
Bug#954794: New packages must not declare themselves Essential
> "Bill" == Bill Allombert writes: Bill> But is it an actual problem ? Do we see packages marked Bill> Essential: yes by mistake ? I think Josh's analysis brought up some important points for me that I did not consider before and that need to be considered making decisions in the future. I think capturing that analysis in a pointer from policy or in policy is important to me. Bill> Each time we make policy longer we dilute the content. Obviously, in the limit this is true. I think that capturing rationale for things that have good rationale and that could affect the project if not properly considered is worth doing even though it makes policy longer.
Bug#954794: New packages must not declare themselves Essential
On Wed, Apr 01, 2020 at 05:14:13AM -0400, Sam Hartman wrote: > I concur with the comments raised so far. > > I think it would be great to do a better job of outlining the problems > with essential packages in debian-policy. ... > I would support a statement in policy that as of the time of writing we > do not anticipate ever creating a new essential package. That would > help people considering proposing making an essential package know they > are probably looking at things the wrong way. But is it an actual problem ? Do we see packages marked Essential: yes by mistake ? Each time we make policy longer we dilute the content. Cheers, -- Bill. Imagine a large red swirl here.
Bug#954794: New packages must not declare themselves Essential
I concur with the comments raised so far. I think it would be great to do a better job of outlining the problems with essential packages in debian-policy. I don't understand why we would tie our hands though. A consensus of debian-devel seems adequate to consider those issues and evaluate them. If after making that consideration we decide to create a new essential package, we're going to do that policy not withstanding. I would support a statement in policy that as of the time of writing we do not anticipate ever creating a new essential package. That would help people considering proposing making an essential package know they are probably looking at things the wrong way. --Sam
Bug#955005: Relax requirements to copy copyright notices into d/copyright
I think there is another use of debian/copyright beyond just documenting what ends up in the binaries. I think that if I read debian/copyright in a source package, I should expect to understand the licenses I need to comply with when dealing with the source package. So for example if the package requires GPL-3 code during its build, and by policy I don't want to deal with GPL-3 I should know I have a problem only from reading debian/copyright. So I think you need to talk about more than just binaries. --Sam