opkg in svn?

opkg in svn?

[Richard Purdie]

Hi Paul,

Looking at opkg, I did have one other question. Currently in most builds
we build opkg (either as the package manager or at least for
update-alternatives). 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?

An alternative would be to have good tarball releases we could use
instead?

FWIW, in OE-Core we currently have:

recipes-devtools/installer/adt-installer_1.0.bb~:SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http \
recipes-devtools/installer/adt-installer_1.0.bb:SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http \
recipes-devtools/opkg/opkg_svn.bb:SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http \
recipes-devtools/ubootchart/ubootchart_svn.bb:SRC_URI = "svn://ubootchart.googlecode.com/svn/;protocol=http;module=trunk \
recipes-multimedia/tremor/tremor_20120314.bb:SRC_URI = "svn://svn.xiph.org/trunk;module=Tremor;rev=18221;protocol=http \
recipes-sato/puzzles/puzzles_r9765.bb:SRC_URI = "svn://svn.tartarus.org/sgt;module=puzzles;rev=${MOD_PV}"

so opkg is three of the remaining six svn references and is by far the
most significant factor in builds.

Cheers,

Richard

Re: opkg in svn?

[Burton, Ross]

On 18 November 2013 12:03, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> recipes-sato/puzzles/puzzles_r9765.bb:SRC_URI = "svn://svn.tartarus.org/sgt;module=puzzles;rev=${MOD_PV}"

Seems like a pretty good reason to ditch puzzles, IMHO.

Ross

Re: opkg in svn?

[Richard Purdie]

On Mon, 2013-11-18 at 12:33 +0000, Burton, Ross wrote:
> On 18 November 2013 12:03, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > recipes-sato/puzzles/puzzles_r9765.bb:SRC_URI = "svn://svn.tartarus.org/sgt;module=puzzles;rev=${MOD_PV}"
> 
> Seems like a pretty good reason to ditch puzzles, IMHO.

Somehow I knew you'd say that. I still maintain those make a great
demo/test app. I'm sure we could just point at a tarball by default for
this ;-).

Cheers,

Richard

Re: opkg in svn?

[Burton, Ross]

On 18 November 2013 12:48, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2013-11-18 at 12:33 +0000, Burton, Ross wrote:
>> On 18 November 2013 12:03, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> > recipes-sato/puzzles/puzzles_r9765.bb:SRC_URI = "svn://svn.tartarus.org/sgt;module=puzzles;rev=${MOD_PV}"
>>
>> Seems like a pretty good reason to ditch puzzles, IMHO.
>
> Somehow I knew you'd say that. I still maintain those make a great
> demo/test app. I'm sure we could just point at a tarball by default for
> this ;-).

Isn't puzzles the upstream that re-generates tarballs so the checksums
suddenly change?

Ross

Re: opkg in svn?

[Saul Wold]

On 11/18/2013 06:21 AM, Burton, Ross wrote:
> On 18 November 2013 12:48, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Mon, 2013-11-18 at 12:33 +0000, Burton, Ross wrote:
>>> On 18 November 2013 12:03, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>> recipes-sato/puzzles/puzzles_r9765.bb:SRC_URI = "svn://svn.tartarus.org/sgt;module=puzzles;rev=${MOD_PV}"
>>>
>>> Seems like a pretty good reason to ditch puzzles, IMHO.
>>
>> Somehow I knew you'd say that. I still maintain those make a great
>> demo/test app. I'm sure we could just point at a tarball by default for
>> this ;-).
>
> Isn't puzzles the upstream that re-generates tarballs so the checksums
> suddenly change?
>
Yup, that's the one, and they don't keep the older tarballs around 
either, a real pain!

Sau!

> Ross
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

Re: opkg in svn?

[Paul Barker]

On 18 November 2013 12:03, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Hi Paul,
>
> Looking at opkg, I did have one other question. Currently in most builds
> we build opkg (either as the package manager or at least for
> update-alternatives). 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?
>
> An alternative would be to have good tarball releases we could use
> instead?
>

The answer is yes to both of these. In my queue of patches to oe-core
which I'm currently testing is an update to the opkg-0.2.0, downloaded
as a tarball instead of from svn.

I'm also trying to organise git hosting for opkg within Yocto Project,
I think I'm waiting to hear back from Michael Halstead on a couple of
questions.

It's just a bit slow going as I'm very busy with other work at the
minute. I can send the patches I have as RFCs if someone else has time
to test them - I know opkg-0.2.0 builds correctly, I just haven't had
time to generate a package feed and try to do a live update of
something on a real board running opkg-0.2.0. It's on my todo list but
it may be a few days or weeks before I find time to test this out.

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: opkg in svn?

[Robert Calhoun]

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.

>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.

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!




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?

-Rob Calhoun

Re: opkg in svn?

[Phil Blundell]

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.

True.  On the other hand, anybody who is enthusiastic enough about svn
to use it internally probably has a good enough copy on their system
already that they could add it to ASSUME_PROVIDED.

p.

Re: opkg in svn?

[Richard Purdie]

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