All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robbie Harwood <rharwood@redhat.com>
To: Nicholas Vinson <nvinson234@gmail.com>, grub-devel@gnu.org
Subject: Re: [PATCH] Add Fedora location of DejaVu SANS font
Date: Wed, 08 Dec 2021 18:42:14 -0500	[thread overview]
Message-ID: <jlgsfv2y889.fsf@redhat.com> (raw)
In-Reply-To: <4a790b05-53b1-bfd9-f5bf-8c54ef009185@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3658 bytes --]

Nicholas Vinson <nvinson234@gmail.com> writes:

> On 12/8/21 12:58, Robbie Harwood wrote:
>> Nicholas Vinson <nvinson234@gmail.com> writes:
>>> On 12/7/21 15:04, Robbie Harwood wrote:
>>>> Nicholas Vinson <nvinson234@gmail.com> writes:
>>>>
>>>>> Wouldn't it be better to modify configure.ac so the location could
>>>>> be passed in instead of having one-off patches for alternate
>>>>> locations?  Something like
>>>>> --with-dejavu-font=/usr/share/fonts/dejavu-sans-fonts?
>>>>
>>>> That would mean that anyone using grub2 that wants the dejavu fonts
>>>> will have to figure out that the option exists and pass it to the
>>>> buildscripts.  That's a pretty bad user experience for anyone
>>>> building their own grub.
>>>
>>> On the contrary, it doesn't have to mean that at all. It could mean
>>> that when a path is given, configure would use the provided path;
>>> otherwise, it falls back to its default list to find the font.
>> 
>> But then we still have to keep the default list... and I'd still be here
>> as a distro maintainer wanting my distro's path in the default list.  I
>> don't see how this is any better.
>
> And you want it in the default path because? Most likely because you're 
> patching configure or using tools like sed or awk to change configure or 
> Makefile to use your path? You know that approach is brittle and you 
> want something better.

No, that's not it.  Don't put words in other people's mouths.

We're sitting on more than 220 downstream patches that I want
upstreamed.  The relative brittleness of this particular change is
*nothing* in comparison, believe me :)

The sheer number here means I'm starting with the easy stuff.  The
one-liners, simple conceptual things, *stuff that should be
non-contentious*.

> Adding your distro's choice location to a pre-defined list works until 
> the distro changes where it stores the font. At that point you are back 
> where you started. Manually patching GRUB until a version of GRUB is 
> released with your new path in the list.
>
> The same is true with any other distro that uses a location not in the 
> list. The approach you're suggesting is that submit a patch, get GRUB 
> updated.
>
> What I am asking for puts an end to that. Once the flag is in place, the 
> builder can pick whatever path is desirable, pass it into the configure 
> script, and have GRUB builds.  No need to craft a patch, send it to the 
> mailing list, and wait for the update to make it into a GRUB release.

But my point is this hurts everyone who's *not* the distro maintainer
but building their own grub.  That's the user experience issue I was
talking about.  Everyone developing on Fedora now has to remember
another flag or it won't work the same.

>>> Such an approach would mimic configure's current behavior for values
>>> such as bootdir and grubdir.
>> 
>> But those are *install* paths, not *detection* paths.  We're not
>> installing the font - we're figuring out where it is on the system.
>
> In the context of building GRUB, bootdir and grubdir are *not* 
> installation directories. They are simply default paths that get written 
> into the built code.

Right, that's what I mean by "install" path.  It's a place where you put
stuff, not a place where you find stuff.

> Effort is often times its own reward. I would not want to deprive you
> of it.

Wow, okay.

You know this comes across as rather hostile, right?  Is this really the
approach you want to take when someone *shows up with code* and asks you
to clarify your feedback?  Tell them to go away and RTFM?

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  reply	other threads:[~2021-12-08 23:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 22:25 [PATCH] Add Fedora location of DejaVu SANS font Robbie Harwood
2021-12-07  0:49 ` Nicholas Vinson
2021-12-07 20:04   ` Robbie Harwood
2021-12-08  2:30     ` Nicholas Vinson
2021-12-08 17:58       ` Robbie Harwood
2021-12-08 22:23         ` Nicholas Vinson
2021-12-08 23:42           ` Robbie Harwood [this message]
2021-12-09  4:33             ` Nicholas Vinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jlgsfv2y889.fsf@redhat.com \
    --to=rharwood@redhat.com \
    --cc=grub-devel@gnu.org \
    --cc=nvinson234@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.