From: Martin Jansa <martin.jansa@gmail.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [RFC] git: add BB_FETCH_PREMIRROR_READONLY option
Date: Tue, 30 Apr 2013 16:46:42 +0200 [thread overview]
Message-ID: <20130430144642.GD3184@jama> (raw)
In-Reply-To: <20732985.qIsTObyanK@helios>
[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]
On Tue, Apr 30, 2013 at 01:57:42PM +0100, Paul Eggleton wrote:
> On Tuesday 30 April 2013 12:52:40 Martin Jansa wrote:
> > * just RFC, because I haven't even tested this change,
> > use it only to describe the issue and discuss it
> >
> > * remove symlink to ud.fullmirror when BB_FETCH_PREMIRROR_READONLY is set
> >
> > * with read-only PREMIRROR (e.g. mounted over NFS or CIFS
> > and referenced as file:///mnt/premirror) we cannot use
> > BB_GENERATE_MIRROR_TARBALLS because all git2_abc.git.tar.gz
> > files later became just symlinks to read-only location in PREMIRROR
> > (it works fine on first build and for new components, because
> > at that time there isn't tarball on PREMIRROR yet).
> >
> > ERROR: Fetcher failure: Fetch command failed with exit code 141, output:
> > tar (child): /build/downloads/git2_abc.git.tar.gz: Cannot open: Read-only
> > file system tar (child): Error is not recoverable: exiting now
> >
> > * maybe we can change the default behavior and always remove symlink
> > without introducing new option
>
> Personally I think it would be better to do the latter.
Only case when keeping old behavior is IMHO desirable is when someone
is using file:// and wants tar.gz updated in original location (e.g. to
rsync less from downloads directory after build).
But it won't update all (e.g. new components which don't have symlinks
yet) so rsync is still needed and usefulness of such requirement is quite low.
Cheers,
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2013-04-30 15:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-30 10:52 [RFC] git: add BB_FETCH_PREMIRROR_READONLY option Martin Jansa
2013-04-30 12:57 ` Paul Eggleton
2013-04-30 14:46 ` Martin Jansa [this message]
2013-05-03 15:58 ` [PATCHv2] git: remove symling before updating mirror tarball Martin Jansa
2013-05-07 16:39 ` [PATCHv3] " Martin Jansa
2013-05-07 21:51 ` Martin Jansa
2013-05-07 22:10 ` Martin Jansa
2013-05-10 9:35 ` Martin Jansa
2013-05-10 12:32 ` Richard Purdie
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=20130430144642.GD3184@jama \
--to=martin.jansa@gmail.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.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.