Re: Bug#458385: New version of Artistic License
While on principle I agree with Charles Plessy about the merits of including this license despite not having the "critical mass" that Debian would like, I understand the view of those in the policy team and respect their decision. For what it's worth, I've added a machine-readable-copyright-format-compatible Artistic-2.0 license text to: http://pkg-perl.alioth.debian.org/copyright.html -- in reality, I've only come across a few Artistic-2.0 licensed modules (the rest are semi-ambiguous "same terms as Perl" -- which gets confusing with the abundance of Perl6:: modules, but I digress). I still consider having to copy-and-paste that license (and later having to remove it and replace it with a reference to the one in common-licenses) papercuts -- they're annoying, but not the end of the world. And I guess we won't have to worry about removing them for another few years yet.. so we can let future-me deal with it :-) On Sun, Aug 30, 2009 at 2:35 AM, Charles Plessy wrote: > Le Sat, Aug 29, 2009 at 02:23:26PM +0200, gregor herrmann a écrit : >> >> As a first approach I've grepped thruugh the lintian lab: >> >> gre...@bellini:/org/lintian.debian.org/laboratory/source$ egrep "(Artistic >> License (Version )*2|Artistic-2)" */debfiles/copyright | cut -f1 -d/ | uniq >> | wc -l >> 19 > > Interestingly, this list does not fully overlap with the result of a search > for > "The Artistic Licence 2.0" using OpenGrok. > > http://walrus.rave.org/source/search?q="The+Artistic+Licence+2.0"; > > This said, I would like to add my voice to say that since there are good > reasons to think that the Artistic license 2.0 will become a common license > some days, even if it takes a few years, it would be kind to add it in the > common license list in advance, to save the maintainer's time from adding it > to > debian/copyright now and removing later. > > Have a nice day, > > -- > Charles Plessy > Debian Med packaging team, > http://www.debian.org/devel/debian-med > Tsurumi, Kanagawa, Japan > > > -- > To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On 26/08/09 at 23:29 -0500, Manoj Srivastava wrote: > On Wed, Aug 26 2009, Steve Langasek wrote: > > On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote: > >> Given that devscripts, lintian, and the dev-ref > >> all advocate or implement +nmu\d+, and that debhelper and cdbs look > >> at the hyphen for determining native vs non-native, I have tried to do > >> so. I think the proposed practice is strictly better than not > >> specifying any conventions, and where possible, Ihave tried to stick to > >> best practices as documented in the dev-ref to base policy on. > > > >> Having said that, there are a lot of packages that seem to still > >> use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this > >> policy change as a 'recommends', and letting lintian warn about the > >> version number. > > > > I don't agree that this is something that should be recommended. > > Changing the convention for NMU versioning of non-native packages is > > not necessary in order to correct the use of confusing version numbers > > for NMUs of native packages. If the dev-ref is recommending +nmuN for > > non-native packages, then I think that's a bug in the dev-ref - a > > common enough problem given the lack of a public process for dev-ref > > change reviews. > > I think they changed that in a newer release than the one > referred to in the bug report I saw. Yes. It was initially changed to +nmuN for both native and non-native packages. But I recently saw that almost everybody was still using .N for non-native ones, so I fixed dev-ref accordingly. (I don't think that dev-ref should be used to change policy, it should document the current pratice, which is +nmuN for native pkgs, and .N for non-native ones.) > , > | Stable Security NMU's > |Version =~ m/\+deb\d\d.\d+$/ > | Testing Security NMU's > | Version =~ m/\+debt\d\d.\d+$/ > ` > These last two do not have buy in from the security team, as far > as I can tell. That's unfortunate. Imagine the following scenario: 1. Package P is released in sarge, with version 1.0-1. 2. Package P is installed on a system S, running sarge. 3. etch is released with P 1.0-1. 4. A security bug is found in P. 5. An oldstable security upload is done for P 1.0-1+sarge1 6. S installs 1.0-1+sarge1 7. A stable security upload is done for P 1.0-1+etch1 8. S is upgraded to etch. P isn't upgraded: 1.0-1+etch1 << 1.0-1+sarge1 9. sarge reaches end-of-life, and is no longer supported 10. Another security bug is found in P 11. A stable security upload is done for P: 1.0-1+etch2 At this point, S won't auto-upgrade to O 1.0-1+etch2 (since 1.0-1+etch2 < 1.0-1+sarge1). S will keep the vulnerable version of P. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544353: debian-policy: Offer One Big HTML http://www.debian.org/doc/debian-policy/
Package: debian-policy Version: 3.8.3.0 Severity: wishlist Please offer link to a One Big HTML page, which would: - be easier to search (forward, backward) - store to browser's offline cache -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.3 utilities to manage online documen -- no debconf information -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
