oem-config isn't removed after completion

Bug #210779 reported by Sense Egbert Hofstede
4
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Binary package hint: oem-config

I just discovered while updating my system that oem-config and it's helppackages(gtk) aren't removed after completion of the setup. I see no reason why they should be kept. Is there a way to remove them after the config has been successfully finished?

Tags: oem-config
Revision history for this message
Colin Watson (cjwatson) wrote :

Right. I think I was reluctant to do this just in case something went wrong and removing it impeded somebody's ability to figure it out.

Seems like a reasonable wish, though.

Changed in oem-config:
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Loye Young (loyeyoung) wrote :

I disagree that this is a bug; I would vote to keep current behavior.

oem-config does no harm if installed, but comes in very handy if the original user's account gets hosed up or if the user wants to return the box to its initial state. In addition, current allows the system builder to test the configuration. For testing, simply run the oem-config-prepare script and reboot. When prompted for the user name, enter "oem". By doing so, the builder can work through as many iterations at needed to perfect the system setup.

Having said that, I recognize that oem-config is a work in progress and that additional capabilities are in the works. Perhaps it's possible to have our cake and eat it too.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

Revision history for this message
Colin Watson (cjwatson) wrote :

Wow. I must admit I had never thought of entering 'oem' for the user name ...

Revision history for this message
Mario Limonciello (superm1) wrote : Re: [Bug 210779] Re: oem-config isn't removed after completion

Loye Young wrote:
> I disagree that this is a bug; I would vote to keep current behavior.
>
> oem-config does no harm if installed, but comes in very handy if the
> original user's account gets hosed up or if the user wants to return the
> box to its initial state. In addition, current allows the system builder
> to test the configuration. For testing, simply run the oem-config-
> prepare script and reboot. When prompted for the user name, enter "oem".
> By doing so, the builder can work through as many iterations at needed
> to perfect the system setup.
>
> Having said that, I recognize that oem-config is a work in progress and
> that additional capabilities are in the works. Perhaps it's possible to
> have our cake and eat it too.
>
> Happy Trails,
>
> Loye Young
> Isaac & Young Computer Company
> Laredo, Texas
> http://www.iycc.biz
>
Well i disagree that it does no harm in leaving it on the system. A link is
left in System->Administration to prepare the system for shipping to the end
user. Maybe the happy medium is to preseed something during installation to
determine whether oem-config is removed or left intact after it's run.

This would then allow testing the system and improving it's setup.

--
Mario Limonciello
<email address hidden>

Revision history for this message
Loye Young (loyeyoung) wrote :

> A link is left in System->Administration

I would be glad if we got rid of that link and the desktop icon altogether.
oem-config is not something that needs a GUI interface. Anyone using
oem-config needs to know what he or she is doing and should be sophisticated
enough to use the command line, IMHO.

Happy Trails,

Loye

Revision history for this message
Sense Egbert Hofstede (sense) wrote :

oem-config and oem-config-gtk are removed when you execute sudo apt-get autoremove. So the system knows that they aren't needed, but they just don't do anything.

Revision history for this message
Loye Young (loyeyoung) wrote :

>oem-config and oem-config-gtk are removed when you execute sudo apt-get
>autoremove.

If it does, apt-get has a bug. oem-config is intentionally installed, so
apt-get's "autoremove" should not work. The auto-remove switch of apt-get
should only apply to packages that were originally automatically installed
to satisfy dependencies. It has nothing to do with whether the oem-config
application is needed .

<off-topic rant>
This is actually yet another reason that apt-get is deprecated upstream in
favor of aptitude and why folks should not use apt-get. But I digress.
</off-topic rant>

>So the system knows that they aren't needed, but they just
>don't do anything.

The above statement should read "So the system
_thinks_they_were_installed_as_dependencies_ . . . ."

If personality($Writer ) = "obnoxious"
     If memstatus(off-topic rant) = "not in reader's memory"
          Read (off-topic rant);
     else
          echo "See what I mean?";
          GoTo HappyTrails;
     fi;
else
     GoTo HappyTrails;
fi;

Happy Trails,

Loye Young

On Sun, Apr 6, 2008 at 4:58 AM, Sense Hofstede <email address hidden> wrote:

> oem-config and oem-config-gtk are removed when you execute sudo apt-get
> autoremove. So the system knows that they aren't needed, but they just
> don't do anything.
>
> --
> oem-config isn't removed after completion
> https://bugs.launchpad.net/bugs/210779
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
(956) 857-1172
<email address hidden>

Revision history for this message
Loye Young (loyeyoung) wrote :

See also Bug 251056.

Colin Watson (cjwatson)
affects: oem-config (Ubuntu) → ubiquity (Ubuntu)
tags: added: oem-config
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.1.11

---------------
ubiquity (2.1.11) lucid; urgency=low

  [ Evan Dandrea ]
  * Remove ubiquity on successful completion of oem-config (LP: #210779).

  [ Didier Roche ]
  * Rebuild needed to take 1.28ubuntu2 user-setup-apply version (LP: #507121)

  [ Colin Watson ]
  * Log calls to partman's freeze_choices and thaw_choices.
  * Revert frozen choices change from 2.1.8. Instead, arrange to thaw
    choices for partman/choose_partition immediately *before* going back to
    it at the end of building the cache, rather than just after it's
    displayed when thawing choices has no immediate effect (LP: #506585).
  * Automatic update of included source packages: partman-base 135ubuntu4,
    user-setup 1.28ubuntu2.
 -- Colin Watson <email address hidden> Sat, 16 Jan 2010 00:31:16 +0000

Changed in ubiquity (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.