[needs-packaging] Get cordova-ubuntu-3.4 into trusty release

Bug #1279814 reported by Daniel Holbach on 2014-02-13
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cordova Ubuntu
Critical
Daniel Holbach
Ubuntu
Wishlist
Unassigned

Bug Description

We want cordova-ubuntu-3.4 into the trusty release.

Related branches

Daniel Holbach (dholbach) wrote :

Missing:

 - explanation how the source was put together
 - update of d/copyright

Daniel Holbach (dholbach) wrote :

/usr/share/cordova-ubuntu-3.4/embed-in-click/ (or some such) might be a bit more obvious location. To be changed at some stage.

Daniel Holbach (dholbach) wrote :

1) d/copyright is done in r13 of ~dholbach/cordova-ubuntu/3.4-packaging (see MP).
2) Can we add a note how the source was put together, so the next person to touch the source knows how to do it? David?
3) I'd personally suggest to change the install path to something along the lines of "/usr/share/cordova-ubuntu-3.4/embed-in-click/", but I'll leave the decision to David (and archive admins if they deem this an issue).

Brian Murray (brian-murray) wrote :

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

summary: - Get cordova-ubuntu-3.4 into trusty release
+ [needs-packaging] Get cordova-ubuntu-3.4 into trusty release
Changed in ubuntu:
importance: Undecided → Wishlist
Daniel Holbach (dholbach) wrote :

2) was solved as well (r16), thanks David.

Daniel Holbach (dholbach) wrote :

Sitting in binary new

Changed in cordova-ubuntu:
status: New → Fix Released
Changed in ubuntu:
status: New → Fix Committed
Maxim Ermilov (zaspire) wrote :

from previous discussions:
1. package should not contain cordova-ubuntu/cordova in its name
2. all files should be in /usr/share/__something__ (should not contain cordova in path)

Changed in cordova-ubuntu:
status: Fix Released → In Progress
Maxim Ermilov (zaspire) wrote :

I rename branch to "container", because It unrelated to 3.4.

Maxim Ermilov (zaspire) on 2014-02-17
Changed in cordova-ubuntu:
assignee: nobody → Daniel Holbach (dholbach)
importance: Undecided → Critical
Daniel Holbach (dholbach) wrote :

I'll file a new bug report to discuss the naming of the path.

Changed in cordova-ubuntu:
status: In Progress → Fix Committed
Daniel Holbach (dholbach) wrote :

Discussion in #ubuntu-devel when accepting the binaries of this build:

<seb128> dholbach, the cordova binaries are a bit weird, they install their .so in /usr/share ... is that wanted?
<infinity> It's never wanted.
 Unless those are magical arch-indep libraries.
<seb128> that package is quite hackish, I don't like much
<seb128> but I'm not wanting to fight over details since I don't have a better suggestion/I'm not interested enough into the topic to spend efforts on it
<infinity> If they're not following FHS, that's absolutely a reason to reject.
<seb128> infinity, they are not, but that package is weird, it's basically a "provide files for clicks to copy/embed"
<infinity> Ahh, binaries in /usr/share make sense in that context. But they still shouldn't overlap between arches, if they currently do.
<seb128> /usr/share/cordova-ubuntu-3.4/www/libcoreplugins.so
 so yeah, they do
<infinity> Yeah, so no indication of what arch that .so is for...
<seb128> dholbach, can we get that fixed?
<infinity> It's not multi-arch:same, of course, so there's allowed to be overlap. It just seems like a bit of a messy design.
<seb128> infinity, feel free to accept the binaries from the queue if you are fine with them ;-)
* seb128 has no strong opinion, as said that package is a bit hackish
<seb128> but if it does the job/unblock people...
<infinity> I'd probably want to talk to the people behind it to get more context before I accepted them. Which I'm unlikely to do at 4am after working all weekend.
<seb128> infinity, yeah, you should get some sleep!
 infinity, have a good night
