On 15/11/11 22:03, Keith Marshall wrote:
> On 15/11/11 13:51, Charles Wilson wrote:
>> On 11/15/2011 7:42 AM, Chris Sutcliffe wrote:
>>> I don't necessarily agree with bundling it
>>> though. Given the scenario where there is an error in the xml file or
>>> something changes in mingw-get that requires a modification to the
>>> xml, in theory you should re-package the entire solution in order to
>>> pick-up the new manifest. This seems like a lot of overhead effort
>>> for a potentially minor change.
> Good point.
>>> If someone decides to take ownership of a given package, the latest
>>> xml file is available in the FRS under the catalogue, or for that
>>> matter, is in their mingw-get cache, so I don't see the benefit of
>>> bundling it.
>> I agree with Chris, with regards to the complete manifest.
> Having given it further thought, I agree too.
However, an option which may be worth considering: rather than bundling
it within any component of the main package, provide a *supplementary*
- The XML file in *template* form; (i.e. with issue="@YYYYMMDDNN@");
- A date stamp (%.issue) file for the most recently generated issue;
- A makefile, derived from the sample I posted previously.
Such a supplementary package could be managed independently of the
package to which it relates, (just as we do in the case of mingw-dist),
so avoiding the repackaging overhead which is of concern here.
Certainly, you may argue,(and you would be right), that having the
sample makefile to hand, together with the current XML file from FRS, it
should be fairly easy to reverse engineer such a supplementary package.
Thus, such a package may be considered as an optionally provided
convenience, rather than as a mandatory requirement.