From: Keith M. <kei...@us...> - 2010-03-13 22:49:44
|
On Saturday 13 March 2010 19:32:38 Charles Wilson wrote: > >> See, this is where I differ from Keith (but, he's a maintainer, > >> and I'm just a schmoe). > > > > Your words, not mine. > > how about > "...where I differ from (what I believe is) Keith's (position)..." > ? That's fine; it was your reference to yourself as "just a schmoe" that I felt was unnecessarily self-deprecatory. > > Well, to be strictly accurate, I corrected a disappointing > > packaging bug in the upstream source tarball, by re-sequencing > > invalid time stamps on two generated files, which GCS require to > > be generated by the distributor, prior to package release; (this > > is disappointing because it's an effective repetition of a bug > > which was previously fixed, following my report in respect of > > binutils-2.19 -- perhaps it was naive to expect that the > > upstream maintainers might take better care than to repeat so > > soon, what is effectively the same error). > > Yes, there is something broken in their release process. What > individual manages that? Tristan Gingold, I believe. I'll file a new bug report, including a summary of my analysis (below), and copy him as an advance heads-up. > Rather than simply reporting the bug, > can we pinpoint the problem in the Makefile's make-dist rule that > causes the violation? Part of the problem is that they don't have a `make dist' rule at all, (which in itself, is a GCS violation). However, I don't think that is the fundamental reason for this particular error that seems to keep recurring. I'm inclined to suspect:-- - They have a tool to generate .texi sources from .c sources; this tool is provided in the source package, and is run by the Makefile when the .c file is modified, to write .texi output to a temporary intermediate file. - The change in any .c file may not necessarily affect the content of the resultant .texi output. - They use `move_if_change' to update the real .texi file; this is the likely problem, since if the content doesn't change, the .texi file is not updated, and the time stamp progression is broken; the .texi file remains out-of-date wrt its .c prerequisite. - Even if, during their release process, they update and package the ultimate .info target, their package will still include that out-of-date .texi file; thus this must be remade, and this in turn forces a remake of the .info file. This requires the end user to have GNU makeinfo, (which is a further GCS violation -- end users are not supposed to be required to install this, and users of Debian derivatives such as Ubuntu, typically don't because GNU info, which provides it, is incompatible with Debian's customised variant). -- Regards, Keith. |