diff options
-rw-r--r-- | documentation/dev-manual/dev-manual-common-tasks.xml | 471 |
1 files changed, 321 insertions, 150 deletions
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index fe34e8ecd8..7b4d638dfa 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml | |||
@@ -3605,61 +3605,179 @@ | |||
3605 | </section> | 3605 | </section> |
3606 | </section> | 3606 | </section> |
3607 | 3607 | ||
3608 | <section id='setting-up-runtime-package-management'> | 3608 | <section id='runtime-package-management'> |
3609 | <title>Setting Up Runtime Package Management</title> | 3609 | <title>Runtime Package Management</title> |
3610 | 3610 | <para> | |
3611 | <para> | 3611 | Regardless of anything else, during a build bitbake will |
3612 | For supported package formats, it is possible to set | 3612 | transform a recipe into one or more packages. For example, |
3613 | up a repository that is a host-based package feed from which | 3613 | the <filename>bash</filename> recipe currently produces the |
3614 | you can install packages on the target system during runtime. | 3614 | following packages: <filename>bash-dbg bash-staticdev bash-dev |
3615 | Doing so is optional and depends on the following: | 3615 | bash-doc bash-locale bash</filename>. Not all generated |
3616 | packages will be included in an image. | ||
3617 | </para><para> | ||
3618 | In several situations you might want to have the ability to | ||
3619 | update, add, remove, query, etc the packages on a target | ||
3620 | device at runtime (i.e. without having to generate a new | ||
3621 | image). Examples of such situations include: | ||
3616 | <itemizedlist> | 3622 | <itemizedlist> |
3617 | <listitem><para> | 3623 | <listitem><para> |
3618 | You take specific steps to set up the feed. | 3624 | You want to provide in-the-field updates to deployed |
3619 | </para></listitem> | 3625 | devices (e.g. for security updates). |
3626 | </para></listitem> | ||
3620 | <listitem><para> | 3627 | <listitem><para> |
3621 | When you build your image, you select to use the | 3628 | You want to have a fast turn-around development cycle |
3622 | appropriate package manager by setting the | 3629 | for one or more applications which run on your device. |
3623 | <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink> | 3630 | </para></listitem> |
3624 | variable. | ||
3625 | </para></listitem> | ||
3626 | <listitem><para> | 3631 | <listitem><para> |
3627 | You have a web server, such as Apache 2, | 3632 | You want to temporarily install the "debug" packages |
3628 | installed and configured on the development host. | 3633 | of various applications on your device so that |
3629 | </para></listitem> | 3634 | debugging can be greatly improved (access to symbols, |
3635 | source debugging, etc). | ||
3636 | </para></listitem> | ||
3630 | <listitem><para> | 3637 | <listitem><para> |
3631 | You enable package management on the target by | 3638 | You want to deploy a more minimal package selection of |
3632 | listing "package-management" in the | 3639 | your device but allow in-the-field updates to add a |
3633 | <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink> | 3640 | larger selection for customization. |
3634 | variable. | 3641 | </para></listitem> |
3635 | </para></listitem> | ||
3636 | </itemizedlist> | 3642 | </itemizedlist> |
3637 | </para> | 3643 | </para><para> |
3644 | In all these situations you have something similar to a more | ||
3645 | traditional Linux distribution in that in-field devices | ||
3646 | are able to grab pre-compiled packages from a server for | ||
3647 | installation/update. This is what is termed "runtime package | ||
3648 | management". In order to use runtime package management you | ||
3649 | need a host/server machine which serves up the pre-compiled | ||
3650 | packages plus the required meta data, and you need package | ||
3651 | manipulation tools on the target. Note that the build machine | ||
3652 | is a likely candidate to act as the server, but the build | ||
3653 | machine doesn't necessarily have to be the package server; | ||
3654 | the build machine could push its artifacts to another (e.g. | ||
3655 | Internet-facing) machine which acts as the server. | ||
3656 | </para><para> | ||
3657 | A simple build which targets just one device will produce | ||
3658 | more than one package database. In other words, the packages | ||
3659 | produced by a build will be separated out into a couple of | ||
3660 | different package groupings based on criteria such as the | ||
3661 | target's CPU architecture, the target board, or the C library | ||
3662 | used on the target. For example, a build targetting the | ||
3663 | <filename>qemuarm</filename> device will produce the following | ||
3664 | 3 package databases: <filename>all</filename>, | ||
3665 | <filename>armv5te</filename>, and | ||
3666 | <filename>qemuarm</filename>. If I wanted my | ||
3667 | <filename>qemuarm</filename> device to be aware of all the | ||
3668 | packages which were available to it, I would need to point it | ||
3669 | to each of these databases individually. In a similar way, a | ||
3670 | traditional Linux distribution usually is configured to be | ||
3671 | aware of a number of software repositories from which it | ||
3672 | will retrieve packages. | ||
3673 | </para><para><note> | ||
3674 | Using runtime package management is completely optional and | ||
3675 | not required for a successful build or deployment in any way. | ||
3676 | But if you want to make use of runtime package management | ||
3677 | you'll need to do a couple things above and beyond the basics. | ||
3678 | </note></para> | ||
3679 | |||
3680 | <section id='runtime-package-management-build'> | ||
3681 | <title>Build Considerations</title> | ||
3682 | <para> | ||
3683 | In order to provide support for runtime package management | ||
3684 | there are some build considerations of which to be aware. | ||
3685 | </para><para> | ||
3686 | When bitbake generates packages it needs to know in | ||
3687 | which format(s) you want the packages to be generated. | ||
3688 | In your configuration this is handled by the | ||
3689 | <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink> | ||
3690 | variable. Note that you can choose to have more than one, | ||
3691 | but at least one is required. | ||
3692 | </para><para> | ||
3693 | If you would like your image to start off with a basic | ||
3694 | package database of the packages in your current build | ||
3695 | as well as having the relevant tools available on the | ||
3696 | target for runtime package management, you can include | ||
3697 | "package-management" in the | ||
3698 | <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink> | ||
3699 | variable. Including "package-management" in this | ||
3700 | configuration variable ensures that when the image | ||
3701 | is assembled for your target it will include | ||
3702 | the currently-known package databases as well as | ||
3703 | the target-specific tools required for runtime | ||
3704 | package management to be performed on the target. | ||
3705 | Note, however, this isn't strictly necessary. | ||
3706 | You could start your image off without any databases | ||
3707 | but only include the required on-target package | ||
3708 | tool(s) (for example you would include "opkg" in your | ||
3709 | <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink> | ||
3710 | variable if you are using the IPK package format). You can | ||
3711 | then initialize your target's package database(s) later, | ||
3712 | once your image is up and running. | ||
3713 | </para><para> | ||
3714 | Whenever you perform any sort of build step which can | ||
3715 | potentially generate a package or modify an existing | ||
3716 | package, it is always a good idea to re-generate the | ||
3717 | package index with: | ||
3718 | <literallayout class='monospaced'> | ||
3719 | $ bitbake package-index | ||
3720 | </literallayout> | ||
3721 | Note that it is not sufficient to simply do: | ||
3722 | <literallayout class='monospaced'> | ||
3723 | $ bitbake <some-package> package-index | ||
3724 | </literallayout> | ||
3725 | since bitbake won't properly schedule the | ||
3726 | <filename>package-index</filename> target fully after any | ||
3727 | other target has completed. Therefore, be sure to run the | ||
3728 | package update step separately. | ||
3729 | </para><para> | ||
3730 | As described below in the | ||
3731 | <link linkend='runtime-package-management-target-ipk'>Using IPK</link> | ||
3732 | section, if you are using IPK as your package format, you | ||
3733 | can make use of the | ||
3734 | <filename>distro-feed-configs</filename> recipe provided | ||
3735 | by <filename>meta-oe</filename> in order to configure your | ||
3736 | target to use your IPK databases. | ||
3737 | </para><para> | ||
3738 | When your build is complete your packages will show up in | ||
3739 | the | ||
3740 | <filename>${TMPDIR}/deploy/<package-format></filename> | ||
3741 | directory. For example, if <filename>${TMPDIR}</filename> | ||
3742 | is <filename>tmp</filename> and your selected package type | ||
3743 | is IPK, then your IPK packages will be available in | ||
3744 | <filename>tmp/deploy/ipk</filename>. | ||
3745 | </para> | ||
3746 | </section> | ||
3638 | 3747 | ||
3639 | <para> | 3748 | <section id='runtime-package-management-server'> |
3640 | The following list provides steps for setting up the optional | 3749 | <title>Host or Server Machine Setup</title> |
3641 | repository regardless of the package format. | 3750 | <para> |
3642 | Once you work through these generic steps, see the | 3751 | Typically packages are served from a server via HTTP, but |
3643 | "<link linkend='runtime-package-management-deb-rpm'>Using RPM</link>" | 3752 | other protocols are possible. If we assume you want to |
3644 | section or the | 3753 | use HTTP, then you would need to setup and configure a |
3645 | "<link linkend='runtime-package-management-ipk'>Using IPK</link>" | 3754 | web server, such as Apache 2 or lighttpd, on the machine |
3646 | section for remaining steps specific to the package type. | 3755 | serving the packages. As mentioned above, the build |
3647 | <note> | 3756 | machine can act as the package server; in the following |
3648 | The example assumes you are using the Apache 2 server: | 3757 | server machine setups it is assumed the build machine is |
3649 | </note> | 3758 | also the server. |
3650 | <orderedlist> | 3759 | </para> |
3651 | <listitem><para> | 3760 | |
3652 | Add the directory to your Apache configuration, which | 3761 | <section id='package-server-apache'> |
3653 | you can find at | 3762 | <title>Serving Packages via Apache 2</title> |
3654 | <filename>/etc/httpd/conf/httpd.conf</filename>. | 3763 | <para> |
3655 | Use commands similar to these on the development system. | 3764 | This example assumes you are using the Apache 2 |
3656 | These example commands assume a top-level | 3765 | server: |
3657 | <link linkend='source-directory'>Source Directory</link> | 3766 | <orderedlist> |
3658 | named <filename>poky</filename> in your home directory. | 3767 | <listitem><para> |
3659 | The example also assumes an RPM package type. | 3768 | Add the directory to your Apache |
3660 | If you are using a different package type, such as | 3769 | configuration, which you can find at |
3661 | IPK, use "ipk" in the pathnames: | 3770 | <filename>/etc/httpd/conf/httpd.conf</filename>. |
3662 | <literallayout class='monospaced'> | 3771 | Use commands similar to these on the |
3772 | development system. These example | ||
3773 | commands assume a top-level | ||
3774 | <link linkend='source-directory'>Source Directory</link> | ||
3775 | named <filename>poky</filename> in your home | ||
3776 | directory. The example also assumes an RPM | ||
3777 | package type. If you are using a different | ||
3778 | package type, such as IPK, use "ipk" in the | ||
3779 | pathnames: | ||
3780 | <literallayout class='monospaced'> | ||
3663 | <VirtualHost *:80> | 3781 | <VirtualHost *:80> |
3664 | .... | 3782 | .... |
3665 | Alias /rpm ~/poky/build/tmp/deploy/rpm | 3783 | Alias /rpm ~/poky/build/tmp/deploy/rpm |
@@ -3667,119 +3785,172 @@ | |||
3667 | Options +Indexes | 3785 | Options +Indexes |
3668 | </Directory> | 3786 | </Directory> |
3669 | </VirtualHost> | 3787 | </VirtualHost> |
3788 | </literallayout> | ||
3789 | </para></listitem> | ||
3790 | <listitem><para> | ||
3791 | Reload the Apache configuration as follows. | ||
3792 | For all commands, be sure you have root | ||
3793 | privileges. | ||
3794 | </para><para> | ||
3795 | If your development system is using Fedora or | ||
3796 | CentOS, use the following: | ||
3797 | <literallayout class='monospaced'> | ||
3798 | # service httpd reload | ||
3799 | </literallayout> | ||
3800 | For Ubuntu and Debian, use the following: | ||
3801 | <literallayout class='monospaced'> | ||
3802 | # /etc/init.d/apache2 reload | ||
3803 | </literallayout> | ||
3804 | For OpenSUSE, use the following: | ||
3805 | <literallayout class='monospaced'> | ||
3806 | # /etc/init.d/apache2 reload | ||
3807 | </literallayout> | ||
3808 | </para></listitem> | ||
3809 | <listitem><para> | ||
3810 | If you are using Security-Enhanced Linux | ||
3811 | (SELinux), you need to label the files as | ||
3812 | being accessible through Apache. Use the | ||
3813 | following command from the development host | ||
3814 | (this example assumes RPM package types): | ||
3815 | <literallayout class='monospaced'> | ||
3816 | # chcon -R -h -t httpd_sys_content_t tmp/deploy/rpm | ||
3817 | </literallayout> | ||
3818 | </para></listitem> | ||
3819 | </orderedlist> | ||
3820 | </para> | ||
3821 | </section> | ||
3822 | |||
3823 | <section id='package-server-lighttpd'> | ||
3824 | <title>Serving Packages via lighttpd</title> | ||
3825 | <para> | ||
3826 | If you are using lighttpd all you need | ||
3827 | to do is to provide a link from your | ||
3828 | ${TMPDIR}/deploy/<package-format> directory to | ||
3829 | lighttpd's document-root. You can determine the | ||
3830 | specifics of your lighttpd installation by looking | ||
3831 | through its configuration file which is usually found | ||
3832 | at: <filename>/etc/lighttpd/lighttpd.conf</filename>. | ||
3833 | </para><para> | ||
3834 | For example, if you are using IPK, if | ||
3835 | lighttpd's document-root is set to | ||
3836 | <filename>/var/www/lighttpd</filename>, and if you had | ||
3837 | packages for a target named "BOARD" | ||
3838 | then you might create a link from your build location | ||
3839 | to lighttpd's document-root as follows: | ||
3840 | <literallayout class='monospaced'> | ||
3841 | # ln -s $(PWD)/tmp/deploy/ipk /var/www/lighttpd/BOARD-dir | ||
3670 | </literallayout> | 3842 | </literallayout> |
3671 | </para></listitem> | 3843 | </para><para> |
3672 | <listitem><para> | 3844 | At this point you need to start the lighttpd server. |
3673 | Reload the Apache configuration as follows. | 3845 | The way in which you start the server will vary by |
3674 | For all commands, be sure you have root privileges. | 3846 | distribution, but one basic way to start it by hand |
3675 | </para> | 3847 | would be: |
3676 | <para> | ||
3677 | If your development system is using Fedora or | ||
3678 | CentOS, use the following: | ||
3679 | <literallayout class='monospaced'> | 3848 | <literallayout class='monospaced'> |
3680 | service httpd reload | 3849 | # lighttpd -f /etc/lighttpd/lighttpd.conf |
3681 | </literallayout> | 3850 | </literallayout> |
3682 | For Ubuntu and Debian, use the following: | 3851 | </para> |
3852 | </section> | ||
3853 | </section> | ||
3854 | |||
3855 | <section id='runtime-package-management-target'> | ||
3856 | <title>Target Setup</title> | ||
3857 | |||
3858 | <section id='runtime-package-management-target-rpm'> | ||
3859 | <title>Using RPM</title> | ||
3860 | <para> | ||
3861 | The application for performing runtime package | ||
3862 | management of RPM packages on the target is called | ||
3863 | <filename>smart</filename>. | ||
3864 | </para><para> | ||
3865 | On the target machine, you need to inform | ||
3866 | <filename>smart</filename> of every package database | ||
3867 | you wish to use. As an example, suppose your target | ||
3868 | device can use the following 3 package databases from | ||
3869 | a server named <filename>server.name</filename>: | ||
3870 | <filename>all</filename>, <filename>i586</filename>, | ||
3871 | and <filename>qemux86</filename>. Given this example, | ||
3872 | issue the following commands on the target: | ||
3683 | <literallayout class='monospaced'> | 3873 | <literallayout class='monospaced'> |
3684 | /etc/init.d/apache2 reload | 3874 | # smart channel --add all type=rpm-md baseurl=http://server.name/rpm/all |
3875 | # smart channel --add i585 type=rpm-md baseurl=http://server.name/rpm/i586 | ||
3876 | # smart channel --add qemux86 type=rpm-md baseurl=http://server.name/rpm/qemux86 | ||
3685 | </literallayout> | 3877 | </literallayout> |
3686 | For OpenSUSE, use the following: | 3878 | Also from the target machine, fetch the repository |
3879 | information using this command: | ||
3687 | <literallayout class='monospaced'> | 3880 | <literallayout class='monospaced'> |
3688 | /etc/init.d/apache2 reload | 3881 | # smart update |
3689 | </literallayout> | 3882 | </literallayout> |
3690 | </para></listitem> | 3883 | You can now use the <filename>smart query</filename> |
3691 | <listitem><para> | 3884 | and <filename>smart install</filename> commands to |
3692 | Re-generate the package index: | 3885 | find and install packages from the repositories. |
3886 | </para> | ||
3887 | </section> | ||
3888 | |||
3889 | <section id='runtime-package-management-target-ipk'> | ||
3890 | <title>Using IPK</title> | ||
3891 | <para> | ||
3892 | The application for performing runtime package | ||
3893 | management of IPK packages on the target is called | ||
3894 | <filename>opkg</filename>. | ||
3895 | </para><para> | ||
3896 | In order to inform <filename>opkg</filename> of the | ||
3897 | package databases you wish to use, simply create one | ||
3898 | or more <filename>*.conf</filename> files in the | ||
3899 | <filename>/etc/opkg</filename> directory on the target | ||
3900 | and <filename>opkg</filename> will use them to find | ||
3901 | its available package databases. As an example if you | ||
3902 | configured your HTTP server on your machine named | ||
3903 | <filename>www.mysite.com</filename> to serve files | ||
3904 | from a <filename>BOARD-dir</filename> directory under | ||
3905 | its document-root you might create a configuration | ||
3906 | file on the target called | ||
3907 | <filename>/etc/opkg/base-feeds.conf</filename> which | ||
3908 | contains: | ||
3693 | <literallayout class='monospaced'> | 3909 | <literallayout class='monospaced'> |
3694 | bitbake package-index | 3910 | src/gz all http://www.mysite.com/BOARD-dir/all |
3911 | src/gz armv7a http://www.mysite.com/BOARD-dir/armv7a | ||
3912 | src/gz beagleboard http://www.mysite.com/BOARD-dir/beagleboard | ||
3695 | </literallayout> | 3913 | </literallayout> |
3696 | </para></listitem> | 3914 | </para> |
3697 | <listitem><para> | 3915 | <note> |
3698 | If you are using Security-Enhanced Linux (SELinux), | 3916 | As a way of making it easier to generate and make |
3699 | you need to label the files as being accessible | 3917 | these IPK configuration files available on your |
3700 | through Apache. | 3918 | target, the <filename>meta-oe</filename> layer |
3701 | Use the following command from the development host. | 3919 | provides a recipe called |
3702 | Again, the example assumes RPM package types: | 3920 | <filename>distro-feed-configs</filename> (which |
3921 | provides a package by the same name). When you | ||
3922 | include this package into your image, it will | ||
3923 | automatically generate and include a set of | ||
3924 | <filename>*.conf</filename> files in the image's | ||
3925 | <filename>/etc/opkg</filename> directory which will | ||
3926 | provide your target's opkg tool with any and all | ||
3927 | package databases your build will generate. The only | ||
3928 | catch is that this recipe can't possibly imagine your | ||
3929 | server's DNS name/IP address, so somewhere in your | ||
3930 | configuration you need to set a variable called | ||
3931 | <filename>DISTRO_FEED_URI</filename> which will point | ||
3932 | to your server and the location within the | ||
3933 | document-root which contains the databases. For | ||
3934 | example: if you are serving your packages over HTTP, | ||
3935 | your server's IP address is 192.168.7.1, and your | ||
3936 | databases are located in a directory called | ||
3937 | <filename>BOARD-dir</filename> underneath your HTTP | ||
3938 | server's document-root then set | ||
3939 | <filename>DISTRO_FEED_URI</filename> to | ||
3940 | <filename>http://192.168.7.1/BOARD-dir</filename>. | ||
3941 | </note> | ||
3942 | <para> | ||
3943 | On the target machine, fetch (or refresh) the | ||
3944 | repository information using this command: | ||
3703 | <literallayout class='monospaced'> | 3945 | <literallayout class='monospaced'> |
3704 | chcon -R -h -t httpd_sys_content_t tmp/deploy/rpm | 3946 | # opkg update |
3705 | </literallayout> | 3947 | </literallayout> |
3706 | </para></listitem> | 3948 | You can now use the <filename>opkg list</filename> and |
3707 | </orderedlist> | 3949 | <filename>opkg install</filename> commands to find and |
3708 | </para> | 3950 | install packages from the repositories. |
3709 | 3951 | </para><para> | |
3710 | <section id='runtime-package-management-deb-rpm'> | 3952 | </para> |
3711 | <title>Using RPM</title> | 3953 | </section> |
3712 | |||
3713 | <para> | ||
3714 | Following are RPM-specific steps needed for setting up the | ||
3715 | optional repository. | ||
3716 | Perform these steps after working through the common steps | ||
3717 | at the start of this section: | ||
3718 | <orderedlist> | ||
3719 | <listitem><para> | ||
3720 | On the target machine, add the repository to Smart | ||
3721 | for every package architecture. | ||
3722 | To see the list of package architectures, list | ||
3723 | the contents of the | ||
3724 | setting-up-runtime-package-management <filename>tmp/deploy/rpm</filename> directory | ||
3725 | on the host.</para> | ||
3726 | <para> | ||
3727 | As an example, suppose you list the contents of the | ||
3728 | directory and discover three architectures: | ||
3729 | <filename>all</filename>, <filename>i586</filename>, | ||
3730 | and <filename>qemux86</filename>. | ||
3731 | Given this example, use the following commands: | ||
3732 | <literallayout class='monospaced'> | ||
3733 | smart channel ‐‐add all type=rpm-md baseurl=http://server.name/rpm/all | ||
3734 | smart channel ‐‐add i585 type=rpm-md baseurl=http://server.name/rpm/i586 | ||
3735 | smart channel ‐‐add qemux86 type=rpm-md baseurl=http://server.name/rpm/qemux86 | ||
3736 | </literallayout> | ||
3737 | </para></listitem> | ||
3738 | <listitem><para> | ||
3739 | Also from the target machine, fetch the repository | ||
3740 | information using this command: | ||
3741 | <literallayout class='monospaced'> | ||
3742 | smart update | ||
3743 | </literallayout> | ||
3744 | </para></listitem> | ||
3745 | </orderedlist> | ||
3746 | You can now use the <filename>smart query</filename> | ||
3747 | and <filename>smart install</filename> commands to find | ||
3748 | and install packages from the repositories. | ||
3749 | </para> | ||
3750 | </section> | ||
3751 | |||
3752 | <section id='runtime-package-management-ipk'> | ||
3753 | <title>Using IPK</title> | ||
3754 | |||
3755 | <para> | ||
3756 | Following are IPK-specific steps needed for setting up the | ||
3757 | optional repository. | ||
3758 | Perform these steps after working through the common steps | ||
3759 | at the start of this section: | ||
3760 | <orderedlist> | ||
3761 | <listitem><para>Install packages onto an | ||
3762 | existing running system by first sharing the | ||
3763 | <filename>tmp/deploy/ipk/</filename> directory | ||
3764 | through a web server and then by changing | ||
3765 | <filename>/etc/opkg/base-feeds.conf</filename> | ||
3766 | to point at the shared server. | ||
3767 | Following is an example: | ||
3768 | <literallayout class='monospaced'> | ||
3769 | src/gz all http://www.mysite.com/somedir/deploy/ipk/all | ||
3770 | src/gz armv7a http://www.mysite.com/somedir/deploy/ipk/armv7a | ||
3771 | src/gz beagleboard http://www.mysite.com/somedir/deploy/ipk/beagleboard | ||
3772 | </literallayout></para></listitem> | ||
3773 | <listitem><para>From the target machine, fetch the | ||
3774 | repository information using this command: | ||
3775 | <literallayout class='monospaced'> | ||
3776 | opkg update | ||
3777 | </literallayout></para></listitem> | ||
3778 | </orderedlist> | ||
3779 | You can now use the <filename>opkg list</filename> and | ||
3780 | <filename>opkg install</filename> commands to find and | ||
3781 | install packages from the repositories. | ||
3782 | </para> | ||
3783 | </section> | 3954 | </section> |
3784 | </section> | 3955 | </section> |
3785 | 3956 | ||