fonts packages review and conffile-without-noreplace-flag warning

Mamoru Tasaka mtasaka at ioa.s.u-tokyo.ac.jp
Wed Mar 28 04:35:49 UTC 2007


Tom "spot" Callaway wrote:
> On Wed, 2007-03-28 at 11:25 +0900, Akira TAGOH wrote:
>>>>>>> On Tue, 27 Mar 2007 09:12:41 -0500,
>>>>>>> "TC" == "Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:
>> TC> Question: Is it really a configuration file?
>>
>> TC> To determine this, ask, will a user be permitted to change it? If the
>> TC> answer is yes, then the user will be quite unhappy to have it replaced
>> TC> by the stock copy when they do a package update. If it is not something
>> TC> designed to be hand-edited (or shipped with a tool to edit), then its
>> TC> probably not a config file.
>>
>> Yes, it's a configuration file that designed to determine
>> the connection between PostScript fontname and the real
>> font. someone may wants to use another one rather than the
>> default font. those would be helpful in this case.
>>
>> However my question is, what happens if the default font is
>> changed? 
> 
> I would say that if they changed it to use a specific font, then, they
> really want that specific font, whether the default changes or not.

Here Akira says is perhaps.. what happens if the previous fonts is
completely _removed_ (due to license issue or something)?
In this case, user-customized config file completely gets useless.
Well, this actually happened on fonts-japanese

I hear some peole say, "well, actually the configuration will
change in the future, so I want to leave this configuration file
as not noreplace".

> The default font should only change in a major release, and should be
> documented in the Release Notes.

I doubt every people reads release notes. And especially, this
is for Japanese...... Forcing people to read release notes is
not a good solution.

IMO if a package has some reason not to add noreplace, then
we should leave as how the packager judges. I saw another example
* When I reviewed a font package and asked a configuration
  file to mark as noreplace, the packager said okay.
* After review passed, the packager updated the package several
  time. After that, the packager decided, "ah, noreplace is
  inconvenient. removing noreplace..."

Mamoru




More information about the Fedora-maintainers mailing list