CSSU is still testing, see http://wiki.maemo.org/Community_SSU
It is still not for end-user, is for power-user, developers...

So this bug is in unstable CSSU release irelevant. You do not have to install
CSSU, if you want stable software.

Yeah, and I can just stay with an older version. Lame answer.
If you actually want some real-world testers, you need to give them the option
to go back to stable versions while the bugs are being ironed out.
It's not like camera-ui2 was needed by anything else in the CSSU as of now.

The point here isn't that camera-ui2 isn't quite ready yet. That's been
established and I don't have a problem downgrading it manually. (In fact, I
have both the stock and ui2 debs to do some side-by-side testing.)
The point is that until the software that's included reaches a certain measure
of stability, and as long as it isn't absolutely neccessary for something else,
users/testers need the option to switch to an earlier version of the software
without having to downgrade the whole CSSU, even if only to be able to do
side-by-side comparisons.

With the current CSSU I either need to downgrade the whole CSSU or get my
system into an inconsistent state if I want to compare the stock camera-ui and
camera-ui2 for testing and bug reporting purposes.

Comment 3 Andrew Flegg 2011-05-03 10:46:39 UTC

(In reply to comment #2)
> 
> With the current CSSU I either need to downgrade the whole CSSU or get my
> system into an inconsistent state if I want to compare the stock camera-ui and
> camera-ui2 for testing and bug reporting purposes.

I agree entirely - if something can be a separate add-on, it should be left out
until it reaches a certain level of maturity. Suggestions and discussions on
how (and who) should make that decision are welcome, perhaps starting at
http://wiki.maemo.org/Community_SSU/QA. Certainly, an aggressive tone on a bug
report isn't going to help things.

However, it's worth considering that your aims are a little contradictory. To
allow easier downgrading, camera-ui2 could use the same package name and the
meta-package depend on the package, rather than a version of it. However, this
would then inhibit side-by-side testing unless you built the source manually.

Have you got an idea as to how it might work? If camera-ui2 (and other open
source replacements) are to be included in the CSSU one day, the wider testing
is required at some point...

(In reply to comment #3)
> an aggressive tone on a bug
> report isn't going to help things.

I didn't mean to sound aggressive - if I did, I'm sorry.

> However, it's worth considering that your aims are a little contradictory. To
> allow easier downgrading, camera-ui2 could use the same package name and the
> meta-package depend on the package, rather than a version of it. However, this
> would then inhibit side-by-side testing unless you built the source manually.

True side-by-side testing isn't possible with the way Nokia chose to launch
camera-ui, if I understood that correctly. My current method is to simply
install one, do some tests, record my results and then install the other and
repeat the process.

To that end, using the same package name with a slightly different version
number (which is the way it is done now) is fine by me, but the fact that the
CSSU depends on the ui2 version is somewhat annoying, especially since changing
the dependency back to the stock camera-ui version isn't difficult and would
mean that everybody else would still get the current version of camera-ui2.
Since it is likely that the CSSU will want to depend on a later version of
camera-ui2 at some point in time, the depends field could be set to
(camera-ui="stock version" | camera-ui>="current version"). The deb package
format is very flexible in this regard.

> Have you got an idea as to how it might work? If camera-ui2 (and other open
> source replacements) are to be included in the CSSU one day, the wider testing
> is required at some point...

I don't think you can do true side-by-side installs in all cases, if only
because some applications need an exclusive lock on a resource the two versions
would have to share. In those cases, keeping a >= dependency on the original
package (be that stock or some other stable version) and simply giving the
replacement the same package name with a higher version number, probably is the
only way to go.

In other cases, where a true side-by-side install is possible, the metapackage
should just depend on either of them (as in a logical or dependency; set the
depends field to (package | replacement) and when the replacement is ready,
make it conflict with and replace the original package as well as changing the
depends field in the metapackage to only depend on the replacement.


I hope I've been able to express myself clearly (and without sounding
aggressive ;-)) - English is *not* my first language.

Comment 5 Andrew Flegg 2011-05-03 12:57:45 UTC

Very helpful, thank you. Apologies for the "aggressive" comment (your English
is faultless)

Your solution of the OR (including on the stock version or >= the replacement)
in mp-fremantle-community-pr sounds great. However, we might need to be careful
because of the way HAM sometimes bypasses apt for parsing control files :-(

(In reply to comment #5)
> However, we might need to be careful
> because of the way HAM sometimes bypasses apt for parsing control files :-(

I was afraid you might bring that up. Since I have no idea what HAM does in
this case (I prefer to use apt-get from the command line), somebody who does
needs to comment, or, if nobody knows, somebody will have to run some tests
(since my schedule is pretty packed for the next few months, I, unfortunately,
won't be able to do it).

Should HAM not support this, we'll just have to wait for a replacement... :-P

As stated above, camera-ui isn't any component that's relevant for cssu
working.
According to general rule of cssu it mustn't get included as it as well can get
deployed via maemo(-devel). Actually augmenting the package by a simple
selector app or plugin for settings, to make the symlink
lrwxrwxrwx 1 root root     22 2011-03-06 21:41 /usr/bin/camera-ui ->
/usr/bin/maemo-invoker
point to either the new camera or to stock camera which is actually
"/usr/bin/maemo-invoker" is utterly straightforward and simple, and offers a
perfect path to deploy new camera-ui alternatives via maemo repo system.

The problem of cssu deinstalling and deleting
-rwxr-xr-x 1 root root 278852 2010-07-27 10:29 /usr/bin/camera-ui.launch
is the mayor issue right now, and needs *immediate* fixing by first of all
creating a backup of of the executable so it can get re-used later on without
need for a complete reflash to stock maemo or installing fremantle-mp

cp /usr/bin/camera-ui.launch /usr/bin/camera-ui.launch_fremantle
shall get called by some pre-install script of cssu. This patch is needed NOW
to avoid more user systems out there losing a sane way to revert to stock
camera app

camera-ui upgrade will be avaiable as optional component in the stable cssu
when the current version in testing is approved as stable.

This won't get optional for testing since with the introduction of stable
testing is not the only choice anymore and lives as a testground for future
packages in stable, therefore testing will always include all cssu bleeding
edge packges in order to test everything.

Closing this as fixed

(In reply to comment #8)
> This won't get optional for testing since with the introduction of stable
> testing is not the only choice anymore and lives as a testground for future
> packages in stable, therefore testing will always include all cssu bleeding
> edge packges in order to test everything.

You seem to be missing the point here: the problem is not potential unstable
versions for testing, it is the fact that this makes a side-by-side comparison
with the stock version impossible. And that is something that needs to be done
in testing, not in stable. (see the comments above; I'll try to come up with a
better summary as I apparently can't adapt the description)

> Closing this as fixed

Leaving this for now, but if you don't find a good reason for leaving this
closed or an actual fix, I'll have to re-open it.

(In reply to comment #9)
> (In reply to comment #8)
> > This won't get optional for testing since with the introduction of stable
> > testing is not the only choice anymore and lives as a testground for future
> > packages in stable, therefore testing will always include all cssu bleeding
> > edge packges in order to test everything.
> 
> You seem to be missing the point here: the problem is not potential unstable
> versions for testing, it is the fact that this makes a side-by-side comparison
> with the stock version impossible. And that is something that needs to be done
> in testing, not in stable. (see the comments above; I'll try to come up with a
> better summary as I apparently can't adapt the description)
> 
> > Closing this as fixed
> 
> Leaving this for now, but if you don't find a good reason for leaving this
> closed or an actual fix, I'll have to re-open it.

I'm having a hard time discussing/arguing with freemangordon about it, but *my*
idea is we get a way for user to *choose* what's default app (the one launched
when opening lens slider). As soon as this selection-picker is implemented in
settings->(whatever_camera), I won't mind what's the default that CSSU-S ships
with. I hope for a way to test the picker in Testing.
See my last post in this ticket - it has all the tech details.
CSSU is about freedom of choice, not about shoving down the throat of users sth
that somebody considers best. We already had that, no need for more.

/j

Comment 11 Andre Klapper 2011-12-01 09:00:57 UTC

CSSU testing project has the right to replace any packages. It is not a bug
that previous packages are not available anymore for comparison.

(In reply to comment #11)
> CSSU testing project has the right to replace any packages. It is not a bug
> that previous packages are not available anymore for comparison.

Personally, I think the fact that I can't do side-by-side testing to ensure
that the replacement provides at a minimum the functionality of the original
and to perhaps spot any difference in how things are done/implemented, *is* a
bug.
Now, if this was about stable, I'd agree with you, but it isn't.

This report could be regarded as an enhancement request, but personally I think
that having to break the packaging system's dependency handling for this very
basic and necessary functionality is a bug.

Reopening since neither an obvious fix nor an explanation how this is fixed has
been given.
Discussion so far neither shows a fix nor does it point to this bug being
invalid.