linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@MIT.EDU>
To: Matthias Koenig <mkoenig@suse.de>
Cc: linux-ext4@vger.kernel.org, hvogel@suse.de,
	Girish Shilamkar <Girish.Shilamkar@Sun.COM>,
	Eric Sandeen <esandeen@redhat.com>
Subject: Re: Integrating patches in SLES10 e2fsprogs
Date: Tue, 29 Jan 2008 09:35:37 -0500	[thread overview]
Message-ID: <20080129143537.GH6774@mit.edu> (raw)
In-Reply-To: <n7xd4rkn3hx.fsf@sor.suse.de>

On Tue, Jan 29, 2008 at 02:52:10PM +0100, Matthias Koenig wrote:
> > Are you running aclocal?  That may be causing the issues since I think
> > that may be causing it to ignore the autoconf macros I've established
> > in the top-level aclocal.m4 file.
> 
> Yes, someone here fixed the german po file (I already sent it to
> translation project). So we have to rerun the
> gettext related part, which results in the requirement to rerun aclocal.

Hmm?  You should be able to rebuild the .gmo file without needing to
re-run aclocal.  I do it all the time.  :-)

> > The problem is that the FHS does not guarantee that the subdirectories
> > stick around, and a number of distro's are using mounting tmpfs for
> > /var/run.  Makes sense, it can significantly speed up operations ---
> > but upon reboot, everything in /var/run is *gone*.
> 
> I see, then there is a problem of course. This is not the way it is
> done in Suse, so I did not see this problem.
> But, shouldn't the daemon then have an rc init script which checks for
> the needed subdirectory in /var/run and creates this if necessary?  If I
> look into /var/run I see a lot of daemons running with their own UID/GID
> and having their own directory. In this case there must be a mechanism
> to guarantee the existence of this directory, which would obviously be
> done in the init script (not sure if any init scripts currently do this
> in Suse).

Well, it either needs to be done in the init script or the daemons run
with root privs, create the directory, and then drop root privs.  So
yes, there are alternatives.  (a) Yet Another init script, (b) setuid
root, with a hard-coded user name that has to be looked up via
getpwent() and configured into /etc/passwd or the LDAP server, (c)
just put the darned directory in /var/lib.

It's all about tradeoffs, and for me, (c) was the easist, especially
since /var/lib/libuuid/clock.txt needs to be persistent across boots
anyway, and so needs to be in /var/lib instead of /var/run.  So yes, I
could have created some machinery to make sure /var/run/uuidd is
always present, but why not just reuse the already existing
/var/lib/libuuid directory, which has the correct ownership and which
has to be in /var/lib anyway?

> > and I still haven't figured out how to easily build my own
> > custom kernel RPM's on OpenSUSE, but it's quite nice.
> 
> unfortunately we don't have make-kpkg.

Yeah, and the RPM macros for generating kernel are incredibly twisted.
At least they were for RHEL4, when I was figuring out how to generate
a real-time kernel rpm.  Serious temptations to gouge out my eyeballs
with a spoon by the time I was done....

       	     					- Ted

      reply	other threads:[~2008-01-29 14:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-24 21:17 Integrating patches in SLES10 e2fsprogs Andreas Dilger
2008-01-24 21:27 ` Eric Sandeen
2008-01-25 15:22 ` Matthias Koenig
2008-01-27  5:05   ` Theodore Tso
2008-01-27 15:06     ` Eric Sandeen
2008-01-27 20:27       ` Theodore Tso
2008-01-28  4:40         ` Eric Sandeen
2008-01-28  5:24           ` Theodore Tso
2008-01-28  5:43             ` Eric Sandeen
2008-01-28 16:01             ` Thierry Vignaud
2008-01-28 16:06               ` Thierry Vignaud
2008-01-28 17:03                 ` Theodore Tso
2008-01-28 17:00               ` Theodore Tso
2008-01-28 15:26     ` Matthias Koenig
2008-01-28 15:38       ` Theodore Tso
2008-01-28 16:54         ` Eric Sandeen
2008-01-28 20:59           ` Andreas Dilger
2008-01-29 13:52         ` Matthias Koenig
2008-01-29 14:35           ` Theodore Tso [this message]

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=20080129143537.GH6774@mit.edu \
    --to=tytso@mit.edu \
    --cc=Girish.Shilamkar@Sun.COM \
    --cc=esandeen@redhat.com \
    --cc=hvogel@suse.de \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mkoenig@suse.de \
    /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).