Comment 1 Eric Warnke 2008-08-12 23:26:44 UTC

I can confirm on my system that Maemo extras was disabled after installing
4.2008.30-2

Comment 2 Marcell Lengyel 2008-08-12 23:34:23 UTC

Marius, could you take a look?

Comment 3 Ryan Abel (reporter) 2008-08-12 23:40:42 UTC

If Nokia was going to screw around with my repositories list anyway, the least
they could've done was to fix the branding on _maemo.org_ Extras. :\

bug #3307

I agree that this is a clear problem and we will take action on this. Thank you
for reporting the issue.

Comment 5 Ryan Abel (reporter) 2008-08-18 03:58:53 UTC

*** Bug 3603 has been marked as a duplicate of this bug. ***

Comment 6 Eero Tamminen 2008-08-18 13:21:49 UTC

I don't think this is easyfix especially if this is about user settings
in general and not just repositories.  There may be other packages that
don't yet handle upgrading of user changed end-user changable settings
correctly (I mean doing it in package upgrades instead of just in backup
restore).

Comment 7 Marius Vollmer 2008-08-18 13:50:34 UTC

Yep, we screwed this one up, sorry about that.

The fundamental problem is that we weren't clear which part of the repository
configuration are user settings and which aren't.  We clearly want to be able
to update the real Nokia catalogues via packages, but we shouldn't mess with
user modifications.

This is a going to be a problem for many settings in the maemo platform, and we
have cobbled together a policy document to deal with this:

https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/doc/packpol-conf.txt?revision=1215&root=hildon-app-mgr&view=markup

This is being implemented for the Application manager right now in the
'predefined_catalogues' branch:

https://garage.maemo.org/plugins/scmsvn/viewcvs.php/branches/predefined_catalogues/?root=hildon-app-mgr

See the "Clean up pre-defined catalogues mechanics" entry in
https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/FUTURE?revision=1292&root=hildon-app-mgr&view=markup
for a short description.

Essentially, the Enabled/disabled flag will be treated as user data and will no
longer be touched when updating the OS.

Comment 8 Ryan Abel (reporter) 2008-08-18 14:07:32 UTC

