Installing alien package

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Future package management system wish: more)
m (Suggest un-installation of unused packages: spelling)
 
(22 intermediate revisions by one user not shown)
Line 1: Line 1:
 
==Problem==
 
==Problem==
The problem is that some packages exist in both the fundamental distribution - and other repositories - with same names, but (newer) with other dependencies, other source code includes and other compilation options, which can and often will break the installation.
+
The problem is that some packages exist in both the fundamental [[distribution]] - and other [[repositories]] - with same names, but (newer) with other dependencies, other source code includes and other compilation options, which can and often will break the installation.
  
 
So e.g. do not use "opkg upgrade" when non-distribution (e.g. non-OM2009) repositories are included. It often breaks the installation.
 
So e.g. do not use "opkg upgrade" when non-distribution (e.g. non-OM2009) repositories are included. It often breaks the installation.
  
 
==Solution hack?==
 
==Solution hack?==
Please surround the non-distribution package (alien) install with:
+
Please surround the non-distribution (alien) package install with:
 
# Addition of the required repository
 
# Addition of the required repository
# opkg update # Update database.
+
# [[opkg]] update # Update database.
 
# Install the package(s)
 
# Install the package(s)
 
# remove the non-distribution repository from opkg. E.g. "rm /etc/opkg/opkg-feed.conf"
 
# remove the non-distribution repository from opkg. E.g. "rm /etc/opkg/opkg-feed.conf"
Line 15: Line 15:
 
Wish: Actually the package management system should cope with it. The fundamental distribution with a given version number/revision should have higher precedence, and other repositories should have lesser precedence. Maybe the best would be that the package had a distribution list in which it can be "fundamental".
 
Wish: Actually the package management system should cope with it. The fundamental distribution with a given version number/revision should have higher precedence, and other repositories should have lesser precedence. Maybe the best would be that the package had a distribution list in which it can be "fundamental".
  
Maybe the package management system should consult a check post, so an installer can be informed before installation of the package on the given fundamental distribution:
+
Maybe the [[package management]] system should consult a check post (by name and some checksum), so an installer can be informed before installation of the package on the given fundamental distribution:
 +
*Not tested
 
*Tested
 
*Tested
** Breaks og permanently damages the installation (system can not (re)boot,...)
+
** Security:
** Do non-permanent damage (uninstall recovers the installation)
+
*** Installation damage (permanent; system can not (re)boot,...)
** Superficially works
+
*** Non-permanent damage (uninstall recovers the installation):
** Works great
+
**** Only configuration
** Designed to work with this fundamental distribution with the version number/revision - "native".
+
**** Data
 +
*** Conflicts with package xyz:
 +
**** Resource (e.g. polling hardware, clearing special interrupts)
 +
**** Offered services (e.g. using tcp-port 80)
 +
*** Contains malware
 +
*** Contains virus
 +
*** Crashes sometimes
 +
*** Crashes often
 +
*** Vulnerable - buffer overflow...
 +
*** Presently seems ok
 +
** Feedback work level:
 +
*** Superficially; can start up and shut down
 +
*** some crucial features
 +
*** many crucial features
 +
*** most crucial features
 +
*** all features
 +
** Designed to work with this fundamental distribution with the version number/revision - package maturity level:
 +
*** Unstable
 +
*** Testing
 +
*** Stable
 
** ...
 
** ...
*Not tested
+
 
 +
===Suggest un-installation of unused packages===
 +
A package management system should also suggest un-installation of unused packages.
 +
 
 +
The primary/non-dispensably packages that the user needs should have been marked - either explicitly or semi-automatically. If the user uninstall a package or a package upgrade make some packages unused, they should be suggested to be uninstalled.
  
 
[[Category:Package management| ]]
 
[[Category:Package management| ]]

Latest revision as of 17:08, 28 July 2009

Contents

[edit] Problem

The problem is that some packages exist in both the fundamental distribution - and other repositories - with same names, but (newer) with other dependencies, other source code includes and other compilation options, which can and often will break the installation.

So e.g. do not use "opkg upgrade" when non-distribution (e.g. non-OM2009) repositories are included. It often breaks the installation.

[edit] Solution hack?

Please surround the non-distribution (alien) package install with:

  1. Addition of the required repository
  2. opkg update # Update database.
  3. Install the package(s)
  4. remove the non-distribution repository from opkg. E.g. "rm /etc/opkg/opkg-feed.conf"
  5.  ? Is this required?: opkg update # Update database with only the fundamental distribution packages?

[edit] Future package management system wish

Wish: Actually the package management system should cope with it. The fundamental distribution with a given version number/revision should have higher precedence, and other repositories should have lesser precedence. Maybe the best would be that the package had a distribution list in which it can be "fundamental".

Maybe the package management system should consult a check post (by name and some checksum), so an installer can be informed before installation of the package on the given fundamental distribution:

  • Not tested
  • Tested
    • Security:
      • Installation damage (permanent; system can not (re)boot,...)
      • Non-permanent damage (uninstall recovers the installation):
        • Only configuration
        • Data
      • Conflicts with package xyz:
        • Resource (e.g. polling hardware, clearing special interrupts)
        • Offered services (e.g. using tcp-port 80)
      • Contains malware
      • Contains virus
      • Crashes sometimes
      • Crashes often
      • Vulnerable - buffer overflow...
      • Presently seems ok
    • Feedback work level:
      • Superficially; can start up and shut down
      • some crucial features
      • many crucial features
      • most crucial features
      • all features
    • Designed to work with this fundamental distribution with the version number/revision - package maturity level:
      • Unstable
      • Testing
      • Stable
    • ...

[edit] Suggest un-installation of unused packages

A package management system should also suggest un-installation of unused packages.

The primary/non-dispensably packages that the user needs should have been marked - either explicitly or semi-automatically. If the user uninstall a package or a package upgrade make some packages unused, they should be suggested to be uninstalled.

Personal tools

Problem

The problem is that some packages exist in both the fundamental distribution - and other repositories - with same names, but (newer) with other dependencies, other source code includes and other compilation options, which can and often will break the installation.

So e.g. do not use "opkg upgrade" when non-distribution (e.g. non-OM2009) repositories are included. It often breaks the installation.

Solution hack?

Please surround the non-distribution package (alien) install with:

  1. Addition of the required repository
  2. opkg update # Update database.
  3. Install the package(s)
  4. remove the non-distribution repository from opkg. E.g. "rm /etc/opkg/opkg-feed.conf"
  5.  ? Is this required?: opkg update # Update database with only the fundamental distribution packages?

Future package management system wish

Wish: Actually the package management system should cope with it. The fundamental distribution with a given version number/revision should have higher precedence, and other repositories should have lesser precedence. Maybe the best would be that the package had a distribution list in which it can be "fundamental".

Maybe the package management system should consult a check post, so an installer can be informed before installation of the package on the given fundamental distribution:

  • Tested
    • Breaks og permanently damages the installation (system can not (re)boot,...)
    • Do non-permanent damage (uninstall recovers the installation)
    • Superficially works
    • Works great
    • Designed to work with this fundamental distribution with the version number/revision - "native".
    • ...
  • Not tested