Previously Ian Jackson wrote:
> OK, how about this: we rename (in a phased manner) Maintainer (in
> .changes) to Uploader.
I definitely agree with this.
> Also, we arrange for this new field to appear in the package control
> file, if it is different from Maintainer.
We risk another non-obvious
Wichert Akkerman writes ("Re: smarter way to differ architectures needed?"):
> Previously Ian Jackson wrote:
> > No, it shouldn't. There should possibly be a new field, but
> > Maintainer is for the maintainer.
>
> A Compiled-by: field would be useful. You can also use that to track
> down who co
Previously Roman Hodek wrote:
> Oh, I see, you probably mean the control file of packages. Then we
> have the following problem: The name of the builder is available only
> in dpkg-buildpackage and passed to dpkg-genchanges. dpkg-gencontrol
> never sees it... expect we make some tricks with environ
> 1) add a Compiled-By field to the control-file
Aehm, to debian/control?? That doesn't make sense. debian/control
contains static infos, whereas who compiled a pkg is dynamic.
Oh, I see, you probably mean the control file of packages. Then we
have the following problem: The name of the builder
> Eeks, no! I don't want the Maintainer: field to change on every NMU
> -- that would be ghastly, especially if people think to use dpkg -s
> to get in contact with the maintainer.
I was talking about Maintainer: in the .changes, not in the package
itself.
Roman
Julian Gilbey <[EMAIL PROTECTED]> writes:
> I would suggest actually having both in the .changes file, then
> dinstall could decide whether to close bugs or change their severity
> to fixed based on the content of the two fields. I have handwritten
> patches to dinstall and the dpkg-dev scripts t
6 matches
Mail list logo
