From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Robert Calhoun <rcalhoun@shotspotter.com>,
"Eggleton, Paul" <paul.eggleton@intel.com>,
"Rifenbark, Scott M" <scott.m.rifenbark@intel.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: opkg in svn?
Date: Mon, 18 Nov 2013 17:27:46 +0000 [thread overview]
Message-ID: <1384795666.6460.252.camel@ted> (raw)
In-Reply-To: <CEAF8F07.1E9235%rcalhoun@shotspotter.com>
On Mon, 2013-11-18 at 16:21 +0000, Robert Calhoun wrote:
> From: Richard Purdie <richard.purdie@linuxfoundation.org>
>
> >opkg is in svn but its one of the few remaining
> >components we use from svn. It means we have to build subversion-native
> >which has a fairly long dependency chain. It would be nice if we didn't
> >need to so is there any chance we can move opkg to git?
>
> I'm one of the great unwashed who still use subversion internally. For
> these users, removing subversion SRC_URIs from oe-core will not remove the
> need to build subversion-native. I'm not suggesting that oe-core should
> not move away from svn when appropriate, only that many users aren't going
> see much of a performance bump when every last reference is purged.
If you need it for internal usage, you probably don't mind the build
overhead and/or you can use ASSUME_PROVIDED.
I'm not suggesting we drop svn support or anything like that, I would
just prefer to optimise the build where we can and this is looking like
somewhere reasonable to do it now.
> >An alternative would be to have good tarball releases we could use
> >instead?
>
> If opkg doesn't change much, a tarball download will be faster and use
> less disk space than svn checkout. This seems like a good approach.
Agreed, I don't think this hurts anything.
> From: Saul Wold <sgw@linux.intel.com>
> >Yup, that's the one, and they don't keep the older tarballs around
> >either, a real pain!
>
> ...as long as the old tarballs hang around!
This is a case where we can ensure they do I hope! :)
> Documentation on the various SRC_URI fetchers is pretty thin in the yocto
> manuals. The bitbake documentation is also incomplete and it requires 1 GB
> (!) of dependencies to make. I'd be happy to work on better documenting
> SRC_URI syntax; where should this go? A new section under 5.3 of the dev
> manual seems most appropriate:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpo
> ky-extend-addpkg
>
> I assume bitbake's usermanual.xml should be updated as well? There are a
> half-dozen commits in the last two years, so it is neither very active nor
> very dead.
>
> This sort of falls under
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4370 but as that is
> about the OE user manual, should I make a new ticket and assign it to
> myself?
I'd sync with Paul Eggleton on this since I think he and Scott
Rifenbbark are going to figure out how to deal with the bitbake manual
soon. It certainly needs some TLC.
Cheers,
Richard
prev parent reply other threads:[~2013-11-18 17:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 12:03 opkg in svn? Richard Purdie
2013-11-18 12:33 ` Burton, Ross
2013-11-18 12:48 ` Richard Purdie
2013-11-18 14:21 ` Burton, Ross
2013-11-18 15:53 ` Saul Wold
2013-11-18 15:10 ` Paul Barker
2013-11-18 16:21 ` Robert Calhoun
2013-11-18 16:50 ` Phil Blundell
2013-11-18 17:27 ` Richard Purdie [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=1384795666.6460.252.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@intel.com \
--cc=rcalhoun@shotspotter.com \
--cc=scott.m.rifenbark@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.