<infinity> seb128: I'll try. :)
<dholbach> seb128, AFAIK (I'm just trying to help the team get things landed): the SDK will download <package>:<arch> from the archive and bundle that the runtime in the click package
<seb128> dholbach, what if you try to dev for e.g i386 and armhf on the same machine?
<seb128> those conflict atm
<dholbach> seb128, AFAIK they're not necessarily required to be installed on the developers machine, but I might be wrong
<seb128> well, they are in the archive, so nothing prevent you to apt-get install them
<dholbach> dbarth and team would be the people to answer this - maybe we should discuss it on https://launchpad.net/bugs/1279814?
<ubottu> Launchpad bug 1279814 in Cordova Ubuntu "[needs-packaging] Get cordova-ubuntu-3.4 into trusty release" [Critical,Fix committed]
<seb128> well, as said before, I'm busy enough with other things and I don't know much about the cordova thing
<dholbach> ok
<seb128> so I'm going to letting infinity a chance to comment on that later on, and if he doesn't I think I'm just going to wave the binaries in
 they are a bit hackish/wrong but that's not the end of the world imho

Daniel Holbach (dholbach) wrote :

If this is deemed a blocker, we should fix bug 1281012 at the same time.

Daniel Holbach (dholbach) wrote :

Maxim, Alex, David: can you comment on the discussion between Séb and Adam?

Maxim Ermilov (zaspire) wrote :

path "/usr/share/ubuntu-container-3.4/__ARCH_NAME__/" will fix both issues

Daniel Holbach (dholbach) wrote :

The list of currently installed files is:

/usr/share/cordova-ubuntu-3.4/qml/CordovaView.qml.in
/usr/share/cordova-ubuntu-3.4/qml/main.qml
/usr/share/cordova-ubuntu-3.4/qml/main.qml.in
/usr/share/cordova-ubuntu-3.4/www/libcoreplugins.so
/usr/share/cordova-ubuntu-3.4/www/cordova.js
/usr/share/cordova-ubuntu-3.4/CordovaUbuntu.3.4/cordova_wrapper.js
/usr/share/cordova-ubuntu-3.4/CordovaUbuntu.3.4/CordovaViewInternal.qml
/usr/share/cordova-ubuntu-3.4/CordovaUbuntu.3.4/qmldir
/usr/share/cordova-ubuntu-3.4/CordovaUbuntu.3.4/CordovaView.qml
/usr/share/cordova-ubuntu-3.4/CordovaUbuntu.3.4/libcordovaubuntuplugin.so
/usr/share/cordova-ubuntu-3.4/cordova-ubuntu
/usr/share/doc/cordova-ubuntu-3.4-dev/changelog.gz
/usr/share/doc/cordova-ubuntu-3.4-dev/README.Debian
/usr/share/doc/cordova-ubuntu-3.4-dev/copyright

Maxim, David, Alex, Adam: where do you suggest which file goes?

Adam: do you suggest that just the .so file and the binary go somewhere else or that everything moves? Do you think it'd help to have some kind of "/embed-in-click/" in the path name, so it would make the purpose of the files clearer?

Maxim: do you also suggest that the binary package name changes? If we don't indicate (via the binary package name) that big parts of the code come from the Cordova project, do you still think it makes sense to have '3.4' in the package name? I guess it could help with a switch to newer runtime in the future.

Let's settle for something like:

/usr/share/ubuntu-container-3.4/__ARCH_NAME__/

as suggested by Maxim, since it'll make things less cordova related, and cleaner from an outside's perspective.

Before we do anything, let me update the various branches that depend on this and add them to this bug. I'll ask David & Daniel to review them,

Daniel: the 3.4. is fine to me, it might seem odd, but 1. does not harm, 2. doesn't prevent us from reverting that from the future, 3. might allow us to selectively check which version to add to the click, (IMO obviously)

Daniel Holbach (dholbach) wrote :

With the changes from Alex we get the following file names: http://paste.ubuntu.com/6953343/ and ubuntu-html5-platform-3.4-dev as the binary package name.

David Barth (dbarth) wrote :

And again, to make it very clear: this runtime is like a firmware. It is not meant to be installed or used on a live system. The .so files are meant to be injected into a click pacakge.

The packages are downloaded, files extracted and copies over to a click package build directory. They should NOT be installed.

The reason we use a .deb container is to re-use all of the good build and distribution infrastructure and ensure that what we inject into a click package respects the same quality criteria as the rest of the system (source code, versioning, revision control, signatures, support for multiple architectures, etc.)

Changed in cordova-ubuntu:
status: Fix Committed → Fix Released
Changed in ubuntu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers