-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnoisohandbook.txt
1389 lines (1079 loc) · 58.4 KB
/
noisohandbook.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
HANDBOOK FOR CRUX PPC 3.5
25Sep2019
1. Preface
1. What is CRUX PPC?
2. Why use CRUX PPC?
3. License
1. Packages
2. Build Scripts
3. GPL
4. NO WARRANTY
3. Installing CRUX PPC
4. The Package System
1. Introduction
2. Using the Package System
1. Installing a Package
2. Upgrading a Package
3. Removing a Package
4. Querying the Package Database
3. Package management frontend: prt-get
1. prt-get and CRUX PPC
4. Creating Packages
1. Adjusting/Configuring the Package Build Process
5. Package Guidelines
1. General
2. Directories
6. Remove Junk Files
1. Pkgfile
2. Pkgfile Header
5. The Ports System
1. Introduction
1. What is a Port?
2. What is the Ports System?
1. Port collections
2. The official collection 'opt' and 'core'
3. The user contributed collection 'contrib'
4. The individual collections from CRUX users
3. Using the Ports System
1. Synchronizing Your Local Ports Structure
2. Listing Local Ports
3. Listing Version Differences
4. Building and Installing Packages
5. Enabling the 'contrib' collection
6. Additional Tools
1. Building ports as unprivileged user
2. Useful scripts
6. Configuration
1. Initialization Scripts
1. Runlevels
2. Layout
3. Configuration Variables in /etc/rc.conf
4. Generating Locales
5. Network Configuration
2. Passwords
3. Upgrading the Kernel
7. Appendix
1. Troubleshooting
2. Installation
3. Configuration
CRUX PPC Handbook - release 3.5
Copyright (c) 2001-2004 Per Liden
Copyright (c) 2004-2005 Giulivo Navigante
Copyright (c) 2005-2011 The CRUX PPC team
Copyright (c) 2018-2019 The CRUX PPC NG team
This handbook covers the installation, configuration and administration of
CRUX PPC and most in general of the CRUX distribution. For further
information about the GNU/Linux system see the GNU's Not Unix project page
and the Linux Documentation Project.
This handbook is somewhat vague regarding installation of CRUX-PPC.
It will probably be sufficient for users experienced with hands on
PowerPC Linux installs (CRUX, Gentoo, LFS, etc) but it is likely not
suffienct for inexperienced users. As time passes, additional details
and information will be added to this handbook to make it easier to
install and use CRUX-PPC.
Preface
Per Liden wrote this handbook. Robert McMeekin converted it to DocBook.
Giulivo Navigante and further on The CRUX PPC Team adapted it for PPC
users. Numerous others have given feedback and improvement suggestions.
Introduction
What is CRUX PPC?
CRUX PPC is a port for the Power Architecture^(R) platform of CRUX, a
lightweight and optimized GNU/Linux distribution targeted at experienced
GNU/Linux users. The primary focus of this distribution is "keep it
simple", which it reflects in a simple tar.xz-based package system,
BSD-style initscripts, and a relatively small collection of trimmed
packages. The secondary focus is utilization of new Linux kernel features
and recent tools and libraries. CRUX PPC also has a ports system which
makes it easy to install and upgrade applications.
Why use CRUX PPC?
There are many GNU/Linux distributions out there these days, so what makes
this distribution any better than the others? Well, it's all about taste
really. Here are a few hints about the tastes and goals of the people
behind CRUX PPC. CRUX PPC is made with simplicity in mind from beginning
to end. Making it easy to create new and update old packages is essential;
updating a package in CRUX PPC is often just a matter of typing pkgmk -d
-u. The usage of ports helps keep your packages up-to-date;
not the latest bleeding-edge-alpha version, but the latest stable version.
Other features include creating packages optimized for your processor, eg.
by compiling with -mtune=750 and avoiding
cluttering the filesystem with files you'll never use, eg. /usr/doc/*,
etc. If you need more information about a specific program, other than
information found in the man-page, a web search engine usually knows all
about it. Finally, it strives to use new features as they become
available, as long as they are consistent with the rest of the goals.
If you are a somewhat experienced GNU/Linux user that wants a clean and
solid GNU/Linux distribution as the foundation of your installation,
prefers editing configuration files with an editor to using a GUI, and
doesn't hesitate to download and compile programs yourself, then this
istribution might suit you well.
If you are looking for a distribution that has numerous packages ready for
installation just with a point and click, then this distribution will
probably not suit you well.
License
Packages
Since CRUX PPC is a GNU/Linux distribution, it contains software written
by a lot of different people. Each software package comes with its own
license, chosen by its author(s). To find out how a particular package is
licensed, have a look at its source code.
Build Scripts
Package build scripts in CRUX PPC (initially in package categories *-ppc)
are Copyright (c) by CRUX PPC-NG Team and licensed through the GNU General
Public License. Other build scripts (in package categories core and
opt) are Copyright (c) 2000-2019 by Per Liden and the CRUX development
team and licensed through the GNU General Public License.
GPL
Any code or documentation authored by the CRUX PPC Team that comes with
CRUX PPC is released under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 or (at your
option) later. You should have received a copy of the GNU General Public
License along with CRUX PPC.
NO WARRANTY
CRUX PPC is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. Use it at YOUR OWN RISK.
Installing CRUX PPC
First make a backup copy of any crucial data that exists on the system
that CRUX-PPC will be installed onto. Although installing CRUX-PPC
should not cause any loss of data, the install operations are performed
with root priveleges and the potential for data loss exists. Therefore,
the first step is to ensure that every piece of crucial data on the
target install system is recoverable should a data loss occur.
Supported Hardware
Packages on the official CRUX PPC rootfs image are compiled with
optimizations to support Power Architecture(R) processors. CRUX PPC works
on Apple NewWorld 32 bit machines. It may also be adaptable to other
PowerPC machines such PegasosII, EFIKA, Sam440ep, Sam460ex, but testing
has been limited to Apple PowerPC machines and so its usability is unknown
regarding other machines.
Installing From CD-ROM
NOTE: There is currently no ISO installation image of this release and
so installing directly from a cruxppc CD-ROM is not possible. However,
it should be possible to boot another distributions CD-ROM and use it
to perform the installation of the CRUX-PPC files. Gentoo, in
particular, produces a bootable ppc iso image that is intended to
install gentoo but can also be used, to download and install
the initial cruxppc root file system and kernel. Any recent install media
that allows the user to break into shell (e.g. rescue mode) and provides
tools to partition, format, extract tar archives, and chroot should work for
a CRUX-PPC installation.
Also if your system is already running a Linux distro and there is
a spare partition for CRUX ppc, then it is quite easy to use the
distos tool set to install CRUX PPC into the spare partition.
The CRUX-PPC Tarball
CRUX-PPC is released as a tarball of a root filesystem that has been
populated with a basic set of CRUX-PPC packages. These packages number
about 100 and consist of all the 'core' CRUX packages except omitting the
x86 specific packages (e.g. lilo), ommiting openssl and it's dependents,
and including several additional packages useful for PowerPC
(e.g. mac-fdisk).
The CRUX-PPC rootfs expands to about 600M in size. Additional space
will be required as additional packages are added. Although the initial
CRUX-PPC system will fit within a Gig of disk space, a more reasonable space
allocation for CRUX-PPC would be 10 to 20 Gig of disk space (or even
bigger if numerous additional packages are to be added).
The CRUX-PPC system may be installed as a chroot or as a bootable
system. Typical use would be as a bootable system but a CRUX-PPC
chroot environment is a quick and easy way to try crux ppc before going
through the more difficult process to install a bootable system.
Installing the root filesystem tarball as chroot:
The CRUX-PPC root file system can be used in a chroot environment.
If chroot is desired then on an existing PowerPC machine create a
directory for the CRUX-PPC tree, extract the rootfs, mount needed
file systems and then chroot to it. e.g.:
mkdir /cruxppc
cd /cruxppc
tar xvfp /pathtocruxrootfs.tar.xz
mount --bind /dev /cruxppc/dev
mount --bind /tmp /cruxppc/tmp
mount -t proc proc /cruxppc/proc
mount -t sysfs none /cruxppc/sys
chroot /cruxppc /bin/bash
Next complete the needed configuration steps as described within
this document. Especially remember to set /etc/resolv.conf
to a valid name server else networking will not work within the chroot
environment.
Note that the CRUX-PPC 3.5 requires a minimum kernel version of 3.2.
If your systems kernel is an earlier version than 3.2, you will not be able
to chroot into CRUX-PPC. Most PowerPC linux distributions released within
the last few years should work with crux ppc as chroot.
Installing a bootable CRUX-PPC system (typical)
To create a bootable CRUX-PPC machine, a disk partition must be allocated
for CRUX-PPC, the partition must be formatted and the CRUX-PPC root
filesystem extracted into the partition. The kernel must be added
and the bootloader configured to boot the CRUX-PPC system and use the
CRUX-PPC partition as root filesystem.
If the machine already has an existing Linux install, then use the
existing tools to create a new partition on the disk. Format the
partition (ext4 is a good choice), mount it and then extract the CRUX-PPC
rootfs tarball into the partition:
mkdir /mnt/crux-3.5
mount /dev/(your crux partition) /mnt/crux-3.5
cd /mnt/crux-3.5
tar xvfp (path to the cruxppc-ng-3.5 rootfs tarball)
sync
If the machine has no existing Linux install, then acquire an install
CD from another distro (e.g. Debian), boot it, and break into a root shell.
Partition the disk as needed, format the partition as needed, mount it and
then extract the CRUX-PPC rootfs tarball into the CRUX-PPC partition.
A sample ppc32 kernel configuration file is provided. It can be used
as a starting point for configuring and building a kernel for the
crux ppc system. If desired, the prebuilt kernel can be installed
to get up and running quickly and then the user can build their
own kernel later as time permits.
If the machine has a seperate boot partition, copy the CRUX-PPC
kernel into the appropriate /boot partition.
Modify the /etc/yaboot.conf file (save a backup copy first) and add
an entry for the CRUX-PPC kernel and root file system. Once /etc/yaboot.conf
is satisfactory, run 'ybin' and the CRUX-PPC system will be a bootable
option at the next reboot.
Once booted, the user should run 'dbus-uuidgen --ensure' to setup
the unique machine id. The dbus package is included in the rootfs
and the installation script of dbus requires this step.
Extra packages.
Some opt and xorg packages are provided at this time and as this
project progresses, additional precompiled packages from the
opt and xorg ports may be provided. Users must build
and install any additional packages from /usr/opt* and /usr/opt/xorg*
(and /usr/port/contrib) as desired.
Note that some packages have pre or post install scripts and/or
README files associated with them. The pkgadd utility does NOT
run these sripts (or even is aware of their existence). When
installing binary packages, the user should always check for the
existence of scripts or READMEs and perform the needed additional
steps required by the package.
Configuring a new CRUX-PPC system
Edit /etc/fstab to configure your filesystem(s).
NOTE If you want access your computer via serial console (as it should be
for IBM RS/6000, pSeries, Apple Xserve or Genesi EFIKA users) you also
have to add ttyS0 (ttyPZ0 for Xserve or ttyPSC0 for EFIKA) in the
/etc/securetty and c7:2:respawn:/sbin/agetty 9600 ttyS0
(c7:2:respawn:/sbin/agetty 57600 ttyPZ0 for Xserve or
c7:2:respawn:/sbin/agetty 115200 ttyPSC0 for EFIKA) in the /etc/inittab
file. For IBM Power Systems (POWER5 and newer) and PPC970 cpu based
systems if you want access your computer via serial console (and to have a
working prompt using keyboard/monitor too) you also have to add hvsi0 or
hvc0 in the /etc/securetty and c7:2:respawn:/sbin/agetty 19200 hvsi0 (or
c7:2:respawn:/sbin/agetty hvc0) in the /etc/inittab file.
Edit /etc/rc.conf to configure font, keyboard, timezone, hostname and
services. See Section 6.1.3, Configuration Variables in /etc/rc.conf for
details about /etc/rc.conf .
Generate locales for your system. See Section 6.1.4, Generating
Locales for more information. A script which generates a few selected
(of the many possible) locales can be found under misc.
Edit /etc/rc.d/net, /etc/hosts and /etc/resolv.conf to configure your
network (ip-address/gateway/hostname/domain/dns).
Execute 'ports -u' to populate the initial set of ports files.
NOTE: ports -u does NOT get the ppc specific ports.
Retrieve the ppc ports from the git repository and copy them to /usr/ports/
core-ppc, /usr/ports/opt-ppc and /usr/ports/xorg-ppc:
git clone https://www.github.com/tarmiste/cruxppc-ng-3.5
cd cruxppc-ng-3.5/ports
cp -r *-ppc /usr/ports
Periodically check and update the ppc specific ports from the git
repository if needed. These ports are not automatically updated
when 'ports -u' is runa and must be updated by hand periodically.
Note that most of the ppc specific ports have a counter part in the
generic /usr/ports tree. For example there will exist both a
/usr/ports/core/gcc and a /usr/ports/core-ppc/gcc package. When
building packages, you should always build the *-ppc version and
not the generic version. If no *-ppc version exists, then build
the generic version. This is not ideal but for now is the way it
works. Manually deleting the generic ports where the equivalent
powerpc specific port exists may make it easier to avoid mistakes.
The prt-get tool should automatically find and use the ppc version
of ports when they exist. prt-get is an easier method of adding
packages than the pkgmk utility.
The Package System
Introduction
The package system (pkgutils) is made with simplicity in mind, where all
packages are plain tar.xz files (i.e. without any kind of meta data).
Packages follow the naming convention
<name>#<version>-<release>.pkg.tar.gz, where <name> is the name of the
program, <version> is the version number of the program, and <release> is
the version number of the package. The pkg.tar.gz extension is used
(instead of just tar.gz) to indicate that this is not just any tar.gz
file, but a tar.gz that is meant to be installed using pkgadd. This way it
is easy to tell packages apart from other tar.gz files.
pkgadd(8), pkgrm(8), pkginfo(8), and pkgmk(8) are the package management
utilities. With these utilities you can install, uninstall, inspect, make
packages and query the package database.
When a package is installed using pkgadd a new record is added to the
package database (stored in /var/lib/pkg/db). The basic package system
does not have any kind of dependency checking, thus it will not warn you
if you install a package that requires other packages to be installed. The
included prt-get tools, however, do support dependencies.
The following sections will in short describe how to use the package
utilities. Additional information about these utilities can be found on
their respective man page.
Using the Package System
Installing a Package
Installing a package is done by using pkgadd. This utility requires at
least one argument, the package you want to install. Example:
$ pkgadd bash#3.2.33-1.pkg.tar.gz
When installing a package the package manager will ensure that no
previously installed files are overwritten. If conflicts are found an
error message will be printed and pkgadd will abort without installing the
package. The error message will contain the names of the conflicting
files. Example:
$ pkgadd bash#3.2.33-1.pkg.tar.gz
bin/sh
usr/man/man1/sh.1.gz
pkgadd error: listed file(s) already installed (use -f to ignore and overwrite)
To force the installation and overwrite the conflicting files you can use
the option -f (or --force). Example:
$ pkgadd -f bash#3.2.33-1.pkg.tar.gz
The package system allows a file to be owned by exactly one package. When
forcing an installation the ownership of the conflicting files will be
transferred to the package that is currently being installed. Directories
can however be owned by more than one package.
WARNING It is often not a good idea to force the installation unless you
really know what you are doing. If a package conflicts with already
installed files it could be a sign that the package is broken and installs
unexpected files. Use this option with extreme care, preferably not at
all.
As said earlier the package file itself does not contain any meta data.
Instead the package manager uses the package filename to determine the
package name and version. Thus, when installing a package file named
bash#3.2.33-1.pkg.tar.gz the package manager will interpret this as a
package named bash at version 3.2.33-1. If pkgadd is unable to interpret
the filename (e.g. # is missing or the filename does not end with
.pkg.tar.gz) an error message will be printed and pkgadd will abort
without installing the package.
Upgrading a Package
Upgrading a package is done using pkgadd with the -u option. Example:
$ pkgadd -u bash#3.2.33-1.pkg.tar.gz
This will replace the previously installed bash package with the new one.
If you have not previously installed bash, pkgadd will print an error
message. The package system does not care about the version number of the
package in that you can "upgrade" version 3.2.33-1 with version 2.04-1 (or
even with version 3.2.33-1 itself). The installed package will be replaced
with the specified package.
Upgrading a package is equivalent to executing pkgrm followed by pkgadd
with one (big) exception. When upgrading a package (with pkgadd -u) you
have the option to prevent some of the already installed files from
getting replaced. This is typically useful when you want to preserve
configuration and log files.
When executing pkgadd the file /etc/pkgadd.conf will be read. This file
can contain rules describing how pkgadd should behave when doing upgrades.
A rule is built out of three fragments; event, pattern and action. The
event describes in what kind of situation this rule applies. Currently
only one type of event is supported, that is UPGRADE. The pattern is a
filename pattern expressed as a regular expression and the action
applicable to the UPGRADE event is YES or NO. More than one rule of the
same event type is allowed, in which case the first rule will have the
lowest priority and the last rule will have the highest priority. Example:
#
# /etc/pkgadd.conf: pkgadd(8) configuration
#
UPGRADE ^etc/.*$ NO
UPGRADE ^var/log/.*$ NO
UPGRADE ^etc/X11/.*$ YES
UPGRADE ^etc/X11/xorg.conf$ NO
# End of file
The above example will cause pkgadd to never upgrade anything in /etc/ or
/var/log/ (subdirectories included), except files in /etc/X11/
(subdirectories included), unless it is the file /etc/X11/xorg.conf. The
default rule is to upgrade everything, rules in this file are exceptions
to that rule.
Note A pattern should never contain an initial "/" since you are referring
to the files in the package, not the files on the disk.
If pkgadd finds that a specific file should not be upgraded it will
install it under /var/lib/pkg/rejected/. Files in this directory are never
added to the package database. The user is then free to examine, use
and/or remove that file manually. Another option is to use rejmerge. For
each rejected file found in /var/lib/pkg/rejected/, rejmerge will display
the difference between the installed version and the rejected version. The
user can then choose to keep the installed version, upgrade to the
rejected version or perform a merge of the two. Example (using the above
/etc/pkgadd.conf):
$ pkgadd -u bash#3.2.33-1.pkg.tar.gz
pkgadd: rejecting etc/profile, keeping existing version
$ ls /var/lib/pkg/rejected/
etc/
$ ls /var/lib/pkg/rejected/etc/
profile
Removing a Package
Removing a package is done by using pkgrm. This utility requires one
argument, the name of the package you want to remove. Example:
$ pkgrm bash
WARNING This will remove all files owned by the package, no questions
asked. Think twice before doing it and make sure that you did not misspell
the package name since that could remove something completely different
(e.g. think about what could happen if you misspelled glib as glibc).
Querying the Package Database
Querying the package database is done using pkginfo. This utility has a
few options to answer different queries.
+------------------------------------------------------------------------+
| Option | Description ||
|-------------------------+---------------------------------------------||
| -i, --installed | List installed packages and their version. ||
|-------------------------+---------------------------------------------||
| -l, --list package|file | List files owned by the specified package ||
| | or contained in file ||
|-------------------------+----------------------------------------------|
| -o, --owner pattern | List owner(s) of file(s) matching pattern. |
+------------------------------------------------------------------------+
Examples:
$ pkginfo -i
atk 1.20.0-1
autoconf 2.61-1
automake 1.10-1
<...>
yaboot 1.3.14-1
zip 2.32-1
zlib 1.2.3-1
$ pkginfo -l bash
bin/
bin/bash
bin/sh
etc/
etc/profile
usr/
usr/man/
usr/man/man1/
usr/man/man1/bash.1.gz
usr/man/man1/sh.1.gz
$ pkginfo -l grep#2.5.3-1.pkg.tar.gz
usr/
usr/bin/
usr/bin/egrep
usr/bin/fgrep
usr/bin/grep
usr/man/
usr/man/man1/
usr/man/man1/egrep.1.gz
usr/man/man1/fgrep.1.gz
usr/man/man1/grep.1.gz
$ pkginfo -o bin/ls
Package File
coreutils bin/ls
e2fsprogs usr/bin/lsattr
module-init-tools sbin/lsmod
pciutils usr/sbin/lspci
usbutils usr/sbin/lsusb
Package management frontend: ilenia
Ilenia is no longer part of CRUX-PPC. Disregard references to it.
To address the different requirements towards package management in CRUX
PPC, a number of users started discussion about an advanced package
management frontend to pkgutils, with dependency handling and support for
large install transactions. Ilenia and prt-get, are two tools which
provide a number of features on top of pkgutils while keeping pkgutils'
original character and power. Its main features are:
* Dependency handling
* Build logging
* Powerful search and query functionality
* Ports repositories hierarchy
Prt-get, is the official project and tool of the CRUX project. A
full description can be found in the manual of prt-get.
prt-get and CRUX PPC
Prt-get is included in CRUX PPC.
Creating Packages
Creating a package is done using pkgmk. This utility uses a file called
Pkgfile, which contains information about the package (such as name,
version, etc) and the commands that should be executed in order to compile
the package in question. To be more specific, the Pkgfile file is actually
a bash(1) script, which defines a number of variables (name, version,
release and source) and a function (build). Below is an example of what a
Pkgfile file might look like. The example shows how to package the grep(1)
utility. Some comments are inserted for explanation.
# Specify the name of the package.
name=grep
# Specify the version of the package.
version=2.4.2
# Specify the package release.
release=1
# The source(s) used to build this package.
source=(ftp://ftp.gnu.org/gnu/$name/$name-$version.tar.gz)
# The build() function below will be called by pkgmk when
# the listed source files have been unpacked.
build() {
# The first thing we do is to cd into the source directory.
cd $name-$version
# Run the configure script with desired arguments.
# In this case we want to put grep under /usr/bin and
# disable national language support.
./configure --prefix=/usr --disable-nls
# Compile.
make
# Install the files, BUT do not install it under /usr, instead
# we redirect all the files to $PKG/usr by setting the DESTDIR
# variable. The $PKG variable points to a temporary directory
# which will later be made into a tar.gz-file. Note that the
# DESTDIR variable is not used by all Makefiles, some use prefix
# and others use ROOT, etc. You have to inspect the Makefile in
# question to find out. Some Makefiles do not support redirection
# at all. In those cases you will have to create a patch for it.
make DESTDIR=$PKG install
# Remove unwanted files, in this case the info-pages.
rm -rf $PKG/usr/info
}
In reality you do not include all those comments, thus the real Pkgfile
for grep(1) looks like this:
# Description: GNU grep, egrep and fgrep
# URL: http://www.gnu.org/software/grep/grep.html
# Maintainer: Per Lideacute;n, per at fukt dot bth dot se
name=grep
version=2.4.2
release=1
source=(ftp://ftp.ibiblio.org/pub/gnu/$name/$name-$version.tar.gz)
build() {
cd $name-$version
./configure --prefix=/usr --disable-nls
make
make DESTDIR=$PKG install
rm -rf $PKG/usr/info
}
Note The build() function in the example above is just an example of how
grep is built. The contents of the function can differ significantly if
the program is build in some other way, e.g. does not use autoconf.
When the build() function has been executed, the $PKG directory will be
made into a package named <name>#<version>-<release>.pkg.tar.gz. Before
the package creation is completed, pkgmk will check the content of the
package against the .footprint file. If this file does not exist, it will
be created and the test will be skipped. The .footprint file will contain
a list of all files that should be in the package if the build was
successful or a list of all the files that were installed in $PKG (if the
.footprint did not already exist). If there is a mismatch the test will
fail and an error message will be printed. You should not write the
.footprint file by hand. Instead, when a package has been upgraded and you
need to update the contents of the .footprint file you simply do pkgmk
-uf. This test ensures that a rebuild of the package turned out as
expected.
If the package built without errors it's time to install it by using
pkgadd and try it out. I highly recommend looking at the Pkgfile in
another package(s), since looking at examples is a great way to learn.
Adjusting/Configuring the Package Build Process
Many settings pertaining to the package build process can be adjusted by
editing the pkgmk(8) configuration file /etc/pkgmk.conf . Some of these
configurable settings include:
* CFLAGS, CXXFLAGS - these settings control optimization and architecture
options for package compiles. It is best NOT to change these unless you
absolutely know what you're doing!
* PKGMK_SOURCE_MIRRORS - this setting defines locations from which pkgmk
will attempt to fetch source archives
* PKGMK_SOURCE_DIR - this setting defines where pkgmk will store (if
downloading) and use source archives when building
* PKGMK_PACKAGE_DIR - this setting defines where pkgmk will create package
files once the build process is complete
* PKGMK_WORK_DIR - this setting defines a work area pkgmk will use to
build the package
Here are some examples:
PKGMK_SOURCE_MIRRORS=(http://fileserver.intranet/crux/sources/)
This setting instructs pkgmk to attempt to fetch all source archives from
http://fileserver.intranet/crux/sources/ before falling back to the source
URL specified in the Pkgfile. Multiple URLS can be separated by spaces.
PKGMK_SOURCE_DIR="/usr/ports/srcfiles"
This example instructs pkgmk to store and find source archives in
/usr/port/srcfiles . An example benefit of this setup would be the ability
to store /usr/ports/srcfiles on an NFS server on your local network for
use by multiple crux installations. PKGMK_PACKAGE_DIR can be set and used
the same way.
PKGMK_WORK_DIR="/usr/ports/work/$name"
This example instructs pkgmk to use /usr/ports/work/$name as a work area
for building the specified package. Building the grep package would result
in the work area being /usr/ports/work/grep . An alternative would be to
use a tmpfs as your work directory.
There are a few more settings which can be found in the pkgmk.conf man
page.
Package Guidelines
General
* The name of a package should always be lowercase (e.g. name=eterm and
not name=Eterm). In case the package is added to the CRUX ports system the
exact same name should be use for the name of the directory in the ports
structure, i.e. /usr/ports/???/eterm.
* Do not combine several separately distributed programs/libraries into
one package. Make several packages instead.
Directories
* In general packages should install files in these directories.
Exceptions are of course allowed if there is a good reason. But try to
follow the following directory structure as close as possible.
+------------------------------------------------------------------------+
| Directory | Description | |
|--------------------+-------------------------------------------| |
| /usr/bin/ | User command/application binaries | |
|--------------------+-------------------------------------------| |
| /usr/sbin/ | System binaries (e.g. daemons) | |
|--------------------+-------------------------------------------| |
| /usr/lib/ | Libraries | |
|--------------------+-------------------------------------------| |
| /usr/include/ | Header files | |
|--------------------+-------------------------------------------| |
| /usr/lib/<prog>/ | Plug-ins, addons, etc | |
|--------------------+-------------------------------------------| |
| /usr/man/ | Man pages | |
|--------------------+-------------------------------------------| |
| /usr/share/<prog>/ | Data files | |
|--------------------+-------------------------------------------| |
| /usr/etc/<prog>/ | Configuration files | |
|--------------------+---------------------------------------------------|
| /etc/ | Configuration files for system software (daemons, |
| | etc) |
+------------------------------------------------------------------------+
* /opt directory is reserved for manually compiled/installed applications.
Packages should never place anything there.
* /usr/libexec/ is not used in CRUX, thus packages should never install
anything there. Use /usr/lib/<prog>/ instead.
Remove Junk Files
* Packages should not contain "junk files". This includes info pages and
other online documentation, man pages excluded (e.g. usr/doc/*, README,
*.info, *.html, etc).
* Files related to NLS (national language support), always use
--disable-nls when available.
* Useless or obsolete binaries (e.g. /usr/games/banner and
/sbin/mkfs.minix).
Pkgfile
* Do not add new variables to the Pkgfile. Only in very few cases does
this actually improve the readability or the quality of the package.
Further, the only variables that are guranteed to work with future
versions of pkgmk are name, version, release, and source. Other names
could be in conflict with internal variables in pkgmk.
* Use the $name and $version variables to make the package easier to
update/maintain. For example,
source=(http://xyz.org/$name-$version.tar.gz) is better than
source=(http://xyz.org/myprog-1.0.3.tar.gz) since the URL will
automatically updated when you modify the $version variable.
* Remember that source is an array, i.e. always do source=(...) and not
source=...
Pkgfile Header
Provide a header including the following fields:
+------------------------------------------------------------------------+
| Name | Meaning ||
|-------------+---------------------------------------------------------||
| Description | A short description of the package; keep it factual ||
|-------------+---------------------------------------------------------||
| Maintainer | Your full name and e-mail address, obfuscated if you ||
| | want ||
|-------------+---------------------------------------------------------||
| Packager | The original packager's full name and e-mail address ||
|-------------+---------------------------------------------------------||
| URL | A webpage with more information on this software ||
| | package ||
|-------------+----------------------------------------------------------|
| Depends on | A list of dependencies, separated either by spaces or |
| | commas |
+------------------------------------------------------------------------+
Depends on can be omitted if there are no dependencies; Packager can be
omitted if the maintainer and packager are the same person.
Example header
# Description: Terminal based IRC client for UNIX systems
# URL: http://www.irssi.org/
# Maintainer: Jukka Heino, jukka at karsikkopuu dot net
# Packager: Daniel K. Gebhart, dkg at con-fuse dot org
# Depends on: glib
Note If your package specifically addresses the PPC platform, or if your
Pkgfile is a modified version of an package build file, please add an
extra header field PPC!=upstream that explains what's different from x86
and/or a field that indicates the PPC packager name like Modified version
for PPC.
Example PPC header:
# Description: Mozilla Web Browser Component
# URL: http://www.mozilla.com/firefox/
# Maintainer: Matt Housh, jaeger at morpheus dot net
# Modified version for PPC: http://cruxppc.sunsite.dk
# Depends on: libidl, gtk, libpng, libjpeg, zlib
# PPC!=upstream: footprint, mozconfig with ac_cv_visibility_pragma=no
The Ports System
Introduction
What is a Port?
A port is a directory containing the files needed for building a package
using pkgmk. This means that this directory at least has the files Pkgfile
(which is the package build description) and .footprint (which is used for
regression testing and contains a list of files this package is expected
to contain once it is built). Further, a port directory can contain
patches and/or other files needed for building the package. It is
important to understand that the actual source code for the package is not
necessarily present in port directory. Instead the Pkgfile contains an URL
which points to a location where the source can be downloaded.
The use of the word port in this context is borrowed from the BSD world,
where a port refers to a program that has been ported to a system or
platform. The word can sometimes be a bit misleading since most programs
require no actual porting to run on CRUX (or on GNU/Linux in general).
What is the Ports System?
The term Ports System refers to a remote repository containing ports and a
client program capable of downloading ports from that repository. CRUX
users use the ports(8) utility to download ports from the repositorty and
place them in /usr/ports/. CRUX PPC ports(8) utility syncs with both the
CRUX PPC repositories, whose copy is kept in /usr/ports/ppc, and the CRUX
repositories, whose copy is kept in /usr/ports/ The ports utility uses
rsync(1) to do the actual synchronization with the PPC repositories, and
rsync(1) to sync with the main CRUX repositories.
Port collections
CRUX ports are organized in so called collections; the CRUX PPC project
provides PPC specific collections that only contain ports that need to be
different on Power Architecture than CRUX upstream (. Whenever the
user seeks for a port and finds it in a PPC repository, s/he should use
the PPC version instead of the CRUX upstream.
There are three different layers of ports.
The official collection 'opt', 'core' and 'xorg'
core, x86/opt and x86/xorg are the three primary collections of CRUX.
They're maintained by the CRUX development team which ensures that they're
consistent and working well together.
ppc/core, ppc/opt and ppc/xorg collections are maintained by the CRUX PPC
Team and are meant to override the ports when there is some ppc
specific issue that prevents the upstream ports from working on Power
Architecture. Those three collections and their ppc counterparts are
also enabled by default in CRUX PPC.
The user contributed collection 'contrib'
The contrib collection is a relatively new collection which is
provided by experienced port maintainers, some part of the CRUX
development team, some regular users. Its goal is to reduce the number of
duplicate ports provided in the individual collections. If you're a
seasoned port maintainer, you might even want to join the contrib
collection. The most of these ports should work on CRUX PPC, but not all
of them have been verified by The CRUX PPC Team or fixed in the
ppc/contrib collection.
The ppc/contrib collection contains some special PowerPC specific ports
not available in the upstream contrib collection, and some contrib ports
adjusted for PPC.
As those ports are not provided officially by the CRUX development team,
this collection is disabled by default.
The individual collections from CRUX users
---fill--
Using the Ports System
Synchronizing Your Local Ports Structure
When CRUX PPC is installed for the first time the local ports structure
(/usr/ports/) is empty. To bring your local ports structure up to date you
use the ports utility with the -u option. Example:
$ ports -u
The -u option means update, and tells ports to contact the ports
repository and download new and updated ports. The output from this
execution is something like this:
Updating file list from cruxppc.org::ports/core/3.5/
Updating collection core
...
Updating file list from cruxppc.org::ports/opt/3.5/
Updating collection opt
...
Updating file list from cruxppc.org::ports/xorg/3.5/
Updating collection xorg
...
Updating file list from crux.nu::ports/crux-3.5/core/
Updating collection core
...
Updating file list from crux.nu::ports/crux-3.5/opt/
Updating collection opt
...
Updating file list from crux.nu::ports/crux-3.5/xorg/
Updating collection xorg
...
Finished successfully
The output reveals which files are downladed, updated and deleted.
ports -u does NOT update the CRUX-PPC ports. The CRUX-PPC ports are
stored in a git repository and must be downloaded and manually
extracted to /usr/ports/core-ppc, /usr/pors/opt-ppc and /usr/pors/xorg-ppc
After installing the ppc specific ports, the cooresponding generic
ports should be deleted to avoid confusion when building packages.
Listing Local Ports
When the local ports structure has been updated the directory /usr/ports/
will contain two package categories, base and opt. Under each of these
directories you will find ports. You can simply browse around in the