[blfs-dev] Possible BLFS systemd solution
lfs65 at cruziero.com
Mon Jun 30 02:12:08 PDT 2014
> Date: Mon, 30 Jun 2014 03:31:32 +0200
> From: "Armin K." <krejzi at email.com>
> To: BLFS Development List <blfs-dev at lists.linuxfromscratch.org>
> Subject: Re: [blfs-dev] Possible BLFS systemd solution
> On 06/30/2014 03:00 AM, akhiezer wrote:
> > Armin: why not cut the gordian knot, and setup a git repo for blfs-systemd
> > and lfs-systemd, and the requisite git/svn bridges to/from 'traditional'
> > b/lfs svn: that would be a much better foundation; and I'd bet you _would_
> > build up a healthy lot of contribs to those sysd projects. I think that
> > part of the problem here is that you are trying to constrain yourself to
> > work within an unsuitable framework - you're almost being not bold enough
> > on the matter.
> I have tried this. BLFS repository is kinda "damaged" and git-svn bridge
> would fail to update. I haven't investigated the right reason since I
> got tired after waiting for several hours to create git-svn clone (7+
Perhaps Pierre could input on that: iirc/aiui Pierre uses git/svn 'ongoingly'
for working with lfs &/or blfs.
Even if you did get git/svn setup ok, &/or the real/perceived blfs 'damaged'
getting fixed (and even staying fixed for a while), the ongoing 'risk'
of course is that one is always kindof at the mercy of what 'upstream'
(here, main blfs) might do, and how it might break or otherwise entail
changes to, your setup. Also of course, such bridge-tools don't always work
'properly' anyway (tell me about it - './adb pull', anyone ... !$*^) .
A common approach to such a situation is: it's perhaps worth bearing in
mind that very often one only really needs the diffs; & so an option could
be to keep a native svn locally, generate the diffs, and (cherry-pick)
import/apply them into git; and similarly for the output from git; and
all automated - quite readily - of course.
> Note: My last name is not Krejzi.
More information about the blfs-dev