(In reply to comment #7)
> The fundamental problem is that we weren't clear which part of the repository
> configuration are user settings and which aren't.  We clearly want to be able
> to update the real Nokia catalogues via packages, but we shouldn't mess with
> user modifications.
> 

Fair enough, but there isn't any reason to be touching Extras entries for any
SSU updates, anyway. The distribution handles itself automatically (so there's
no need to do anything for Fremantle), and the URL isn't likely to change
anytime soon. . . .

At the very least the package needs to be renamed anyway.

Comment 9 Marius Vollmer 2008-08-18 14:26:58 UTC

(In reply to comment #8)
> (In reply to comment #7)
> Fair enough, but there isn't any reason to be touching Extras entries for any
> SSU updates, anyway.

Maybe, maybe not.  We might want to fix bugs in the localization of the
repository name, for example.

> At the very least the package needs to be renamed anyway.

Hmm, I might split it into two, one for the Nokia repositories and one for
maemo Extras.  The one for maemo Extras can then easily be open sourced.

Comment 10 Ryan Abel (reporter) 2008-09-29 14:36:54 UTC

C'mon guys, really? Again? You couldn't just tweak the package script a
_little_ so we didn't have to go through this nonsense a second time?

Comment 11 Andre Klapper 2008-09-29 15:14:34 UTC

Guess Marius has a lot of other stuff on his todo-list too... :-/

Comment 12 Marius Vollmer 2008-09-29 18:05:35 UTC

(In reply to comment #10)
> C'mon guys, really? Again? You couldn't just tweak the package script a
> _little_ so we didn't have to go through this nonsense a second time?

Crap, slipped thru the cracks.  I'll fix this immediately.

http://flickr.com/photos/tigert/776106528/

Comment 13 Marius Vollmer 2008-09-29 18:07:28 UTC

(In reply to comment #11)
> Guess Marius has a lot of other stuff on his todo-list too... :-/

Yeah, but its all about priorities.

That's one big drawback of the way things happen here: when a new release is
out and the focus of external people, the internal developers have already
switched to the next release for a couple of weeks.

Comment 14 Andrew Flegg 2008-09-30 01:17:33 UTC

/etc/apt/sources.list.d is already being used for the out-of-the-box options.
Perhaps the single file produced by Hildon App Mgr should be split into
"system" and "user".

Out-of-the-box, "user" contains "maemo.org Extras" (disabled, for now) - but
then it's NEVER touched again.

This is the reason, after all, that all the ...conf.d directories were
introduced in "big" Linux: to allow system upgrades to leave user settings
intact.

Comment 15 Marius Vollmer 2008-09-30 13:20:45 UTC

(In reply to comment #14)
> /etc/apt/sources.list.d is already being used for the out-of-the-box options.
> Perhaps the single file produced by Hildon App Mgr should be split into
> "system" and "user".

Yes, something like this is done for Fremantle.  See the 2.2.x release series
of the hildon-application-manager here:

    https://garage.maemo.org/scm/?group_id=122

The catalogue details like name, uri, distribution, etc will be controlled by
packages for the pre-configured catalogues, but the enabled/disabled flag will
be controlled by the user.

I am reluctant to back-port this whole thing to the 2.1.x series of
hildon-application-manager that is in Diablo, so I am looking for some ugly
workarounds now.  It's unfortunately not straightforward since the old value of
the enabled/disabled flag is already erased before the new package has any
chance to look at it...

One easy way out is to just enable Maemo Extra by default.

> This is the reason, after all, that all the ...conf.d directories were
> introduced in "big" Linux: to allow system upgrades to leave user settings
> intact.

No, the directories are there to make it easy for multiple packages to
contribute to a single configuration 'point'.  It's a much preferred
alternative to 'manually' editing a single file.

Keeping user values for a setting separate from system defaults and
distribution defaults for that same setting is done by keeping the user values
somewhere in $HOME and letting them override the system defaults, which are
somewhere in /etc, which in turn override the distribution defaults that are
stored somewhre in /usr/share.  (Or are hidden in a 'conffile'.)

In this particular case, there is no user value: catalogues are system-wide
settings that are maintained by the sysadmin.  (On our device and on other
typical single-user machines like the typical Ubuntu laptop, the user is the
sysadmin, but it's good to keep the two roles separate anyway.)

The failure in Diablo is that the Application manager doesn't keep the sysadmin
value for the disabled/enabled flag separate from the distribution default. 
Both the sysadmin and the distribution are writing into the same space, and end
up fighting over the value.

Comment 16 Marius Vollmer 2008-09-30 16:28:17 UTC

Ok, this should be fixed in nokia-repository 5.9.  Unfortunately, updating from
5.8 to 5.9 will disable maemo Extras one more time, but after that, it
shouldn't happen anymore.

Comment 17 Andre Klapper 2008-10-14 12:58:12 UTC

This was fixed in the internal week41 build.
Any public update released with or after this build version (x.2008.41-x)
should include the fix.

Also see Marius' last comment.

Comment 18 Andre Klapper 2008-12-17 20:20:13 UTC

Fix for this should be included in today's 5.2008.43-7 SSU update.
Please verify the fix by marking this bug report as VERIFIED if you have some
time.

Comment 19 Niels Breet 2008-12-18 10:54:22 UTC

After this SSU (5.2008.43-7) my maemo Extras entry is disabled again.
REOPENING.

Comment 20 Andre Klapper 2008-12-18 11:47:27 UTC

As I wrote: See comment 16. :)
> Ok, this should be fixed in nokia-repository 5.9.  Unfortunately, updating 
> from 5.8 to 5.9 will disable maemo Extras one more time, but after that, 
> it shouldn't happen anymore.

4.2008.36-5 shipped nokia-repository 5.8 and 5.2008.43-7 ships 5.9.