All of lore.kernel.org
 help / color / mirror / Atom feed
From: aq <aquynh@gmail.com>
To: Jeremy Katz <katzj@redhat.com>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] reiserfs module for pygrub
Date: Tue, 24 May 2005 10:04:36 +0900	[thread overview]
Message-ID: <9cde8bff05052318046fdb3e7b@mail.gmail.com> (raw)
In-Reply-To: <1116892650.4292.41.camel@bree.local.net>

On 5/24/05, Jeremy Katz <katzj@redhat.com> wrote:
> On Wed, 2005-05-18 at 20:37 +0100, Ian Pratt wrote:
> > > here is a patch to add reiserfs (version 2,3) support to
> > > pygrub in -unstable (against cset 1.1434)
> >
> > Does Fedora have a reiserfs tools devel package?
> 
> Not at present.
> 
> > Please can you add something to the tools/check directory that checks
> > the appropriate headers are installed.
> 
> What if we check instead for the headers being present and only building
> the filesystem modules that there's support for on the system?  Then
> distributors can ensure they have the right things in their buildsystem
> and anyone else can do the same.  The attached patch should implement
> that for libext2fs.
> 
> > Also, at runtime, are there
> > issues with libraries being present? Can you load the library
> > dynamically if required?
> 
> The libraries get linked dynamically into the python module.  If at
> runtime, the library isn't present, it won't cause a fatal error (you
> won't be able to access those types of filesystems, but it won't fall
> over on the import)
> 

yes, this trick could be easily adapted to reiserfs and others. but
what if the user keeps the needed libraries, but removes those headers
( like /usr/include/ext2fs/ext2_fs.h )after building (for example to
make the system more compact)? then the check would fail.

actually we should check for those need to present at runtime, not
things at compile time. i propose checking /usr/lib/libext2fs.so
instead of header files (incase we use dynamic libs)

regards,
aq

  reply	other threads:[~2005-05-24  1:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-18 19:37 [PATCH] reiserfs module for pygrub Ian Pratt
2005-05-19  1:15 ` aq
2005-05-23 23:57 ` Jeremy Katz
2005-05-24  1:04   ` aq [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-05-24  1:27 Ian Pratt
2005-05-24  3:17 ` Jeremy Katz
2005-05-24  4:09   ` aq
2005-05-24  4:15   ` aq
2005-05-24 19:34     ` Jeremy Katz
2005-05-25 21:57       ` aq
2005-05-24  0:14 Ian Pratt
2005-05-24  3:17 ` Jeremy Katz
2005-05-19  1:32 Ian Pratt
2005-05-19  2:43 ` aq
2005-05-18 18:46 aq
2005-05-23 23:57 ` Jeremy Katz

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=9cde8bff05052318046fdb3e7b@mail.gmail.com \
    --to=aquynh@gmail.com \
    --cc=katzj@redhat.com \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.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.