DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, David Marchand <david.marchand@redhat.com>
Subject: Re: [PATCH v3] doc: build manpages as well as html output
Date: Wed, 30 Aug 2023 11:47:00 +0200	[thread overview]
Message-ID: <4505422.LvFx2qVVIh@thomas> (raw)
In-Reply-To: <ZO3EGF09duMi9X1s@bricha3-MOBL.ger.corp.intel.com>

29/08/2023 12:10, Bruce Richardson:
> On Tue, Aug 29, 2023 at 11:28:01AM +0200, Thomas Monjalon wrote:
> > 3/08/2023, Bruce Richardson:
> > > +    meson.add_install_script(mandb)
> > 
> > When is it executed exactly?
> > Will it update the database in case we install in a staging directory,
> > when preparing a package for later deploying on another machine?
> 
> Yes, it will. Unfortunately, I can't find any way to just call mandb if we
> are installing in a system manpage location on the local machine. Therefore,
> I had two options:
> 1. don't update the manpage database. In this case, the user won't be able to
> actually get the newly install manpages

The user can update the manpage database himself.
And if installing from a package, it should have been done automatically.

> 2. always update the local manpage database. In this case, the user
> installing the docs will find them, but anyone installing to staging will
> experience a slight delay while their local mandb is updated.
> 
> I went for #2 on the basis that the delay in the staging case is pretty
> harmless, while not actually finding the manpages is more serious.
> 
> However, I'm open to other suggestions on how to work this?

My concern is polluting the machine of the packager.
What happens when the staging directory is removed?
Is it an error when opening a manpage later?



  reply	other threads:[~2023-08-30  9:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01 15:38 [PATCH] " Bruce Richardson
2023-06-05  5:20 ` Jerin Jacob
2023-06-06  9:18   ` Bruce Richardson
2023-06-06  9:46     ` Jerin Jacob
2023-06-06 10:18       ` Bruce Richardson
2023-06-06 10:49         ` Jerin Jacob
2023-06-06 10:54           ` Bruce Richardson
2023-06-06 13:12 ` [PATCH v2] " Bruce Richardson
2023-07-04  8:21   ` David Marchand
2023-07-17 11:09     ` Bruce Richardson
2023-08-03  9:18       ` David Marchand
2023-08-03 16:43         ` Bruce Richardson
2023-08-03 16:44 ` [PATCH v3] " Bruce Richardson
2023-08-04 12:12   ` David Marchand
2023-08-29  9:28   ` Thomas Monjalon
2023-08-29 10:10     ` Bruce Richardson
2023-08-30  9:47       ` Thomas Monjalon [this message]
2023-08-30 10:20         ` Bruce Richardson
2023-08-30 11:23           ` Thomas Monjalon
2023-08-31  9:49 ` [PATCH v4] " Bruce Richardson
2023-08-31 10:12   ` Thomas Monjalon
2023-08-31 15:48     ` Morten Brørup
2023-09-27 16:25       ` Thomas Monjalon

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=4505422.LvFx2qVVIh@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).