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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox