ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

Note: for some reason thunderbird completely and utterly lost Colin's email over
the weekend, but I knew I wanted to respond, so I am responded to a later
message in the thread, but with Colin's response. Sorry if this causes confusion.

> On Sat, Mar 15, 2014 at 5:30 AM, Colin Watson <cjwatson@xxxxxxxxxx> wrote:
>> On Fri, Mar 14, 2014 at 09:48:38PM -0500, Jamie Strandboge wrote:
>> 1. we are going to force everyone to rebuild with ubuntu-sdk-14.04-dev1 (I
>> thought we were going to use ubuntu-sdk-14.04-qml-dev1,
>> ubuntu-sdk-14.04-html-dev1 and ubuntu-sdk-14.04-papi-dev1 anyway...) and then
>> again with ubuntu-sdk-14.04-qml|html|papi in a few weeks. This seems less
>> than ideal.

> Well, firstly, it's rubbish to have missed the splitting; we should get
> the proper frameworks in as soon as you and I are both actually at work.
> If I'd been properly around when we'd been doing this I'd have noticed
> in time ...

ACK, that makes sense. Thankfully I updated click-apparmor to use both the
approved ones and ones like ubuntu-sdk-14.04-dev1 just in case something weird
happened.

> But secondly, there's absolutely no reason why we should drop -dev1
> frameworks from the released image if their ABI hasn't been broken.
> I've made this point before and I think Click/Frameworks encapsulates
> it.  So there's no reason app authors would have to rebuild for that.

Ah, I think I forgot this point. I was thinking we were going to drop the -dev*
ones right before we release, but like you said, we don't have to necessarily
remove them from the image-- we can just change the sdk, review tools, etc for
new uploads to target the official ones.

>> 2. we are asking people to upload apps to the store with a framework
>> (or qt5.2 for that matter) that doesn't yet exist on a promoted image.

> My understanding is that the store will only return results to clients
> that match frameworks they have.

I think at the time I wrote this, the store didn't yet support this, but perhaps
I was mistaken. If it hasn't landed by now I'm guessing it will land very soon.
I was more thinking about the developer trying to update an app before the
framework existed on the target device which is what people were being asked to
do over the weekend (aiui).

Going forward, this probably isn't something to worry about and is probably just
a normal temporary issue when adding frameworks-- the thing is this time we are
doing a number of extraordinary things: obsoleting a framework (13.10) rather
quickly, adding a -dev framework at the same time and then releasing 14.04.
Certainly this won't be nearly as compressed now that we more or less know how
we want to do things in the future.

>>  In theory, they can test the packaging changes by using
>> --force-missing-framework with click install, but does pkcon
>> install-local support that?

> No.

>> (Aside: what will libclick do for base framework and base version if
>> the framework is missing?)

> The framework doesn't exist so you'll never get as far as being able to
> query it.  How that's handled depends on how click-apparmor starts using
> libclick; click itself doesn't use the
> click_framework_get_base_{name,version} functions.

True-- really I think I need to just start using libclick and making some
decisions for these corner cases. I may have more questions, but can discuss
elsewhere.

Thanks!

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature