Re: Ports page - about to be reset - patches weclome!
-=| Mark A. Stratman, Sat, Mar 26, 2011 at 12:13:09PM -0500 |=- Can somebody briefly explain the criteria for appending a '+patches' to the Perl version? e.g. as far as I can tell, every Debian perl package has patches (from looking at the debian package Changelog files), but only one is flagged as such. Huh? Where do you see that? According to http://packages.qa.debian.org/perl the available versions of the 'perl' package are: 5.10.0-19lenny3 lenny (currently oldstable) 5.10.1-17squeeze (currently stable) 5.10.1-18wheezy (currently testing) and sid (alias unstable) 5.12.3-2 (experimental) Looking at the output of 'perl -V' (on all versions above) brings no matches of '+patches'. By the way, the list of patches applied to the 'perl' package is available at http://patch-tracker.debian.org/package/perl signature.asc Description: Digital signature
Re: CMSP 16. Binary Package Dependencies
-=| David Cantrell, Thu, Oct 22, 2009 at 02:03:50PM +0100 |=- lib header (this should probably be renamed to inc, with an alias for sdrawkcab compatibility) Note that as well as having a library, you need to have the C header file so you can build stuff against it. Also, in things like Debian, those tend to be in seperate packages. Note that the libfoo-dev packages (the ones with C header files) are required to depend on the relevant library package. At least on Debian. -- dam signature.asc Description: Digital signature
Re: CMSP 23. Have a development version flag
-=| Graham Barr, Fri, Oct 09, 2009 at 09:20:37AM -0500 |=- On Oct 9, 2009, at 8:17 AM, Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:52:45] 23. Have a development version flag Agreed. * Con: Development version'ness would not be determinable post- installation AdamKennedy Packlist 2.0? Agreed. The main use of development status seems to be control if the distribution is indexed as the latest released etc. So having a flag instead of the hackish way we use _ seems a benefit. +1 Getting rid of _ will simplify downstream handling of versions. Currently one has to dig into CHANGES in order to determine if 1.002_04 is a dev release after 1.002 or the fourth beta before 1.002. Not that I am all for packaging development releases downstream, but some times they fix bugs and are a necessary evil. -- dam signature.asc Description: Digital signature
