head	1.368;
access;
symbols
	pkgsrc-2005Q3:1.368.0.2
	pkgsrc-2005Q3-base:1.368
	pkgsrc-2005Q2:1.367.0.2
	pkgsrc-2005Q2-base:1.367
	pkgsrc-2005Q1:1.366.0.4
	pkgsrc-2005Q1-base:1.366
	pkgsrc-2004Q4:1.366.0.2
	pkgsrc-2004Q4-base:1.366
	pkgsrc-2004Q3:1.359.0.2
	pkgsrc-2004Q3-base:1.359
	pkgsrc-2004Q2:1.338.0.2
	pkgsrc-2004Q2-base:1.338
	pkgsrc-2004Q1:1.332.0.2
	pkgsrc-2004Q1-base:1.332
	pkgsrc-2003Q4:1.319.0.2
	pkgsrc-2003Q4-base:1.319
	netbsd-1-6-1:1.286.0.2
	netbsd-1-6-1-base:1.286
	netbsd-1-6:1.260.0.4
	netbsd-1-6-RELEASE-base:1.260
	pkgviews:1.258.0.2
	pkgviews-base:1.258
	buildlink2:1.244.0.2
	buildlink2-base:1.251
	netbsd-1-5-PATCH003:1.242
	netbsd-1-5-PATCH001:1.159
	netbsd-1-5-RELEASE:1.115
	netbsd-1-4-PATCH003:1.115
	netbsd-1-4-PATCH002:1.82
	comdex-fall-1999:1.69
	netbsd-1-4-PATCH001:1.57
	netbsd-1-4-RELEASE:1.53
	netbsd-1-3-PATCH003:1.44;
locks; strict;
comment	@# @;


1.368
date	2005.06.23.17.06.48;	author wiz;	state dead;
branches;
next	1.367;

1.367
date	2005.05.07.22.53.52;	author wiz;	state Exp;
branches;
next	1.366;

1.366
date	2004.11.30.21.05.24;	author jlam;	state Exp;
branches;
next	1.365;

1.365
date	2004.11.20.12.32.24;	author hubertf;	state Exp;
branches;
next	1.364;

1.364
date	2004.11.20.12.25.27;	author hubertf;	state Exp;
branches;
next	1.363;

1.363
date	2004.11.19.18.39.14;	author peter;	state Exp;
branches;
next	1.362;

1.362
date	2004.10.16.00.41.40;	author dan;	state Exp;
branches;
next	1.361;

1.361
date	2004.10.16.00.36.10;	author dan;	state Exp;
branches;
next	1.360;

1.360
date	2004.09.29.11.33.38;	author hubertf;	state Exp;
branches;
next	1.359;

1.359
date	2004.09.19.20.13.26;	author hubertf;	state Exp;
branches;
next	1.358;

1.358
date	2004.09.15.20.18.26;	author minskim;	state Exp;
branches;
next	1.357;

1.357
date	2004.09.10.10.53.13;	author sketch;	state Exp;
branches;
next	1.356;

1.356
date	2004.09.09.12.25.27;	author hubertf;	state Exp;
branches;
next	1.355;

1.355
date	2004.09.03.17.22.42;	author reed;	state Exp;
branches;
next	1.354;

1.354
date	2004.08.31.13.51.23;	author jmmv;	state Exp;
branches;
next	1.353;

1.353
date	2004.08.31.00.14.51;	author rh;	state Exp;
branches;
next	1.352;

1.352
date	2004.08.22.19.42.10;	author jlam;	state Exp;
branches;
next	1.351;

1.351
date	2004.08.12.10.07.28;	author jlam;	state Exp;
branches;
next	1.350;

1.350
date	2004.08.07.10.15.47;	author wiz;	state Exp;
branches;
next	1.349;

1.349
date	2004.08.06.15.27.21;	author jlam;	state Exp;
branches;
next	1.348;

1.348
date	2004.08.05.20.55.11;	author jlam;	state Exp;
branches;
next	1.347;

1.347
date	2004.08.04.16.14.34;	author jschauma;	state Exp;
branches;
next	1.346;

1.346
date	2004.08.04.16.10.40;	author jschauma;	state Exp;
branches;
next	1.345;

1.345
date	2004.07.30.20.52.44;	author jlam;	state Exp;
branches;
next	1.344;

1.344
date	2004.07.30.07.48.56;	author xtraeme;	state Exp;
branches;
next	1.343;

1.343
date	2004.07.29.06.40.35;	author xtraeme;	state Exp;
branches;
next	1.342;

1.342
date	2004.07.29.05.15.31;	author xtraeme;	state Exp;
branches;
next	1.341;

1.341
date	2004.07.24.01.57.07;	author hubertf;	state Exp;
branches;
next	1.340;

1.340
date	2004.07.04.17.41.58;	author wiz;	state Exp;
branches;
next	1.339;

1.339
date	2004.07.04.17.35.41;	author jmmv;	state Exp;
branches;
next	1.338;

1.338
date	2004.06.06.12.46.37;	author grant;	state Exp;
branches;
next	1.337;

1.337
date	2004.05.02.10.37.48;	author hubertf;	state Exp;
branches;
next	1.336;

1.336
date	2004.04.19.17.20.23;	author hubertf;	state Exp;
branches;
next	1.335;

1.335
date	2004.04.08.17.17.16;	author reed;	state Exp;
branches;
next	1.334;

1.334
date	2004.04.08.09.38.39;	author xtraeme;	state Exp;
branches;
next	1.333;

1.333
date	2004.04.07.22.57.16;	author dmcmahill;	state Exp;
branches;
next	1.332;

1.332
date	2004.02.18.18.06.24;	author jlam;	state Exp;
branches
	1.332.2.1;
next	1.331;

1.331
date	2004.02.17.03.24.28;	author snj;	state Exp;
branches;
next	1.330;

1.330
date	2004.02.16.18.44.32;	author snj;	state Exp;
branches;
next	1.329;

1.329
date	2004.02.16.18.11.59;	author jmmv;	state Exp;
branches;
next	1.328;

1.328
date	2004.02.12.07.08.21;	author minskim;	state Exp;
branches;
next	1.327;

1.327
date	2004.02.01.01.56.28;	author jlam;	state Exp;
branches;
next	1.326;

1.326
date	2004.02.01.00.29.01;	author snj;	state Exp;
branches;
next	1.325;

1.325
date	2004.01.27.09.10.26;	author agc;	state Exp;
branches;
next	1.324;

1.324
date	2004.01.24.15.32.59;	author grant;	state Exp;
branches;
next	1.323;

1.323
date	2004.01.23.23.46.44;	author wiz;	state Exp;
branches;
next	1.322;

1.322
date	2004.01.14.07.25.48;	author wiz;	state Exp;
branches;
next	1.321;

1.321
date	2004.01.14.06.57.45;	author rh;	state Exp;
branches;
next	1.320;

1.320
date	2003.12.14.21.47.32;	author kristerw;	state Exp;
branches;
next	1.319;

1.319
date	2003.11.19.22.31.47;	author hubertf;	state Exp;
branches;
next	1.318;

1.318
date	2003.11.12.21.16.39;	author wiz;	state Exp;
branches;
next	1.317;

1.317
date	2003.10.29.19.55.19;	author reed;	state Exp;
branches;
next	1.316;

1.316
date	2003.10.10.01.17.55;	author reed;	state Exp;
branches;
next	1.315;

1.315
date	2003.10.04.23.44.29;	author wiz;	state Exp;
branches;
next	1.314;

1.314
date	2003.10.04.19.59.38;	author agc;	state Exp;
branches;
next	1.313;

1.313
date	2003.10.04.19.34.46;	author agc;	state Exp;
branches;
next	1.312;

1.312
date	2003.10.03.15.32.55;	author hubertf;	state Exp;
branches;
next	1.311;

1.311
date	2003.09.28.20.22.08;	author hubertf;	state Exp;
branches;
next	1.310;

1.310
date	2003.09.23.01.27.53;	author yyamano;	state Exp;
branches;
next	1.309;

1.309
date	2003.09.22.13.18.31;	author wiz;	state Exp;
branches;
next	1.308;

1.308
date	2003.09.17.19.04.21;	author jmmv;	state Exp;
branches;
next	1.307;

1.307
date	2003.08.30.22.01.36;	author seb;	state Exp;
branches;
next	1.306;

1.306
date	2003.08.11.14.17.11;	author wiz;	state Exp;
branches;
next	1.305;

1.305
date	2003.08.09.10.25.43;	author seb;	state Exp;
branches;
next	1.304;

1.304
date	2003.07.28.08.08.59;	author seb;	state Exp;
branches;
next	1.303;

1.303
date	2003.07.14.21.23.51;	author wiz;	state Exp;
branches;
next	1.302;

1.302
date	2003.07.14.15.38.56;	author martti;	state Exp;
branches;
next	1.301;

1.301
date	2003.07.09.16.59.25;	author agc;	state Exp;
branches;
next	1.300;

1.300
date	2003.07.09.16.14.51;	author agc;	state Exp;
branches;
next	1.299;

1.299
date	2003.07.04.11.33.54;	author martti;	state Exp;
branches;
next	1.298;

1.298
date	2003.06.28.09.58.11;	author agc;	state Exp;
branches;
next	1.297;

1.297
date	2003.06.23.07.48.01;	author grant;	state Exp;
branches;
next	1.296;

1.296
date	2003.06.23.07.41.45;	author grant;	state Exp;
branches;
next	1.295;

1.295
date	2003.06.19.21.41.13;	author seb;	state Exp;
branches;
next	1.294;

1.294
date	2003.06.05.17.32.13;	author jmmv;	state Exp;
branches;
next	1.293;

1.293
date	2003.05.31.19.35.16;	author wiz;	state Exp;
branches;
next	1.292;

1.292
date	2003.05.08.13.31.06;	author zuntum;	state Exp;
branches;
next	1.291;

1.291
date	2003.05.06.17.40.18;	author jmmv;	state Exp;
branches;
next	1.290;

1.290
date	2003.05.06.00.15.52;	author zuntum;	state Exp;
branches;
next	1.289;

1.289
date	2003.04.04.20.15.51;	author jschauma;	state Exp;
branches;
next	1.288;

1.288
date	2003.03.25.16.24.57;	author salo;	state Exp;
branches;
next	1.287;

1.287
date	2003.02.23.10.45.39;	author wiz;	state Exp;
branches;
next	1.286;

1.286
date	2003.02.03.15.33.01;	author wiz;	state Exp;
branches;
next	1.285;

1.285
date	2003.02.03.11.13.54;	author jmmv;	state Exp;
branches;
next	1.284;

1.284
date	2003.01.29.08.50.11;	author grant;	state Exp;
branches;
next	1.283;

1.283
date	2003.01.28.22.03.00;	author jlam;	state Exp;
branches;
next	1.282;

1.282
date	2003.01.22.19.22.05;	author jdolecek;	state Exp;
branches;
next	1.281;

1.281
date	2003.01.19.17.38.40;	author jschauma;	state Exp;
branches;
next	1.280;

1.280
date	2003.01.10.17.26.35;	author jschauma;	state Exp;
branches;
next	1.279;

1.279
date	2003.01.10.11.58.02;	author agc;	state Exp;
branches;
next	1.278;

1.278
date	2003.01.04.16.04.06;	author wiz;	state Exp;
branches;
next	1.277;

1.277
date	2003.01.04.14.31.57;	author grant;	state Exp;
branches;
next	1.276;

1.276
date	2003.01.02.06.18.48;	author grant;	state Exp;
branches;
next	1.275;

1.275
date	2002.12.27.06.53.42;	author uebayasi;	state Exp;
branches;
next	1.274;

1.274
date	2002.12.10.15.02.24;	author schmonz;	state Exp;
branches;
next	1.273;

1.273
date	2002.12.03.10.51.47;	author hubertf;	state Exp;
branches;
next	1.272;

1.272
date	2002.11.28.14.21.32;	author salo;	state Exp;
branches;
next	1.271;

1.271
date	2002.11.17.09.00.30;	author salo;	state Exp;
branches;
next	1.270;

1.270
date	2002.11.08.09.29.14;	author wiz;	state Exp;
branches;
next	1.269;

1.269
date	2002.11.04.13.00.51;	author seb;	state Exp;
branches;
next	1.268;

1.268
date	2002.10.27.21.54.05;	author seb;	state Exp;
branches;
next	1.267;

1.267
date	2002.10.24.04.52.15;	author jlam;	state Exp;
branches;
next	1.266;

1.266
date	2002.10.23.19.21.18;	author jlam;	state Exp;
branches;
next	1.265;

1.265
date	2002.10.23.12.21.29;	author wiz;	state Exp;
branches;
next	1.264;

1.264
date	2002.10.21.13.58.14;	author wiz;	state Exp;
branches;
next	1.263;

1.263
date	2002.10.21.01.21.46;	author wiz;	state Exp;
branches;
next	1.262;

1.262
date	2002.09.19.12.48.04;	author lukem;	state Exp;
branches;
next	1.261;

1.261
date	2002.08.26.05.17.39;	author jlam;	state Exp;
branches;
next	1.260;

1.260
date	2002.08.12.14.23.47;	author agc;	state Exp;
branches;
next	1.259;

1.259
date	2002.07.29.21.10.18;	author wiz;	state Exp;
branches;
next	1.258;

1.258
date	2002.07.04.13.42.11;	author hubertf;	state Exp;
branches;
next	1.257;

1.257
date	2002.07.02.15.25.49;	author wiz;	state Exp;
branches;
next	1.256;

1.256
date	2002.07.02.11.26.05;	author agc;	state Exp;
branches;
next	1.255;

1.255
date	2002.06.30.03.52.32;	author rh;	state Exp;
branches;
next	1.254;

1.254
date	2002.06.30.03.43.43;	author rh;	state Exp;
branches;
next	1.253;

1.253
date	2002.06.27.09.50.42;	author hubertf;	state Exp;
branches;
next	1.252;

1.252
date	2002.06.25.21.21.44;	author agc;	state Exp;
branches;
next	1.251;

1.251
date	2002.06.20.20.15.46;	author jlam;	state Exp;
branches;
next	1.250;

1.250
date	2002.06.18.16.14.54;	author agc;	state Exp;
branches;
next	1.249;

1.249
date	2002.06.17.21.46.04;	author skrll;	state Exp;
branches;
next	1.248;

1.248
date	2002.06.17.09.51.27;	author wiz;	state Exp;
branches;
next	1.247;

1.247
date	2002.05.30.22.55.21;	author schmonz;	state Exp;
branches;
next	1.246;

1.246
date	2002.05.22.23.30.21;	author hubertf;	state Exp;
branches;
next	1.245;

1.245
date	2002.05.19.08.52.17;	author zuntum;	state Exp;
branches;
next	1.244;

1.244
date	2002.04.27.02.42.22;	author enami;	state Exp;
branches
	1.244.2.1;
next	1.243;

1.243
date	2002.04.13.12.59.52;	author wiz;	state Exp;
branches;
next	1.242;

1.242
date	2002.04.02.21.04.31;	author seb;	state Exp;
branches;
next	1.241;

1.241
date	2002.03.27.20.50.33;	author rh;	state Exp;
branches;
next	1.240;

1.240
date	2002.03.23.22.52.32;	author hubertf;	state Exp;
branches;
next	1.239;

1.239
date	2002.03.23.22.47.45;	author hubertf;	state Exp;
branches;
next	1.238;

1.238
date	2002.03.23.15.33.15;	author hubertf;	state Exp;
branches;
next	1.237;

1.237
date	2002.03.13.06.30.12;	author hubertf;	state Exp;
branches;
next	1.236;

1.236
date	2002.03.11.19.19.18;	author fredb;	state Exp;
branches;
next	1.235;

1.235
date	2002.03.11.19.12.07;	author fredb;	state Exp;
branches;
next	1.234;

1.234
date	2002.02.18.17.07.20;	author wiz;	state Exp;
branches;
next	1.233;

1.233
date	2002.02.18.16.40.34;	author seb;	state Exp;
branches;
next	1.232;

1.232
date	2002.02.15.09.33.43;	author skrll;	state Exp;
branches;
next	1.231;

1.231
date	2002.02.13.23.29.37;	author hubertf;	state Exp;
branches;
next	1.230;

1.230
date	2002.02.13.20.05.02;	author abs;	state Exp;
branches;
next	1.229;

1.229
date	2002.02.13.12.30.52;	author mjl;	state Exp;
branches;
next	1.228;

1.228
date	2002.02.12.09.36.00;	author skrll;	state Exp;
branches;
next	1.227;

1.227
date	2002.02.12.09.29.56;	author skrll;	state Exp;
branches;
next	1.226;

1.226
date	2002.01.11.14.41.41;	author agc;	state Exp;
branches;
next	1.225;

1.225
date	2002.01.06.21.48.40;	author fredb;	state Exp;
branches;
next	1.224;

1.224
date	2001.12.31.14.58.46;	author lukem;	state Exp;
branches;
next	1.223;

1.223
date	2001.12.31.14.09.15;	author abs;	state Exp;
branches;
next	1.222;

1.222
date	2001.12.26.15.06.35;	author mason;	state Exp;
branches;
next	1.221;

1.221
date	2001.12.15.20.25.34;	author agc;	state Exp;
branches;
next	1.220;

1.220
date	2001.12.12.16.30.04;	author wiz;	state Exp;
branches;
next	1.219;

1.219
date	2001.12.08.02.14.38;	author hubertf;	state Exp;
branches;
next	1.218;

1.218
date	2001.12.02.21.29.20;	author wiz;	state Exp;
branches;
next	1.217;

1.217
date	2001.11.30.01.26.32;	author wiz;	state Exp;
branches;
next	1.216;

1.216
date	2001.11.29.01.12.24;	author hubertf;	state Exp;
branches;
next	1.215;

1.215
date	2001.11.27.03.03.11;	author hubertf;	state Exp;
branches;
next	1.214;

1.214
date	2001.11.26.22.06.58;	author jlam;	state Exp;
branches;
next	1.213;

1.213
date	2001.11.25.19.10.27;	author jlam;	state Exp;
branches;
next	1.212;

1.212
date	2001.11.19.16.28.03;	author jlam;	state Exp;
branches;
next	1.211;

1.211
date	2001.11.08.08.54.04;	author jlam;	state Exp;
branches;
next	1.210;

1.210
date	2001.11.03.21.02.46;	author wiz;	state Exp;
branches;
next	1.209;

1.209
date	2001.11.03.20.43.53;	author hubertf;	state Exp;
branches;
next	1.208;

1.208
date	2001.10.31.04.24.16;	author jlam;	state Exp;
branches;
next	1.207;

1.207
date	2001.10.30.17.09.43;	author drochner;	state Exp;
branches;
next	1.206;

1.206
date	2001.10.26.17.15.57;	author jlam;	state Exp;
branches;
next	1.205;

1.205
date	2001.10.24.22.10.43;	author jlam;	state Exp;
branches;
next	1.204;

1.204
date	2001.10.24.20.06.19;	author jlam;	state Exp;
branches;
next	1.203;

1.203
date	2001.10.17.18.35.42;	author hubertf;	state Exp;
branches;
next	1.202;

1.202
date	2001.10.15.11.34.20;	author agc;	state Exp;
branches;
next	1.201;

1.201
date	2001.10.13.05.27.49;	author abs;	state Exp;
branches;
next	1.200;

1.200
date	2001.10.11.13.21.08;	author wiz;	state Exp;
branches;
next	1.199;

1.199
date	2001.10.11.11.11.15;	author martti;	state Exp;
branches;
next	1.198;

1.198
date	2001.10.02.11.15.29;	author abs;	state Exp;
branches;
next	1.197;

1.197
date	2001.09.30.22.10.33;	author abs;	state Exp;
branches;
next	1.196;

1.196
date	2001.09.29.23.15.45;	author hubertf;	state Exp;
branches;
next	1.195;

1.195
date	2001.09.29.23.14.38;	author hubertf;	state Exp;
branches;
next	1.194;

1.194
date	2001.09.27.23.17.41;	author jlam;	state Exp;
branches;
next	1.193;

1.193
date	2001.09.26.04.47.39;	author jmc;	state Exp;
branches;
next	1.192;

1.192
date	2001.09.24.08.59.09;	author agc;	state Exp;
branches;
next	1.191;

1.191
date	2001.09.21.09.04.22;	author skrll;	state Exp;
branches;
next	1.190;

1.190
date	2001.09.21.08.36.50;	author skrll;	state Exp;
branches;
next	1.189;

1.189
date	2001.09.19.10.45.32;	author wiz;	state Exp;
branches;
next	1.188;

1.188
date	2001.09.14.01.52.40;	author jlam;	state Exp;
branches;
next	1.187;

1.187
date	2001.09.09.20.36.08;	author agc;	state Exp;
branches;
next	1.186;

1.186
date	2001.09.08.20.09.46;	author jlam;	state Exp;
branches;
next	1.185;

1.185
date	2001.09.04.13.50.02;	author hubertf;	state Exp;
branches;
next	1.184;

1.184
date	2001.09.04.13.33.56;	author hubertf;	state Exp;
branches;
next	1.183;

1.183
date	2001.09.04.13.00.44;	author hubertf;	state Exp;
branches;
next	1.182;

1.182
date	2001.08.29.22.55.36;	author jlam;	state Exp;
branches;
next	1.181;

1.181
date	2001.08.25.02.17.02;	author jlam;	state Exp;
branches;
next	1.180;

1.180
date	2001.08.24.00.54.48;	author hubertf;	state Exp;
branches;
next	1.179;

1.179
date	2001.08.22.17.59.11;	author jlam;	state Exp;
branches;
next	1.178;

1.178
date	2001.08.22.17.53.30;	author jlam;	state Exp;
branches;
next	1.177;

1.177
date	2001.08.13.18.09.06;	author hubertf;	state Exp;
branches;
next	1.176;

1.176
date	2001.07.30.17.17.20;	author jlam;	state Exp;
branches;
next	1.175;

1.175
date	2001.07.26.15.14.05;	author jlam;	state Exp;
branches;
next	1.174;

1.174
date	2001.07.20.02.00.47;	author jlam;	state Exp;
branches;
next	1.173;

1.173
date	2001.07.17.21.19.37;	author jlam;	state Exp;
branches;
next	1.172;

1.172
date	2001.07.16.11.06.48;	author jlam;	state Exp;
branches;
next	1.171;

1.171
date	2001.07.16.11.00.32;	author jlam;	state Exp;
branches;
next	1.170;

1.170
date	2001.07.01.23.03.17;	author jlam;	state Exp;
branches;
next	1.169;

1.169
date	2001.06.30.21.10.43;	author jlam;	state Exp;
branches;
next	1.168;

1.168
date	2001.06.29.14.07.28;	author jlam;	state Exp;
branches;
next	1.167;

1.167
date	2001.06.29.05.07.36;	author jlam;	state Exp;
branches;
next	1.166;

1.166
date	2001.06.23.14.29.29;	author jlam;	state Exp;
branches;
next	1.165;

1.165
date	2001.06.23.14.19.09;	author jlam;	state Exp;
branches;
next	1.164;

1.164
date	2001.06.21.11.57.03;	author hubertf;	state Exp;
branches;
next	1.163;

1.163
date	2001.06.19.20.55.01;	author jlam;	state Exp;
branches;
next	1.162;

1.162
date	2001.06.19.16.23.33;	author jlam;	state Exp;
branches;
next	1.161;

1.161
date	2001.06.16.04.15.08;	author jlam;	state Exp;
branches;
next	1.160;

1.160
date	2001.05.20.01.58.19;	author hubertf;	state Exp;
branches;
next	1.159;

1.159
date	2001.05.09.17.43.22;	author skrll;	state Exp;
branches;
next	1.158;

1.158
date	2001.05.08.14.59.26;	author abs;	state Exp;
branches;
next	1.157;

1.157
date	2001.05.04.15.09.59;	author agc;	state Exp;
branches;
next	1.156;

1.156
date	2001.05.03.21.38.29;	author hubertf;	state Exp;
branches;
next	1.155;

1.155
date	2001.05.01.16.06.27;	author dmcmahill;	state Exp;
branches;
next	1.154;

1.154
date	2001.04.28.14.28.26;	author dmcmahill;	state Exp;
branches;
next	1.153;

1.153
date	2001.04.27.15.40.47;	author hubertf;	state Exp;
branches;
next	1.152;

1.152
date	2001.04.25.07.27.44;	author skrll;	state Exp;
branches;
next	1.151;

1.151
date	2001.04.17.12.50.04;	author agc;	state Exp;
branches;
next	1.150;

1.150
date	2001.04.17.08.18.30;	author hubertf;	state Exp;
branches;
next	1.149;

1.149
date	2001.04.14.19.20.47;	author dmcmahill;	state Exp;
branches;
next	1.148;

1.148
date	2001.03.29.11.20.57;	author agc;	state Exp;
branches;
next	1.147;

1.147
date	2001.03.27.03.19.43;	author hubertf;	state Exp;
branches;
next	1.146;

1.146
date	2001.03.23.17.11.17;	author skrll;	state Exp;
branches;
next	1.145;

1.145
date	2001.03.19.17.36.52;	author wiz;	state Exp;
branches;
next	1.144;

1.144
date	2001.03.19.11.28.47;	author dmcmahill;	state Exp;
branches;
next	1.143;

1.143
date	2001.03.12.11.23.01;	author skrll;	state Exp;
branches;
next	1.142;

1.142
date	2001.02.27.08.20.23;	author skrll;	state Exp;
branches;
next	1.141;

1.141
date	2001.02.17.15.09.51;	author skrll;	state Exp;
branches;
next	1.140;

1.140
date	2001.02.16.13.06.17;	author wiz;	state Exp;
branches;
next	1.139;

1.139
date	2001.02.09.14.48.39;	author agc;	state Exp;
branches;
next	1.138;

1.138
date	2001.02.09.14.32.27;	author agc;	state Exp;
branches;
next	1.137;

1.137
date	2001.02.02.03.42.42;	author hubertf;	state Exp;
branches;
next	1.136;

1.136
date	2001.01.28.03.17.41;	author itojun;	state Exp;
branches;
next	1.135;

1.135
date	2001.01.26.09.17.55;	author skrll;	state Exp;
branches;
next	1.134;

1.134
date	2001.01.24.09.53.52;	author garbled;	state Exp;
branches;
next	1.133;

1.133
date	2001.01.06.03.10.02;	author hubertf;	state Exp;
branches;
next	1.132;

1.132
date	2001.01.04.15.10.17;	author agc;	state Exp;
branches;
next	1.131;

1.131
date	2000.12.30.11.24.31;	author hubertf;	state Exp;
branches;
next	1.130;

1.130
date	2000.12.17.23.32.39;	author hubertf;	state Exp;
branches;
next	1.129;

1.129
date	2000.12.15.14.03.31;	author abs;	state Exp;
branches;
next	1.128;

1.128
date	2000.12.08.10.18.19;	author wiz;	state Exp;
branches;
next	1.127;

1.127
date	2000.12.07.01.23.48;	author hubertf;	state Exp;
branches;
next	1.126;

1.126
date	2000.12.06.17.15.58;	author hubertf;	state Exp;
branches;
next	1.125;

1.125
date	2000.12.06.17.12.32;	author hubertf;	state Exp;
branches;
next	1.124;

1.124
date	2000.11.02.03.03.39;	author wiz;	state Exp;
branches;
next	1.123;

1.123
date	2000.11.01.12.05.15;	author hubertf;	state Exp;
branches;
next	1.122;

1.122
date	2000.10.22.21.25.14;	author hubertf;	state Exp;
branches;
next	1.121;

1.121
date	2000.10.18.03.53.41;	author garbled;	state Exp;
branches;
next	1.120;

1.120
date	2000.10.17.15.51.34;	author hubertf;	state Exp;
branches;
next	1.119;

1.119
date	2000.10.17.15.29.47;	author hubertf;	state Exp;
branches;
next	1.118;

1.118
date	2000.10.17.15.12.00;	author hubertf;	state Exp;
branches;
next	1.117;

1.117
date	2000.10.17.15.00.18;	author hubertf;	state Exp;
branches;
next	1.116;

1.116
date	2000.10.17.14.52.31;	author hubertf;	state Exp;
branches;
next	1.115;

1.115
date	2000.10.13.23.21.53;	author jlam;	state Exp;
branches;
next	1.114;

1.114
date	2000.10.11.14.02.27;	author hubertf;	state Exp;
branches;
next	1.113;

1.113
date	2000.09.18.10.24.59;	author abs;	state Exp;
branches;
next	1.112;

1.112
date	2000.09.15.22.05.46;	author hubertf;	state Exp;
branches;
next	1.111;

1.111
date	2000.09.08.12.55.12;	author hubertf;	state Exp;
branches;
next	1.110;

1.110
date	2000.09.07.09.53.13;	author hubertf;	state Exp;
branches;
next	1.109;

1.109
date	2000.08.27.10.59.53;	author jlam;	state Exp;
branches;
next	1.108;

1.108
date	2000.08.25.20.30.20;	author tron;	state Exp;
branches;
next	1.107;

1.107
date	2000.08.17.15.53.58;	author wiz;	state Exp;
branches;
next	1.106;

1.106
date	2000.08.16.19.08.20;	author dmcmahill;	state Exp;
branches;
next	1.105;

1.105
date	2000.08.03.14.56.51;	author hubertf;	state Exp;
branches;
next	1.104;

1.104
date	2000.07.30.08.57.54;	author tron;	state Exp;
branches;
next	1.103;

1.103
date	2000.07.29.10.10.43;	author wiz;	state Exp;
branches;
next	1.102;

1.102
date	2000.07.28.01.40.05;	author hubertf;	state Exp;
branches;
next	1.101;

1.101
date	2000.07.28.01.19.43;	author hubertf;	state Exp;
branches;
next	1.100;

1.100
date	2000.07.21.06.56.35;	author rh;	state Exp;
branches;
next	1.99;

1.99
date	2000.07.20.12.58.11;	author rh;	state Exp;
branches;
next	1.98;

1.98
date	2000.07.20.12.56.13;	author rh;	state Exp;
branches;
next	1.97;

1.97
date	2000.07.19.02.27.16;	author hubertf;	state Exp;
branches;
next	1.96;

1.96
date	2000.07.16.17.20.20;	author hubertf;	state Exp;
branches;
next	1.95;

1.95
date	2000.07.06.16.52.12;	author hubertf;	state Exp;
branches;
next	1.94;

1.94
date	2000.07.06.15.08.30;	author hubertf;	state Exp;
branches;
next	1.93;

1.93
date	2000.07.01.20.12.03;	author hubertf;	state Exp;
branches;
next	1.92;

1.92
date	2000.06.30.11.09.53;	author wiz;	state Exp;
branches;
next	1.91;

1.91
date	2000.06.30.10.23.28;	author agc;	state Exp;
branches;
next	1.90;

1.90
date	2000.06.16.09.18.34;	author hubertf;	state Exp;
branches;
next	1.89;

1.89
date	2000.06.02.06.08.41;	author rh;	state Exp;
branches;
next	1.88;

1.88
date	2000.06.02.01.52.10;	author hubertf;	state Exp;
branches;
next	1.87;

1.87
date	2000.06.01.11.28.08;	author rh;	state Exp;
branches;
next	1.86;

1.86
date	2000.05.11.14.55.56;	author agc;	state Exp;
branches;
next	1.85;

1.85
date	2000.05.11.11.23.20;	author agc;	state Exp;
branches;
next	1.84;

1.84
date	2000.04.20.16.06.23;	author jdolecek;	state Exp;
branches;
next	1.83;

1.83
date	2000.03.10.17.57.11;	author hubertf;	state Exp;
branches;
next	1.82;

1.82
date	2000.02.10.22.39.34;	author abs;	state Exp;
branches;
next	1.81;

1.81
date	2000.02.10.02.09.17;	author abs;	state Exp;
branches;
next	1.80;

1.80
date	2000.01.14.10.32.35;	author abs;	state Exp;
branches;
next	1.79;

1.79
date	2000.01.14.09.20.47;	author rh;	state Exp;
branches;
next	1.78;

1.78
date	2000.01.13.23.39.18;	author hubertf;	state Exp;
branches;
next	1.77;

1.77
date	2000.01.05.21.59.16;	author hubertf;	state Exp;
branches;
next	1.76;

1.76
date	2000.01.05.19.40.21;	author hubertf;	state Exp;
branches;
next	1.75;

1.75
date	99.12.07.08.58.59;	author sakamoto;	state Exp;
branches;
next	1.74;

1.74
date	99.12.04.18.00.08;	author hubertf;	state Exp;
branches;
next	1.73;

1.73
date	99.11.26.18.06.21;	author hubertf;	state Exp;
branches;
next	1.72;

1.72
date	99.11.23.16.38.22;	author dmcmahill;	state Exp;
branches;
next	1.71;

1.71
date	99.11.17.15.57.45;	author agc;	state Exp;
branches;
next	1.70;

1.70
date	99.10.31.19.45.15;	author rh;	state Exp;
branches;
next	1.69;

1.69
date	99.09.29.15.23.54;	author agc;	state Exp;
branches;
next	1.68;

1.68
date	99.09.12.01.40.02;	author hubertf;	state Exp;
branches;
next	1.67;

1.67
date	99.09.09.22.10.56;	author tron;	state Exp;
branches;
next	1.66;

1.66
date	99.09.08.20.57.22;	author hubertf;	state Exp;
branches;
next	1.65;

1.65
date	99.08.31.08.38.57;	author rh;	state Exp;
branches;
next	1.64;

1.64
date	99.08.30.22.54.26;	author tron;	state Exp;
branches;
next	1.63;

1.63
date	99.08.30.22.48.05;	author tron;	state Exp;
branches;
next	1.62;

1.62
date	99.08.29.22.27.11;	author rh;	state Exp;
branches;
next	1.61;

1.61
date	99.08.28.11.36.22;	author dmcmahill;	state Exp;
branches;
next	1.60;

1.60
date	99.08.22.01.31.16;	author hubertf;	state Exp;
branches;
next	1.59;

1.59
date	99.08.21.02.15.23;	author hubertf;	state Exp;
branches;
next	1.58;

1.58
date	99.08.16.14.12.40;	author bad;	state Exp;
branches;
next	1.57;

1.57
date	99.07.09.15.29.43;	author agc;	state Exp;
branches;
next	1.56;

1.56
date	99.07.09.15.26.42;	author agc;	state Exp;
branches;
next	1.55;

1.55
date	99.07.09.14.53.11;	author agc;	state Exp;
branches;
next	1.54;

1.54
date	99.07.02.08.37.20;	author agc;	state Exp;
branches;
next	1.53;

1.53
date	99.04.15.20.39.38;	author tron;	state Exp;
branches;
next	1.52;

1.52
date	99.02.24.10.40.58;	author agc;	state Exp;
branches;
next	1.51;

1.51
date	99.02.19.01.44.41;	author tv;	state Exp;
branches;
next	1.50;

1.50
date	99.02.18.12.36.16;	author frueauf;	state Exp;
branches;
next	1.49;

1.49
date	99.02.10.14.55.00;	author frueauf;	state Exp;
branches;
next	1.48;

1.48
date	99.01.30.23.21.26;	author agc;	state Exp;
branches;
next	1.47;

1.47
date	99.01.26.20.03.12;	author abs;	state Exp;
branches;
next	1.46;

1.46
date	98.12.19.20.35.47;	author bad;	state Exp;
branches;
next	1.45;

1.45
date	98.11.26.06.37.22;	author hubertf;	state Exp;
branches;
next	1.44;

1.44
date	98.09.23.13.09.33;	author agc;	state Exp;
branches;
next	1.43;

1.43
date	98.08.24.10.31.00;	author agc;	state Exp;
branches;
next	1.42;

1.42
date	98.08.21.16.37.57;	author tsarna;	state Exp;
branches;
next	1.41;

1.41
date	98.08.12.02.52.35;	author tv;	state Exp;
branches;
next	1.40;

1.40
date	98.07.31.15.24.13;	author tv;	state Exp;
branches;
next	1.39;

1.39
date	98.07.16.06.50.46;	author hubertf;	state Exp;
branches;
next	1.38;

1.38
date	98.07.13.15.37.12;	author hubertf;	state Exp;
branches;
next	1.37;

1.37
date	98.07.03.06.51.37;	author hubertf;	state Exp;
branches;
next	1.36;

1.36
date	98.06.18.15.12.22;	author agc;	state Exp;
branches;
next	1.35;

1.35
date	98.06.10.09.01.12;	author agc;	state Exp;
branches;
next	1.34;

1.34
date	98.06.05.12.21.36;	author frueauf;	state Exp;
branches;
next	1.33;

1.33
date	98.06.03.15.06.06;	author agc;	state Exp;
branches;
next	1.32;

1.32
date	98.06.03.11.11.27;	author agc;	state Exp;
branches;
next	1.31;

1.31
date	98.05.25.22.01.57;	author tron;	state Exp;
branches;
next	1.30;

1.30
date	98.04.20.12.14.22;	author frueauf;	state Exp;
branches;
next	1.29;

1.29
date	98.04.20.08.25.46;	author frueauf;	state Exp;
branches;
next	1.28;

1.28
date	98.04.17.22.01.01;	author hubertf;	state Exp;
branches;
next	1.27;

1.27
date	98.04.17.21.47.26;	author hubertf;	state Exp;
branches;
next	1.26;

1.26
date	98.04.17.10.13.20;	author agc;	state Exp;
branches;
next	1.25;

1.25
date	98.04.16.14.10.53;	author frueauf;	state Exp;
branches;
next	1.24;

1.24
date	98.03.25.14.19.59;	author hubertf;	state Exp;
branches;
next	1.23;

1.23
date	98.03.18.07.10.30;	author hubertf;	state Exp;
branches;
next	1.22;

1.22
date	98.03.07.14.18.40;	author tron;	state Exp;
branches;
next	1.21;

1.21
date	98.03.05.16.37.14;	author hubertf;	state Exp;
branches;
next	1.20;

1.20
date	98.03.05.15.26.03;	author tron;	state Exp;
branches;
next	1.19;

1.19
date	98.02.27.02.46.29;	author hubertf;	state Exp;
branches;
next	1.18;

1.18
date	98.02.08.18.17.33;	author hubertf;	state Exp;
branches;
next	1.17;

1.17
date	98.02.08.18.15.08;	author hubertf;	state Exp;
branches;
next	1.16;

1.16
date	98.02.02.08.58.13;	author hubertf;	state Exp;
branches;
next	1.15;

1.15
date	98.02.02.08.10.41;	author hubertf;	state Exp;
branches;
next	1.14;

1.14
date	98.01.30.13.15.05;	author hubertf;	state Exp;
branches;
next	1.13;

1.13
date	98.01.30.13.11.42;	author hubertf;	state Exp;
branches;
next	1.12;

1.12
date	98.01.29.13.47.35;	author hubertf;	state Exp;
branches;
next	1.11;

1.11
date	98.01.28.15.37.19;	author hubertf;	state Exp;
branches;
next	1.10;

1.10
date	98.01.19.08.07.16;	author hubertf;	state Exp;
branches;
next	1.9;

1.9
date	98.01.03.06.18.00;	author hubertf;	state Exp;
branches;
next	1.8;

1.8
date	98.01.01.05.52.52;	author hubertf;	state Exp;
branches;
next	1.7;

1.7
date	97.12.29.19.44.32;	author hubertf;	state Exp;
branches;
next	1.6;

1.6
date	97.12.27.04.27.10;	author hubertf;	state Exp;
branches;
next	1.5;

1.5
date	97.12.27.04.13.29;	author hubertf;	state Exp;
branches;
next	1.4;

1.4
date	97.12.26.03.42.33;	author hubertf;	state Exp;
branches;
next	1.3;

1.3
date	97.11.13.13.47.38;	author hubertf;	state Exp;
branches;
next	1.2;

1.2
date	97.11.10.00.35.47;	author hubertf;	state Exp;
branches;
next	1.1;

1.1
date	97.11.05.09.35.52;	author hubertf;	state Exp;
branches;
next	;

1.244.2.1
date	2002.06.23.18.37.13;	author jlam;	state Exp;
branches;
next	;

1.332.2.1
date	2004.04.27.07.56.38;	author agc;	state Exp;
branches;
next	1.332.2.2;

1.332.2.2
date	2004.04.27.08.56.50;	author agc;	state Exp;
branches;
next	;


desc
@@


1.368
log
@Remove Packages.txt, replaced by doc/pkgsrc.txt.
@
text
@# $NetBSD: Packages.txt,v 1.367 2005/05/07 22:53:52 wiz Exp $
###########################################################################

The "Documentation on the NetBSD Packages System" is now known as 
"The pkgsrc Guide", which can be found in various places and formats:

 * ASCII:      pkgsrc/doc/pkgsrc.txt
               http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.txt
 * HTML:       pkgsrc/doc/pkgsrc.html
               http://www.NetBSD.org/Documentation/pkgsrc/
 * PDF:        http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.pdf
 * PostScript: http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.ps

This file will be removed after 2005Q2.
@


1.367
log
@This file will be removed after 2005Q2.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.366 2004/11/30 21:05:24 jlam Exp $
@


1.366
log
@Typo.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.365 2004/11/20 12:32:24 hubertf Exp $
d14 1
a14 3

This notice will be removed at some point in time when people got used
to the new path. - HF
@


1.365
log
@add urls to pdf etc. too
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.364 2004/11/20 12:25:27 hubertf Exp $
d9 1
a9 1
 * HTML:       pkgsrc.doc/pkgsrc.html
@


1.364
log
@Bang bang, you're dead - point to the new location
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.363 2004/11/19 18:39:14 peter Exp $
d5 9
a13 1
"The pkgsrc Guide", which can be found in pkgsrc/doc/pkgsrc.{txt,html}.
@


1.363
log
@Remove the documentation for optional patch files, which was removed some
time ago.

ok wiz@@
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.362 2004/10/16 00:41:40 dan Exp $
d4 2
a5 4
			==========================
			   Documentation on the
			   NetBSD Package System
			==========================
d7 2
a8 3850
		      Hubert Feyrer, Alistair Crooks


Table of contents:
==================

Run this command to produce a table of contents:
 sed '/^.====/{g;p;};h;d' Packages.txt


 0 Intro
 =======

There is a lot of software freely available for Unix based systems, which
usually runs on NetBSD, too, sometimes with some modifications. The NetBSD
packages collection incorporates any such changes necessary to make that
software run on NetBSD, and makes the installation (and re-installation) of
the software package easy by means of a single command.

The NetBSD package system is used to enable such freely available
third-party software to be built easily on NetBSD hosts. Once the software
has been built, it is manipulated with the pkg_* tools so that installation
and de-installation, printing of an inventory of all installed packages and
retrieval of one-line comments or more verbose descriptions are all simple.

Both the NetBSD packages collection and the NetBSD package system are
derived from FreeBSD.


 0.1 Overview
 ============

This document is divided into two parts.  The first, "User's Guide",
describes how one can use one of the packages in the Package
Collection, either by installing a precompiled binary package, or
by building one's copy using the NetBSD package system.  The
second part, "Package Constructor's Guide", explains how to prepare
a package so it can be easily built by other NetBSD users without
knowing about the package's building details.


 0.2 Terminology
 ===============

There has been a lot of talk about "ports", "packages", etc. so far. Here
is a description of all the terminology used within this document:

 * Package:
   A set of files and building instructions that describe what's necessary
   to build a certain piece of software using the NetBSD package
   system. Packages are traditionally stored under /usr/pkgsrc.

 * The NetBSD package system:
   This is the part of the NetBSD operating system handling building
   (compiling), installing, and removing of packages.

 * Distfile:
   This term describes the file or files that are provided by the author
   of the piece of freely available software to distribute his work. All
   the changes necessary to build on NetBSD are reflected in the
   corresponding package. Usually the distfile is in the form of a
   compressed tar-archive, but other types are possible, too. Distfiles
   are stored below /usr/pkgsrc/distfiles.

 * Port:
   This is the term used by FreeBSD people for what we call a package.
   In NetBSD terminology, "port" refers to a different architecture.

 * Precompiled (binary) package:
   A set of binaries built by the NetBSD package system from a distfile
   using the NetBSD package system and stuffed together in a single .tgz
   file so it can be installed on machines of the same machine architecture
   without the need to recompile. Packages are generated in
   /usr/pkgsrc/packages by the NetBSD package system; there is also an
   archive on ftp.NetBSD.org.

   Sometimes, this is referred to by the term "package" too,
   especially in the context of precompiled packages.

 * Program:
   The piece of software to be installed which will be constructed from
   all the files in the Distfile by the actions defined in the
   corresponding package.

 * NetBSD RCS IDs:
   Some files in a package contain RCS IDs to reflect which version of
   that file this is (inserted automatically by cvs). These IDs are used
   in several examples within this document, but as this document itself
   is managed by CVS, it can't list the RCS IDs in plaintext. Instead, the
   $s are written as <$>, resulting in <$>NetBSD<$> and <$>Id<$>.


 0.3 Typography
 ==============

Right now this document is written in plain ASCII text, and there's not
much typography applied here. It's being moved to DocBook.

When giving examples for commands, shell prompts are used to show if the
command should/can be issued as root, or if "normal" user privileges are
sufficient. We use a "#" for root's shell prompt, and a "%" for users'
shell prompt, assuming they use the C-shell or tcsh.


====================
Part I: User's Guide
====================

 1 Installing a precompiled binary package
 =========================================

This section describes how to find, retrieve and install a precompiled
binary package that someone else already prepared for your type of machine.


 1.1 Where to get
 ================

Precompiled packages are stored on ftp.NetBSD.org and its mirrors in the
directory /pub/NetBSD/packages for anon FTP access. Please pick the right
subdirectory there as indicated by "uname -p". In that directory, there
is a subdirectory for each category plus a subdirectory "All" which includes
the actual binaries in .tgz-files. The category subdirectories use symbolic
links to those files. (This is the same directory layout as in
/usr/pkgsrc/packages).

This same directory layout applies for CDROM distributions, only that the
directory may be rooted somewhere else, probably somewhere below /cdrom.
Please consult your CDROM's documentation for the exact location!


 1.2 How to use
 ==============

If you have the files on a CDROM or downloaded them to your hard disk, you
can install them with the following command (be sure to su to root first):

	# pkg_add /path/to/package.tgz

If you have FTP access and you don't want to download the packages via FTP
prior to installation, you can do this automatically by giving pkg_add an
ftp-URL:

	# pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.tgz

If there is any doubt, the uname utility can be used to determine the
<OS Ver>, and <arch> by running "uname -rp".

Also note that any prerequisite packages needed to run the package in
question will be installed, too, assuming they are present where you install
from.

After you've installed packages, be sure to have /usr/pkg/bin in your $PATH
so you can actually start the just installed program.


 1.3 A word of warning
 =====================

Please pay very careful attention to the warnings expressed in that manual
page about the inherent dangers of installing binary packages which you did
not create yourself, and the security holes that can be introduced onto
your system by indiscriminate adding of such files.


 2 Installing by Building
 ========================

This assumes that the package is already part of the NetBSD package system.
If it is not, then you are advised to read part II of this document,
"Package Constructor's Guide".


 2.1 Requirements
 ================

To build packages from source on a NetBSD system the "comp" and the "text"
distribution sets must be installed. If you want to build X11 related
packages the "xbase" and "xcomp" distribution sets are required, too.


 2.2 Where to get pkgsrc
 =======================

There are three ways to get pkgsrc. Either as a tar file, via SUP, or
via CVS. All three ways are described here.

To get the package source going, you need to get the pkgsrc.tar.gz file
from ftp://ftp.NetBSD.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz and
unpack it into /usr.

As an alternative, you can get pkgsrc via the Software Update Protocol,
SUP. To do so, make sure your supfile has a line saying "release=pkgsrc" in
it, see the examples in /usr/share/examples/supfiles, and that the
directory /usr/pkgsrc does exist. Then, simply start "sup -v
/path/to/your/supfile".

To get pkgsrc via CVS, make sure you have cvs installed. If not present on
your system, it can be found as precompiled binary on ftp.NetBSD.org.
To do an initial (full) checkout of pkgsrc, do the following steps:

	% setenv CVSROOT anoncvs@@anoncvs.NetBSD.org:/cvsroot
	% setenv CVS_RSH ssh
	% cd /usr
	% cvs checkout -P pkgsrc

This will create the "pkgsrc" directory in your /usr, and all the
package source will be stored under /usr/pkgsrc.  To update pkgsrc
after the initial checkout, make sure you have CVS_RSH set as above,
then do:

	% cd /usr/pkgsrc
	% cvs -q update -dP

Please also note that it is possible to have multiple copies of the
pkgsrc hierarchy in use at any one time - all work is done relatively
within the pkgsrc tree.


 2.3 Fetching distfiles
 ======================

There is one gotcha: The distribution file (i.e. the unmodified source)
must exist on your system for the packages system to be able to build it.
If it does not, then ftp(1) is used to fetch the distribution files
automatically.

You can overwrite some of the major distribution sites to fit to sites
that are close to your own.  Have a look at
pkgsrc/mk/bsd.pkg.defaults.mk to find some examples - in particular,
look for the MASTER_SORT, MASTER_SORT_REGEX and INET_COUNTRY
definitions.  This may save some of your bandwidth and time.

You can change these settings either in your shell's environment, or,
if you want to keep the settings, by editing the /etc/mk.conf file,
and adding the definitions there.

If you don't have a permanent Internet connection and you want to know
which files to download, "make fetch-list" will tell you what you'll need.
Put these distfiles into /usr/pkgsrc/distfiles.


 2.4 How to build and install
 ============================

Assuming that the distfile has been fetched (see previous section), become
root and change into the relevant directory. Then you can type

	% make

at the shell prompt to build the various components of the package, and

	# make install

at the shell prompt to install the various components into the correct
places on your system.

Taking the top system utility as an example, we can install it on our
system by building as shown in appendix A.1.

The program is installed under the default root of the packages tree -
/usr/pkg. Should this not conform to your tastes, simply set the LOCALBASE
variable in your environment, and it will use that value as the root of
your packages tree. So, to use /usr/local, set

	LOCALBASE=/usr/local

in your environment.  Please note that you should use a root which is
dedicated to packages and not shared with other programs (ie, do not try
and use LOCALBASE=/usr).  Also, you should not try to add any of your
own files or directories (such as, for example, src, obj, or pkgsrc) below
the LOCALBASE tree.  This is to prevent possible conflicts between programs
and other files installed by the package system and whatever else may have
been installed there.

There is, of course, one exception to this - X11 packages are traditionally
installed in the X11 tree. The definition used to identify the root of the
X11 tree is the X11BASE definition.

It is possible to install X11 packages in the LOCALBASE tree, for
which you must install the xpkgwedge package
(pkgsrc/pkgtools/xpkgwedge) - see section 7.1 for further details.

Some packages look in /etc/mk.conf to alter some configuration options
at build time.  Have a look at pkgsrc/mk/bsd.pkg.defaults.mk to
get an overview of what will be set there by default.  Environment
variables such as LOCALBASE, and X11BASE can be set in /etc/mk.conf to
save having to remember to set them each time you want to use pkgsrc.

Occasionally, people want to "look under the covers" to see what is
going on when a package is building or being installed. This may be
for debugging purposes, or out of simple curiosity. A number of utility
values have been added to help with this.

(1) If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a
huge amount of information will be displayed.  As a worked example,

	make patch PKG_DEBUG_LEVEL=2

will show all the commands that are invoked, up to and including the
"patch stage".

(2) If you want to know the value of a certain make(1) definition, then
the VARNAME definition should be used, in conjunction with the show-var
target. e.g.

	make show-var VARNAME=DISTFILES

will show the expansion of the make(1) variable "DISTFILES".

If you want to de-install and re-install a binary package that you've
created (see next section), that you put into pkgsrc/packages manually or
that's located on a remote FTP server, you can use the the "bin-install"
target. This target will install a binary package - if available - via
pkg_add, and do a "make package" else. The list of remote FTP sites
searched is kept in the variable BINPKG_SITE, which defaults to
ftp.NetBSD.org. Any flags that should be added to pkg_add(8) can be put
into BIN_INSTALL_FLAGS. See pkgsrc/mk/bsd.pkg.defaults.mk for more details.

A final word of warning: If you setup a system that has a non-standard
setting for LOCALBASE (or X11BASE, for that matter), be sure to set that
before any packages are installed, as you can not use several directories
for the same purpose. Doing so will result in pkgsrc not being able to
properly detect your installed packages, and fail miserably. Note also that
precompiled binary packages are usually built with the default LOCALBASE of
/usr/pkg, and that you should *not* install any if you use a non-standard
LOCALBASE.


 2.5 Selecting the compiler
 ==========================

By default, pkgsrc will use GCC to build packages.  This may be
overridden by setting the following variables in /etc/mk.conf:

 * PKGSRC_COMPILER:
   This is a list of values specifying the chain of compilers to invoke
   when building packages.  Valid values are:

	distcc		distributed C/C++ (chainable)
	ccache		compiler cache (chainable)
	gcc		GNU
	mipspro		Silicon Graphics, Inc. MIPSpro (n32/n64)
	mipspro-ucode	Silicon Graphics, Inc. MIPSpro (o32)
	sunpro		Sun Microsystems, Inc. WorkShip/Forte/Sun
			ONE Studio

   The default is "gcc".  You can use ccache and/or distcc with an
   appropriate PKGSRC_COMPILER setting, e.g. "ccache gcc".  This variable
   should always be terminated with a value for a real compiler.

 * GCC_REQD:
   This specifies the minimum version of GCC to use when building
   packages.  If the system GCC doesn't satisfy this requirement, then
   pkgsrc will build and install one of the GCC packages to use instead.


 3 Making precompiled packages
 =============================


 3.1 Packaging a single package
 ==============================

Once you have built and installed the package as mentioned above, you can
build it into a "binary package" - you might want to do this so that you
can use the binaries you have just built on another NetBSD system, or to
provide a simple means for others to use your binary package instead of
wasting CPU time - this is done by changing to the appropriate directory in
the pkgsrc tree, and typing the command

	# make package

at the shell prompt. This will build and install your package (if not
already done), and then construct a binary package out of the results so
that you can use the pkg_* tools to manipulate this. The binary package is
stored under /usr/pkgsrc/packages, it's in the form of a gzipped file at
the present time. See appendix A.2 for a continuation of the above top
example.

Please see the "submitting" section later in this document on how to submit
such a binary package.


 3.2 Doing a bulk build of all packages
 ======================================

If you want to get a full set of precompiled binary packages, this section
describes how to get them. Beware that the bulk build will remove all
currently installed packages from your system! Having a FTP server
configured either on the machine doing the bulk builds or on a nearby NFS
server can help to make the packages available to everyone. See ftpd(8) for
more information. If you use a remote NFS server's storage, be sure to not
actually compile on NFS storage, as this slows things down a lot.


 3.2.1 Configuration
 ===================

 3.2.1.1 /etc/mk.conf
 ====================

You may want to set things in /etc/mk.conf.  Look at
pkgsrc/mk/bsd.pkg.defaults.mk for details of the default settings.
You will want to make sure that ACCEPTABLE_LICENSES meet your local
policy:

    PACKAGES?=              ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
    WRKOBJDIR?=             /usr/tmp/pkgsrc   # build here instead of in pkgsrc
    BSDSRCDIR=              /usr/src
    BSDXSRCDIR=             /usr/xsrc         # for x11/xservers
    OBJHOSTNAME?=           yes               # use work.`hostname`
    FAILOVER_FETCH=         yes               # insist on the correct checksum
    PKG_DEVELOPER?=         yes
    _ACCEPTABLE=            yes

Other packages which must be installed during the bulk build to modify the
build behaviour may be added to the BULK_PREREQ variable.  Note that currently
the only package for which BULK_PREREQ makes sense is xpkgwedge.


 3.2.1.2 build.conf
 ==================

In pkgsrc/mk/bulk, copy ``build.conf-example'' to ``build.conf'' and
edit it, following the comments in that file. This is the config
file that determines where log files are generated after the build,
where to mail the build report, where your pkgsrc is located and
which user to su(8) to to do a 'cvs update'.

 3.2.1.3 pre-build.local
 =======================

It is possible to configure the bulk build to perform certain site
specific tasks at the end of the pre-build stage.  If the file
``pre-build.local'' exists in pkgsrc/mk/bulk it will be executed
(as a sh(1) script) at the end of the usual pre-build stage.  An
example use of pre-build.local is to have the line:

	# echo "I do not have enough disk space to build this pig." \
		> games/crafty-book-enormous/$BROKENF

to prevent the system from trying to build a particular package
which requires nearly 3 Gb of disk space.
   
 3.2.2 Other environmental considerations
 ========================================

As /usr/pkg will be completely deleted at the start of bulk builds,
make sure your login shell is placed somewhere else. Either drop it into
/usr/local/bin (and adjust your login shell in the password file), or
(re-)install it via pkg_add from /etc/rc.local, so you can login after a
reboot (remember that your current process won't die if the package is
removed, you just can't start any new instances of the shell any more).
Also, if you use a OS version below 1.5 or you still want to use the
pkgsrc version of ssh for some reason, be sure to install ssh before
starting it from rc.local:

	( cd /usr/pkgsrc/security/ssh ; make bulk-install )
	if [ -f	/usr/pkg/etc/rc.d/sshd ]; then
	   /usr/pkg/etc/rc.d/sshd
	fi

Not doing so will result in you being not able to log in via ssh
after the bulk build is finished or if the machine gets rebooted
or crashes. You have been warned! :)


 3.2.3 Operation
 ===============

Make sure you don't need any of the packages still installed.
BEWARE: During the bulk build, ALL packages will be removed!!!
Be sure to remove all other things that might interfere with builds, like
some libs installed in /usr/local, etc. then become root and type:

        # cd /usr/pkgsrc
        # sh mk/bulk/build

If for some reason your last build didn't complete (power failure,
system panic, ...), you can continue it by running:

	# sh mk/bulk/build restart

At the end of the bulk run, you will get a summary via mail, and find
build logs in the directory specified by "FTP" in the "build.conf"
file.


 3.2.4 What it does
 ==================

The bulk builds consist of three steps:

1. pre-build: The script updates your pkgsrc via (anon)cvs, then cleans
	out any broken distfiles, and removes all packages installed.

2. the bulk build: This is basically 'make bulk-package' with an optimised
	order in which packages will be built. Packages that don't require
	other packages will be built first, and packages with many depends
	will be built later.

3. post-build: Generates a report that's placed in the directory specified
	in the build.conf file named ``broken.html'', a short version of
	that report will also be mailed to the build's admin.

During the build, a list of broken packages will be compiled in
/usr/pkgsrc/.broken  (or .../.broken.${MACHINE} if OBJMACHINE is set),
individual build logs of broken builds can be found in the package's
directory. These files are used by the bulk-targets to mark broken builds
to not waste time trying to rebuild them, and they can be used to debug
these broken package builds later.

	
 3.2.5 Disk space requirements
 =============================

Currently, roughly the following requirements are valid for
1.6.1/i386 as of 20031003:

 * Distfiles:                         5 GB (NFS ok)
 * Full set of all binaries:          5 GB (NFS ok)
 * Temp space for compiling:          2 GB (local disk recommended)

For 1.5/alpha:

 * Full set of all binaries:          1300MB (NFS ok)

Note that all pkgs will be de-installed as soon as they are turned into a
binary package, and that work-sources are removed, so there is no huge
demand to disk space. Afterwards, if the package is needed again, it will
be installed via pkg_add instead of building again, so there are no cycles
wasted by recompiling.


 3.2.6 Setting up a sandbox for chroot'ed builds
 ===============================================

If you don't want all the pkgs nuked from a machine (rendering it useless
for anything but pkg compiling), there is the possibility of doing the pkg
bulk build inside a chroot environment.

The first step to do so is setting up a chroot sandbox, e.g. /usr/sandbox.
Extract all sets from a NetBSD installation or doing a "make distribution
DESTDIR=/usr/sandbox" in src/etc, also don't forget to install X - if you
are a developer and want to upload the resulting binary packages to
ftp.NetBSD.org, make sure you are using the default X version for your
architecture and release (up to 1.6, that is 3.3.6 for all architectures).
Then, make sure the following items are present and properly configured:

 * Kernel:
   cp /netbsd /usr/sandbox
 * /dev/*:
   cd /usr/sandbox/dev ; sh MAKEDEV all
 * /etc/resolv.conf (for security/smtpd and mail):
   cp /etc/resolv.conf /usr/sandbox/etc
 * working(!) mail config (hostname, sendmail.cf):
   cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
 * /etc/localtime (for security/smtpd):
   ln -sf /usr/share/zoneinfo/GMT /usr/sandbox/etc/localtime
 * /usr/src (system sources, for sysutils/aperture, net/ppp-mppe):
   ln -s ../disk1/cvs .
   ln -s cvs/src-1.6 src
   ln -s cvs/pkgsrc .
 * create /var/db/pkg (not part of default install):
   mkdir /usr/sandbox/var/db/pkg
 * create /usr/pkg (not part of default install)
   mkdir /usr/sandbox/usr/pkg
 * checkout pkgsrc from cvs, into /usr/sandbox/usr/pkgsrc
   cvs -d cvs.NetBSD.org:/cvsroot co pkgsrc
   Do not mount/link this to the copy of your pkgsrc tree you do
   development in, as this will likely cause problems! 
 * /usr/pkgsrc/packages & .../distfiles (point outside of sandbox)
 * /etc/mk.conf, see 3.2.1.1
 * adjust .../mk/bulk/build.conf
 * If you have set CVS_USER in build.conf, make sure that account exists
   and can do a "cvs ${CVS_FLAGS} update" properly!

When the chroot sandbox is setup, you can start the build with the following
steps:

	# cd /usr/sandbox/usr/pkgsrc
	# sh mk/bulk/do-sandbox-build

This will just jump inside the sandbox and start thrash^Wbuilding.
At the end of the build, mail will be sent with the results of the build.
Created binary pkgs will be in /usr/sandbox/usr/pkgsrc/packages (wherever
that points/mounts to/from).

 3.2.7 Building a partial set of packages
 ========================================

In addition to building a complete set of all packages in pkgsrc, the
pkgsrc/mk/bulk/build script may be used to build a subset of the
packages contained in pkgsrc.  By setting defining SPECIFIC_PKGS
in /etc/mk.conf, the variables 

	SITE_SPECIFIC_PKGS
	HOST_SPECIFIC_PKGS
	GROUP_SPECIFIC_PKGS
	USER_SPECIFIC_PKGS

will define the set of packages which should be built.  The bulk build
code will also include any packages which are needed as dependencies
for the explicitly listed packages.

One use is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
periodically to have a complete set of the binary packages needed for
your site available without the overhead of building extra packages
that are not needed.

 3.3 Creating a multiple CD-ROM packages collection
 ==================================================

After your bulk pkgsrc build has completed, you may wish to create a CD-ROM
set of the resulting binary packages to assist in installing packages on
other machines.  The package pkgsrc/pkgtools/cdpack provides a simple tool for
creating the ISO 9660 images.  `cdpack' arranges the packages on the CD-ROM's
in a way that keeps all the dependencies for given package on the same
CD as that package.


 3.3.1 Example of cdpack
 =======================

Complete documentation for cdpack is found in cdpack(1).  The following
short example assumes that the binary packages are left in
/usr/pkgsrc/packages/All and that sufficient disk space exists in /u2
to hold the ISO 9660 images.

        # mkdir /u2/images
        # pkg_add /usr/pkgsrc/packages/All/cdpack
	# cdpack /usr/pkgsrc/packages/All /u2/images

If you wish to include a common set of files (COPYRIGHT, README, etc)
on each CD in the collection, then you need to create a directory which
contains these files.  For example

	# mkdir /tmp/common
	# echo "This is a README" > /tmp/common/README
	# echo "Another file" > /tmp/common/COPYING
	# mkdir /tmp/common/bin
	# echo "#!/bin/sh" > /tmp/common/bin/myscript
	# echo "echo Hello world" >> /tmp/common/bin/myscript
	# chmod 755 /tmp/common/bin/myscript

Now create the images with

	# cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images

and each image will contain "README", "COPYING", and "bin/myscript"
in their root directories.


====================================
Part II: Package Constructor's Guide
====================================

 4 Package components - files, directories and contents
 ======================================================

Whenever you're preparing a package, there are a number of files involved
which are described in the following sections.


 4.1 Makefile
 ============

Building, installation and creation of a binary package are all controlled
by the package's Makefile.

There is a Makefile for each package. This file includes the standard
bsd.pkg.mk file (referenced as "../../mk/bsd.pkg.mk"), which sets all the
definitions and actions necessary for the package to compile and install
itself. The mandatory fields are the DISTNAME which specifies the base name
of the distribution file to be downloaded from the site on the Internet,
MASTER_SITES which specifies that site, CATEGORIES which denotes the
categories into which the package falls, PKGNAME which is the name of the
package, the MAINTAINER name, and the COMMENT variable, which should
contain a one-line description of the package (the package name should not
appear, it will be added automatically). The maintainer variable is there
so that anyone who quibbles with the (always completely correct) decisions
taken by the guy who maintains the port can complain vigorously.

The MASTER_SITES may be set to one of the predefined sites:

	${MASTER_SITE_APACHE}
	${MASTER_SITE_DEBIAN}
	${MASTER_SITE_GNOME}
	${MASTER_SITE_GNU}
	${MASTER_SITE_GNUSTEP}
	${MASTER_SITE_MOZILLA}
	${MASTER_SITE_PERL_CPAN}
	${MASTER_SITE_SOURCEFORGE}
	${MASTER_SITE_SUNSITE}
	${MASTER_SITE_R_CRAN}
	${MASTER_SITE_SUSE}
	${MASTER_SITE_TEX_CTAN}
	${MASTER_SITE_XCONTRIB}
	${MASTER_SITE_XEMACS}

If one of these predefined sites is chosen, you may require the ability to
specify a subdirectory of that site.  This is in fact almost always the
case with all of the above.  Since these macros may expand to more than one
actual site, you MUST use the following construct to specify a
subdirectory:

	${MASTER_SITE_GNU:=subdirectory/name/}
	${MASTER_SITE_SOURCEFORGE:=project_name/}

(Note the trailing slash after the subdirectory name.) Use of the deprecated
MASTER_SITE_SUBDIR will not work.

If the package has multiple DISTFILES or multiple PATCHFILES from different
sites, set SITES_foo to a list of URI's where file "foo" may be found. "foo"
includes the suffix, e.g.

	DISTFILES=${DISTNAME}${EXTRACT_SUFX}
	DISTFILES+=foo-file.tar.gz
	SITES_foo-file.tar.gz=http://www.somewhere.com/somehow/ \
			http://www.somewhereelse.com/mirror/somehow/

Note, that the normal default setting of DISTFILES must be made explicit
if you want to add to it (rather than replace it), as you usually would.

Currently the following values are available for CATEGORIES. If more than
one is used, they need to be separated by spaces:

	archivers
	audio
	benchmarks
	biology
	cad
	chat
	comms
	converters
	cross
	databases
	devel
	editors
	emulators
	finance
	fonts
	games
	geography
	graphics
	ham
	inputmethod
	lang
	mail
	math
	mbone
	meta-pkgs
	misc
	multimedia
	net
	news
	packages
	parallel
	pkgtools
	print
	security
	shells
	sysutils
	textproc
	time
	wm
	www
	x11

See the NetBSD packages(7) manual page for a description of all available
options and variables.

Please pay attention to the following gotchas:

 - Add MANCOMPRESSED (if not already there) if manpages are installed in
   compressed form by the package; see comment in bsd.pkg.mk
 - Replace /usr/local by ${PREFIX} in all files  (see patches below)
 - If the package installs any info files, see the section `Packages providing
   info files' in this document.
 - Adjust MAINTAINER to be either yourself, if you plan to maintain the
   package for future updates, or set it to the default MAINTAINER
   tech-pkg@@NetBSD.org.
 - If there exists a home page for the software in question, please
   add the variable HOMEPAGE right after MAINTAINER. The value of this
   variable should be the URL for the home page.
 - Please also set the COMMENT variable to a short description of the
   package. The description should start with a capital letter.


 4.2 distinfo
 ============

Most important, the mandatory message digest, or checksum, of all the
distfiles needed for the package to compile, confirming they match the
original file distributed by the author.  This ensures that the
distfile retrieved from the Internet has not been corrupted during
transfer or altered by a malign force to introduce a security hole.
It is best generated using the "make makesum" command.  The digest
algorithm used was, at one stage, md5, but that was felt lacking
compared to sha1, and so sha1 is now the default algorithm.  The
distfile size is also generated and stored in new distinfo files.
The pkgsrc/pkgtools/digest utility calculates all of the digests
in the distinfo file, and it provides various different algorithms.
At the current time, the algorithms provided are:

	md5, rmd160, sha1, sha256, sha384 and sha512

Some packages have different sets of distfiles on a per architecture
basis. (A good example is pkgsrc/www/navigator). These are kept in the
same distinfo file and care should be taken when upgrading such a
package to ensure distfile information is not lost.

The message digest/checksum for all the official patches found in the
patches/ directory (see section 4.3) for the package is also stored in
the distinfo file.  This is a message digest/checksum of all lines in
the patch file except the NetBSD RCS Id.  This file is generated by
invoking "make makepatchsum".


 4.3 patches/*
 =============

This directory contains files that are used by the patch(1) command to
modify the sources as distributed in the distribution file into a form that
will compile and run perfectly on NetBSD.  The files are applied
successively in alphabetic order (as returned by a shell "patches/patch-*"
glob expansion), so patch-aa is applied before patch-ab etc.

The patch-* files should be in "diff -bu" format, and apply without a fuzz
to avoid problems (to force patches to apply with fuzz you can set
PATCH_FUZZ_FACTOR=-F2).  Furthermore, do not put changes for more than one
file into a single patch-file, as this will make future modifications more
difficult.

Similar, a file should be patched at most once, not several times by
several different patches. If a file needs several patches, they should
be combined into one file.

One important thing to mention is to pay attention that no RCS IDs
get stored in the patch files, as these will cause problems when
later checked into the NetBSD CVS tree. To avoid this, use either
the "-U 2" or "-U 1" option to diff, or let the 'pkgdiff' command
from pkgsrc/pkgtools/pkgdiff help you.

If you don't want to worry about the problems in the last two paragraphs
yourself, use pkgdiff from the pkgsrc/pkgtools/pkgdiff package, which takes
care of any RCS Ids by itself.

For even more automation, we recommend using mkpatches from the same
package to make a whole set of patches. You just have to backup files
before you edit them to "filename.orig", e.g. with "cp -p filename
filename.orig" or, easier, by using pkgvi from the same package. If you
upgrade a package this way, you can easily compare the new set of patches
with the previously existing one with patchdiff.

When you have finished a package, remember to generate the checksums
for the patch files by using the "make makepatchsum" command, see
section 4.2.

Patch files that are distributed by the author or other maintainers can be
listed in $PATCHFILES.

If it is desired to store any patches that should not be committed into
pkgsrc, they can be kept outside the pkgsrc tree in the $LOCALPATCHES
directory. The directory tree there is expected to have the same
"category/package" structure as pkgsrc, and patches are expected to be
stored inside these dirs (also known as $LOCALPATCHES/$PKGPATH). For
example if you want to keep a private patch for pkgsrc/graphics/png, keep
it in $LOCALPATCHES/graphics/png/mypatch. All files in the named directory
are expected to be patch files, and they are applied after the "normal"
pkgsrc patches are applied.


 4.4 Other mandatory files
 =========================

 * DESCR:
   A multi-line description of the piece of software.  This should include
   any credits where they are due.  Please bear in mind that others do not
   share your sense of humour (or spelling idiosyncrasies), and that others
   will read everything that you write here.

 * PLIST:
   This file governs the files that are installed on your system: all the
   binaries, manual pages, etc. There are other directives which may be
   entered in this file, to control the creation and deletion of
   directories, and the location of inserted files.


 4.5 Optional files
 ==================

 * INSTALL:
   Shell script invoked twice during pkg_add. First time after package
   extraction and before files are moved in place, the second time after
   the files to install are moved in place. This can be used to do any
   custom procedures not possible with @@exec commands in PLIST. See
   pkg_add(1) and pkg_create(1) for more information.

 * DEINSTALL:
   This script is executed before and after any files are removed.  It is
   this script's responsibility to clean up any additional messy details
   around the package's installation, since all pkg_delete knows is how to
   delete the files created in the original distribution. See pkg_delete(1)
   and pkg_create(1) for more information.

 * MESSAGE:
   Display this file after installation of the package.
   Useful for things like legal notices on almost-free software, etc.
   Please note that you can modify variables in it easily by using
   MESSAGE_SUBST in the package's Makefile:
  
	MESSAGE_SUBST+=  SOMEVAR="somevalue"
	
   replaces
  
	${SOMEVAR}
	
   in MESSAGE with "somevalue" before displaying the message.


 4.6 work/*
 ==========

When you type "make" the distribution files are unpacked into this
directory.  It can be removed by typing

	# make clean

at the shell prompt. Also, this directory is used to keep various
timestamp files.


 4.7 files/*
 ===========

If you have any files that you wish to be placed in the package prior
to configuration or building, you could place these files here and use
a ${CP} command in the pre-configure target to achieve this.
Alternatively, you could simply diff the file against /dev/null and
use the patch mechanism to manage the creation of this file.


 5 PLIST* issues
 ===============

This section addresses some special issues that one needs to pay attention
to when dealing with the PLIST file (or files, see below!).


 5.1 Miscellaneous
 =================

 * NetBSD RCS Id:
   Be sure to add a RCS ID line as the first thing in any PLIST file you
   write:

	@@comment <$>NetBSD<$>

 * ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}:
   Some packages like emacs and perl embed information about which
   architecture they were built on into the pathnames where they install
   their file. To handle this case, PLIST will be preprocessed before
   actually used, and the symbol "${MACHINE_ARCH}" will be replaced by
   what "uname -p" gives. The same is done if the string ${MACHINE_GNU_ARCH}
   is embedded in PLIST somewhere - use this on packages that have GNU
   autoconf created configure scripts.

   Legacy note: There used to be a symbol "<$ARCH>" that was replaced by
   the output of "uname -m", but that's no longer supported and has been
   removed.

 * ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}:
   Some packages want to embed the OS name and version into some paths.
   To do this, use these variables in the PLIST:

      * ${OPSYS} - output of "uname -s"
      * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
      * ${OS_VERSION} - "uname -r"

 * ${PKGLOCALEDIR}:
   Packages that install locale files should list them in the PLIST as
   "${PKGLOCALEDIR}/locale/de/LC_MESSAGES/..." instead of
   "share/locale/de/LC_MESSAGES/...".  This properly handles the fact that
   different OSes expect locale files to be either in "share" or "lib" by
   default.

 * Manpage-compression:
   Manpages should be installed in compressed form if MANZ is set (in
   bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST
   file, the suffix ".gz" is appended/removed automatically for manpages
   according to MANZ and MANCOMPRESSED being set or not, see above for
   details. This modification of the PLIST file is done on a copy of it,
   not PLIST itself.

 * Platform specific and differing PLISTs:
   Some packages decide to install a different set of files based on
   the operating system being used. These differences can be
   automatically handled by using the following files:

        * PLIST.common
        * PLIST.${OPSYS}
        * PLIST.common_end

   If PLIST.${OPSYS} exists, these files are used instead of PLIST. This
   allows packages which behave in this way to be handled gracefully.
   Manually overriding PLIST_SRC for other more exotic uses is also
   possible.

 * Semi-automatic PLIST generation:
   You can use the "make print-PLIST" command to output a PLIST that matches
   any new files since the package was extracted. See below for more
   information on this target.


 5.2 ${PLIST_SRC}
 ================

To use one or more files as source for the PLIST used in generating the
binary package, set the variable PLIST_SRC to the names of that file(s).
The files are later concatenated using cat(1), and order of things is
important.

 5.3 ${PLIST_SUBST}
 ==================

Similar to MESSAGE_SUBST (see above), you can add variables and their
expansions to this variable in the following way:

	   PLIST_SUBST+=    SOMEVAR="somevalue"

which replaces all occurrences of ${SOMEVAR} in the PLIST with "somevalue".
For the values which are replaced by default, please look in bsd.pkg.mk
(and search for PLIST_SUBST).

 5.4 Perl5 modules
 =================

Makefile of packages providing perl5 modules should include the
makefile fragment lang/perl5/module.mk.  It provides a do-configure
target for the standard perl configuration for such modules as well
as various hooks to tune this configuration.  See comments in this
file for details.

Perl5 modules will install into different places depending on the version
of perl used during the build process.  To address this, the NetBSD
packages system will append lines to the PLIST corresponding to the files
listed in the installed .packlist file generated by most perl5 modules.
This is invoked by defining PERL5_PACKLIST to a space-separated list of
paths to packlist files:

	PERL5_PACKLIST=	${PERL5_SITEARCH}/auto/Pg/.packlist

The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent
the three locations in which perl5 modules may be installed, and may be
used by perl5 packages that don't have a packlist.  These three variables
are also substituted for in the PLIST.


 6 Notes on fixes for packages
 =============================

 6.1 CPP defines
 ===============

To port an application to NetBSD, it's usually necessary for the compiler
to be able to judge the system on which it's compiling, and we use
definitions so that the C pre-processor can do this.

To test whether you are working on a 4.4 BSD-derived system, you should use
the BSD definition, which is defined in <sys/param.h> on said systems.

        #include <sys/param.h>

and then you can surround the BSD-specific parts of your port using the
conditional:

	#if (defined(BSD) && BSD >= 199306)
	...
	#endif

Please use the __NetBSD__ definition sparingly - it should only apply to
features of NetBSD that are not present in other 4.4-lite derived BSDs.

 6.2 Shared libraries - libtool
 ==============================

Pkgsrc supports many different machines, with different object formats
like a.out and ELF, and varying abilities to do shared library and
dynamic loading at all. To accompany this, varying commands and options
have to be passed to the compiler, linker etc. to get the Right Thing,
which can be pretty annoying especially if you don't have all the
machines at your hand to test things.  The "libtool" pkg can help
here, as it just "knows" how to build both static and dynamic
libraries from a set of source files, thus being platform
independent.

Here's how to use libtool in a pkg in seven simple steps:

1. Add USE_LIBTOOL= yes to the package Makefile.

2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of
   ${CC}.  You could even add it to the definition of CC, if only
   libraries are being built in a given Makefile.  This one command will
   build both PIC and non-PIC library objects, so you need not have
   separate shared and non-shared library rules.

3. For the linking of the library, remove any "ar", "ranlib", and "ld
   -Bshareable" commands, and use instead:

	${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info CURRENT:REVISION:AGE

   Note that the library is changed to have a .la extension, and the
   objects are changed to have a .lo extension.  Change OBJS as necessary.
   This automatically creates all of the .a, .so.major.minor, and ELF
   symlinks (if necessary) in the build directory. Be sure to include
   the -version-info especially when major and minor are zero, as libtool
   will otherwise strip off the shared library version.

   PLIST gets all of the .a, .la and so, .so.major and .so.major.minor
   entries.

   From the libtool manual:

	libtool library versions are described by three integers:

	CURRENT
	     The most recent interface number that this library implements.

	REVISION
	     The implementation number of the CURRENT interface.

	AGE
	     The difference between the newest and oldest interfaces that this
	     library implements.  In other words, the library implements all the
	     interface numbers in the range from number `CURRENT - AGE' to
	     `CURRENT'.

	If two libraries have identical CURRENT and AGE numbers, then the
	dynamic linker chooses the library with the greater REVISION
	number.

   The "-release" option will produce different results for a.out and ELF
   (excluding symlinks) in only one case. An ELF library of the form
   libfoo-release.so.x.y will have a symlink of libfoo.so.x.y on an a.out
   platform. This is handled automatically.

   The -rpath argument is the install directory of the library being built.

   PLIST should include all of the .a, .la and so, .so.major and
   .so.major.minor entries.

4. When linking shared object (.so) files, i.e. files that are loaded via
   dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
   them getting version tacked on.

   PLIST gets the foo.so entry.

5. When linking programs that depend on these libraries _before_ they are
   installed, preface the cc or ld line with "${LIBTOOL} --mode=link", and
   it will find the correct libraries (static or shared), but please be
   aware that libtool will not allow you to specify a relative path in -L
   (such as -L../somelib), because it expects you to change that argument
   to be the .la file.  For example:

	${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib

   should be changed to:

	${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la

   and it will DTRT with the libraries.

6. When installing libraries, preface the install or cp command with
   "${LIBTOOL} --mode=install", and change the library name to .la.  For
   example:

	${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib

   This will install the static .a, shared library, any needed symlinks,
   and run "ldconfig."

7. In your PLIST, include all of the .a, .la, and so, .so.CURRENT and
   .so.CURRENT.REVISION files (this is a change from the previous
   behaviour).


 6.3 Using libtool on GNU packages that already support libtool
 ==============================================================

Add USE_LIBTOOL=yes to the package Makefile.  This will override the
package's own libtool in most cases.  For older libtool using packages,
libtool is made by ltconfig script during the do-configure step; you can
check the libtool script location by doing "make configure; find work*/
-name libtool".

LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
override.  By default, it is set to "libtool */libtool */*/libtool".  If
this does not match the location of the package's libtool script(s), set
it as appropriate.

If you do not need *.a static libraries built and installed, then use
SHLIBTOOL_OVERRIDE instead.

If your package makes use of the platform independent library for loading
dynamic shared objects, that comes with libtool (libltdl), you should
include the libtool buildlink3.mk (and set USE_BUILDLINK3 to "yes").

Some packages use libtool incorrectly so that the package may not work or
build in some circumstances. Some common errors are

 * The inclusion of a shared object (-module) as a dependent library in an
   executable or library. This in itself isn't a problem if one of two things
   has been done.

   1. The shared object is named correctly, i.e. libfoo.la and not foo.la

   2. The -dlopen option is used when linking an executable.

 * The use of libltdl without the correct calls to initialisation routines.
   The function lt_dlinit() should be called and the macro
   LTDL_SET_PRELOADED_SYMBOLS included in executables.


 6.4 GNU Autoconf/Automake
 =========================

If a package needs GNU autoconf or automake to be executed to regenerate
the configure script and Makefile.in makefile templates, then they should
be executed in a pre-configure target. Two makefile fragments are provided
in pkgsrc/mk/autoconf.mk and pkgsrc/mk/automake.mk to help dealing with
these tools. See comments in these files for details.

For packages that need only autoconf:

	AUTOCONF_REQD=	2.50	# if default version is not good enough
	...

	pre-configure:
		cd ${WRKSRC}; ${AUTOCONF}

	...
	.include "../../mk/autoconf.mk"

and for packages that need automake and autoconf:

	AUTOMAKE_REQD=	1.7.1	# if default version is not good enough
	...

	pre-configure:
		cd ${WRKSRC};						\
		${ACLOCAL};						\
		${AUTOHEADER};						\
		${AUTOMAKE} -a --foreign -i;				\
		${AUTOCONF}

	...
	.include "../mk/automake.mk"

Packages which use GNU Automake will almost certainly require GNU Make, but
that's automatically provided for you in "mk/automake.mk".

There are times when the configure process makes additional changes to the
generated files, which then causes the build process to try to re-execute
the automake sequence.  This is prevented by touching various files in
the configure stage. If this causes problems with your package you can set
AUTOMAKE_OVERRIDE to NO in the package Makefile.


 6.5 Package configuration files
 ===============================

Packages should be taught to look for their configuration files in
${PKG_SYSCONFDIR}, which is passed through to the configure and build
processes.  PKG_SYSCONFDIR may be customized in various ways by setting
other make variables:

* PKG_SYSCONFBASE is the main config directory under which all package
  configuration files are to be found.  This defaults to ${PREFIX}/etc, but
  may be overridden in /etc/mk.conf.

* PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which the
  configuration files for a particular package may be found, e.g. the
  Apache configuration files may all be found under the "httpd" subdirectory
  of ${PKG_SYSCONFBASE}.  This is meant to be set in a package Makefile.

* By default PKG_SYSCONFDIR=${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}, but
  the default may be overridden by setting PKG_SYSCONFDIR.${PKG_SYSCONFVAR}
  for a particular package, where PKG_SYSCONFVAR defaults to ${PKGBASE}.
  This is not meant to be set by a package Makefile, but is reserved for
  users who wish to override the PKG_SYSCONFDIR setting for a particular
  package with a special location.

The only variables that users should customize are PKG_SYSCONFBASE and
PKG_SYSCONFDIR.${PKG_SYSCONFVAR}.  Users will typically want to set
PKG_SYSCONFBASE to /etc, or to accept the default location of ${PREFIX}/etc.


 6.6 User Interaction
 ====================

Occasionally, packages require interaction from the user, and this can be
in a number of ways:

+ help in fetching the distfiles
+ help to configure the package before it is built
+ help during the build process
+ help during the installation of a package

The INTERACTIVE_STAGE definition is provided, to notify the pkgsrc mechanism
of an interactive stage which will be needed, and this should be set in the
package's Makefile. e.g.

INTERACTIVE_STAGE= build

Multiple interactive stages can be specified:

INTERACTIVE_STAGE= configure install


 6.7 Feedback to the author
 ==========================

If you have found any bugs in the package you make available, if you had to
do special steps to make it run under NetBSD or if you enhanced the software
in various other ways, be sure to report these changes back to the original
author of the program! With that kind of support, the next release of the
program can incorporate these fixes, and people not using the NetBSD packages
system can win from your efforts.

Support the idea of free software!


 7 The build process
 ===================

The basic steps for building a program are always the same.  First the
program's source (distfile) must be brought to the local system and
then extracted.  After any patches to compile properly on NetBSD are
applied, the software can be configured, then built (usually by
compiling), and finally the generated binaries etc.  can be put into
place on the system.  These are exactly the steps performed by the
NetBSD package system, which is implemented as a series of targets in
a central Makefile, pkgsrc/mk/bsd.pkg.mk.


 7.1 Program location
 ====================

Before outlining the process performed by the NetBSD package system in the
next section, here's a brief discussion on where programs are installed,
and which variables influence this.

The automatic variable PREFIX indicates where all files of the final
program shall be installed.  It is usually set to $LOCALBASE (/usr/pkg),
or $CROSSBASE for pkgs in the "cross" category, though its value becomes
that of $X11BASE if USE_IMAKE or USE_X11BASE is set.  The value ${PREFIX}
needs to be put into the various places in the program's source where paths
to these files are encoded; see sections 4.3 and 6.2 for details on this.

When choosing which of these variables to use, follow the following rules:

 * ${PREFIX} always points to the location where the current pkg will be
   installed.  When referring to a pkg's own installation path, use ${PREFIX}.

 * ${LOCALBASE} is where all non-X11 pkgs are installed.  If you need to
   construct a -I or -L argument to the compiler to find includes and
   libraries installed by another non-X11 pkg, use ${LOCALBASE}.

 * ${X11BASE} is where the actual X11 distribution (from xsrc etc.) is installed.
   When looking for _standard_ X11 includes (not those installed by a pkg), use
   ${X11BASE}.

 * X11 based pkgs are special in that they may be installed in either
   X11BASE or LOCALBASE.

   Usually, X11 packages should be installed under LOCALBASE whenever
   possible.  Note that you will need to set USE_X11 in them to request
   the presence of X11 and to get the right compilation flags.
   
   Even though, there are some packages that cannot be installed under
   LOCALBASE: those that come with app-defaults files. These packages are
   special and they must be placed under X11BASE. To accomplish this,
   set either USE_X11BASE or USE_IMAKE in your package.

   Some notes: USE_X11 and USE_X11BASE are mutually exclusive. If you need
   to find includes or libraries installed by a pkg that has USE_IMAKE or
   USE_X11BASE in its pkg Makefile, you need to use _both_ ${X11BASE} and
   ${LOCALBASE}. To install all X11 packages in LOCALBASE, simply install
   the xpkgwedge package (pkgsrc/pkgtools/xpkgwedge).

 * ${X11PREFIX} should be used to refer to the installed location of an X11
   package. X11PREFIX will be set to ${X11BASE} if xpkgwedge is not installed,
   and to ${LOCALBASE} if xpkgwedge is installed.

 * If xpkgwedge is installed, it is possible to have some packages installed in
   X11BASE and some in LOCALBASE. To determine the prefix of an installed
   package, the EVAL_PREFIX definition can be used. It takes pairs in the
   format DIRNAME=<package>, and the make(1) variable DIRNAME will be set
   to the prefix of the installed package <package>, or ${X11PREFIX} if the
   package is not installed.

   This is best illustrated by example.

   The following lines are taken from pkgsrc/wm/scwm/Makefile:

	EVAL_PREFIX+=	GTKDIR=gtk+
	CONFIGURE_ARGS+=	--with-guile-prefix=${LOCALBASE}	\
				--with-gtk-prefix="${GTKDIR}"		\
				--enable-multibyte

   Specific defaults can be defined for the packages evaluated using
   EVAL_PREFIX, by using a definition of the form:

	GTKDIR_DEFAULT= ${LOCALBASE}

   where "GTKDIR" corresponds to the first definition in the EVAL_PREFIX pair.

 * Within ${PREFIX}, packages should install files according to hier(7), with
   the exception that manual pages go into ${PREFIX}/man, not
   ${PREFIX}/share/man.

 7.2 Main targets
 ================

The main targets used during the build process defined in bsd.pkg.mk are:

 * fetch:
   This will check if the file(s) given in the variables DISTFILES and
   PATCHFILES (as defined in the package's Makefile) are present on the
   local system in /usr/pkgsrc/distfiles. If they are not present, an
   attempt will be made to fetch them using commands of the form

   ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}

   where ${site} varies through several possibilities in turn: first,
   ${MASTER_SITE_OVERRIDE} is tried, then the sites specified in either
   ${SITES_file}, if defined, else ${MASTER_SITES} or ${PATCH_SITES}, as
   applies, then finally the value of ${MASTER_SITE_BACKUP}. The order of
   all except the first can be optionally sorted by the user, via setting
   either ${MASTER_SORT_AWK} or ${MASTER_SORT_REGEX}.

 * checksum:
   After the distfile(s) are fetched, their checksum is generated and
   compared with the checksums stored in the distinfo file. If the
   checksums don't match, the build is aborted. This is to ensure the same
   distfile is used for building, and that the distfile wasn't changed,
   e.g. by some malign force, deliberately changed distfiles on the master
   distribution site or network lossage.

 * extract:
   When the distfiles are present on the local system, they need to be
   extracted, as they are usually in the form of some compressed archive
   format, most commonly .tar.gz. If only some of the distfiles need to be
   uncompressed, the files to be uncompressed should be put into
   EXTRACT_ONLY. If the distfiles are not in .tar.gz format, they can be
   extracted by setting EXTRACT_CMD.

 * patch:
   After extraction, all the patches named by the PATCHFILES, those present
   in the patches subdirectory of the package as well as in
   $LOCALPATCHES/$PKGPATH (e.g. /usr/local/patches/graphics/png) are
   applied. Patchfiles ending in .Z or .gz are uncompressed before they are
   applied, files ending in .orig or .rej are ignored. Any special options
   to patch(1) can be handed in PATCH_DIST_ARGS. See section 4.3 for more
   details.
  
   By default patch is given special args to make it fail if the
   patches apply with some lines of fuzz. Please fix (regen) the patches
   so that they apply cleanly. The rationale behind this is that
   patches that don't apply cleanly may end up being applied in the wrong
   place, and cause severe harm there.

 * configure:
   Most pieces of software need information on the header files,
   system calls, and library routines which are available in NetBSD.
   This is the process known as configuration, and is usually
   automated.  In most cases, a script is supplied with the source,
   and its invocation results in generation of header files,
   Makefiles, etc.

   If the program's distfile contains its own configure script, this can
   be invoked by setting HAS_CONFIGURE. If the configure script is a GNU
   autoconf script, GNU_CONFIGURE should be specified instead. In either
   case, any arguments to the configure script can be specified in the
   CONFIGURE_ARGS variable, and the configure script's name can be set in
   CONFIGURE_SCRIPT if it differs from the default "configure".

   If the program uses an Imakefile for configuration, the appropriate
   steps can be invoked by setting USE_IMAKE to YES. (If you only want the
   package installed in $X11PREFIX but xmkmf not being run, set USE_X11BASE
   instead!)

 * build:
   Once configuration has taken place, the software can be built on
   NetBSD by invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as
   the target to build.  The default MAKE_PROGRAM is "gmake" if
   USE_GNU_TOOLS 'make' is set, "make" otherwise.  MAKEFILE is set to
   "Makefile" by default, and ALL_TARGET defaults to "all".  Any of
   these variables can be set to change the default build process.

 * install:
   Once the build stage has completed, the final step is to install
   the software in public directories, for users.  As in the
   build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with
   the $INSTALL_TARGET instead, the latter defaulting to "install"
   (plus "install.man", if USE_IMAKE is set).

If no target is specified, the default is "build". If a subsequent stage
is requested, all prior stages are made: e.g. "make build" will also
perform the equivalent of:

	make fetch
	make checksum
	make extract
	make patch
	make configure
	make build


 7.3 Other helpful targets
 =========================

 * pre/post-*
   For any of the main targets described in the previous section, two
   auxiliary targets exist with "pre-" and "post-" used as a prefix
   for the main target's name.  These targets are invoked before and
   after the main target is called, allowing extra configuration or
   installation steps, for example, which program's configure script
   or install target omitted.

 * do-*:
   Should one of the main targets do the wrong thing, and should there
   be no variable to fix this, you can redefine it with the do-*
   target.  (Note that redefining the target itself instead of the
   do-* target is a bad idea, as the pre-* and post-* targets won't be
   called anymore, etc.) You will not usually need to do this.

 * reinstall:
   If you did a "make install" and you noticed some file was not installed
   properly, you can repeat the installation with this target, which will
   ignore the "already installed" flag.

 * deinstall:
   This target does a pkg_delete(1) in the current directory,
   effectively de-installing the package. The following variables can
   be used either on the command line or in /etc/mk.conf to tune the
   behaviour:

    - PKG_VERBOSE:
      Add a "-v" to the pkg_delete(1) command.
     
    - DEINSTALLDEPENDS:
      Remove all packages that require (depend on) the given package.
      This can be used to remove any packages that may have been pulled in
      by a given package, e.g. if "make deinstall DEINSTALLDEPENDS=1" is
      done in pkgsrc/x11/kde, this is likely to remove whole KDE. Works by
      adding a "-R" to the pkg_delete command line.

 * update:
   This target causes the current package to be updated to the latest
   version.  The package and all depending packages first get de-installed,
   then current versions of the corresponding packages get compiled and
   installed.  This is similar to manually noting which packages are
   currently installed, then performing a series of "make deinstall" and
   "make install" (or whatever UPDATE_TARGET is set to) for these packages.

   You can use the "update" target to resume package updating in case a
   previous "make update" was interrupted for some reason.  However, in
   this case, make sure you don't call "make clean" or otherwise remove
   the list of dependent packages in ${WRKDIR}.  Otherwise you lose the
   ability to automatically update the current package along with the
   dependent packages you have installed.

   Resuming an interrupted "make update" will only work as long as the
   package tree remains unchanged.  If the source code for one of the
   packages to be updated has been changed, resuming "make update" will
   most certainly fail!

   The following variables can be used either on the command line or in
   /etc/mk.conf to alter the behaviour of "make update":

    - UPDATE_TARGET:
      Install target to recursively use for the updated package and the
      dependent packages.  Defaults to ${DEPENDS_TARGET} if set, "install"
      otherwise for "make update".
      E.g. "make update UPDATE_TARGET=package"

    - NOCLEAN:
      Don't clean up after updating.  Useful if you want to leave the
      work sources of the updated packages around for inspection or
      other purposes.  Be sure you eventually clean up the source
      tree (see the "clean-update" target below) or you may run into
      troubles with old source code still lying around on your next
      "make" or "make update".

    - REINSTALL:
      Deinstall each package before installing (making ${DEPENDS_TARGET}).
      This may be necessary if the "clean-update" target (see below) was
      called after interrupting a running "make update".

    - DEPENDS_TARGET:
      Allows you to disable recursion and hardcode the target for
      packages.  The default is "update" for the update target,
      facilitating a recursive update of prerequisite packages.
      Only set DEPENDS_TARGET if you want to disable recursive updates.
      Use "UPDATE_TARGET" instead to just set a specific target for
      each package to be installed during "make update" (see above).

 * clean-update:
   Clean the source tree for all packages that would get updated if
   "make update" was called from the current directory.  This target
   should not be used if the current package (or any of its depending
   packages) have already been de-installed (e.g., after calling "make
   update") or you may lose some packages you intended to update.
   As a rule of thumb: only use this target _before_ the first time
   you call "make update" and only if you have a dirty package tree
   (e.g., if you used NOCLEAN).

   If you unsure about whether your tree is clean you can either perform
   a "make clean" at the top of the tree, or use the following sequence
   of commands from the directory of the package you want to update
   (*before* running "make update" for the first time, otherwise you lose
   all the packages you wanted to update!):

      make clean-update
      make clean CLEANDEPENDS=YES
      make update

   The following variables can be used either on the command line or in
   /etc/mk.conf to alter the behaviour of "make clean-update":

    - CLEAR_DIRLIST:
      After "make clean", do not reconstruct the list of directories to
      update for this package.  Only use this if "make update" successfully
      installed all packages you wanted to update.  Normally, this is done
      automatically on "make update", but may have been suppressed by the
      NOCLEAN variable (see above).

 * info:
   This target invokes "pkg_info" for the current package. You can use this
   e.g. to check which version of a package is installed.

 * readme:
   This target generates a README.html file, which can be viewed using a
   browser such as navigator (pkgsrc/www/navigator) or lynx
   (pkgsrc/www/lynx). The generated files contain references to any
   packages which are in the ${PACKAGES} directory on the local host. The
   generated files can be made to refer to URLs based on FTP_PKG_URL_HOST
   and FTP_PKG_URL_DIR. For example, if I wanted to generate README.html
   files which pointed to binary packages on the local machine, in the
   directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
   FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
   subdirectories will be searched for all the binary packages.

 * readme-all:
   Use this target to create a file README-all.html which contains a
   list of all packages currently available in the NetBSD Packages
   Collection, together with the category they belong to and a short
   description. This file is compiled from the pkgsrc/*/README.html
   files, so be sure to run this _after_ a "make readme".

 * cdrom-readme:
   This is very much the same as the readme: target (see above), but is
   to be used when generating a pkgsrc tree to be written to a CD-ROM.
   This target also produces README.html files, and can be made to refer
   to URLs based on CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.

 * show-distfiles:
   This target shows which distfiles and patchfiles are needed to build
   the package. (DISTFILES and PATCHFILES, but not patches/*)

 * show-downlevel:
   This target shows nothing if the package is not installed. If a version
   of this package is installed, but is not the version provided in this
   version of pkgsrc, then a warning message is displayed. This target can
   be used to show which of your installed packages are downlevel, and so
   the old versions can be deleted, and the current ones added.

 * show-pkgsrc-dir:
   This target shows the directory in the pkgsrc hierarchy from which the
   package can be built and installed. This may not be the same directory
   as the one from which the package was installed. This target is intended
   to be used by people who may wish to upgrade many packages on a single
   host, and can be invoked from the top-level pkgsrc Makefile by using the
   target "show-host-specific-pkgs"

 * show-installed-depends:
   This target shows which installed packages match the current package's
   DEPENDS. Useful if out of date DEPENDS are causing build problems.

 * check-shlibs:
   After a package is installed, check all its binaries and (on ELF
   platforms) shared libraries to see if they find the shared libs they need.
   Run by default if PKG_DEVELOPER is set in /etc/mk.conf.

 * print-PLIST:
   After a 'make install' from a new or upgraded pkg, this prints out an
   attempt to generate a new PLIST from a 'find -newer work/.extract_done'.
   (Note that it will not descend into different filesystems.)
   An attempt is made to care for shared libs etc., but it is STRONGLY 
   recommended to review the result before putting it into PLIST. On
   upgrades, it's useful to diff the output of this command against an already
   existing PLIST file.

   If the package installs files via tar(1) or other methods that don't update
   file access times, be sure to add these files manually to your PLIST,
   as 'find -newer' won't catch them!

 * bulk-package:
   Used to do bulk builds. If an appropriate binary package already exists,
   no action is taken. If not, this target will compile, install and
   package it (and its dependencies, if PKG_DEPENDS is set properly; see
   section 3.2.1). After creating the binary package, the sources, the
   just-installed package and its dependencies are removed to preserve
   disk space.

 * bulk-install:
   Used during bulk-installs to install required packages. If an
   appropriate binary package is available, it will be installed via
   pkg_add. If not, "make bulk-package" will be executed, but the installed
   binary not be removed. A binary package is "appropriate" to be installed
   via pkg_add if:

    - None of the package's files (Makefile, ...) were modified since it
      was built
    - None of the package's required (binary) packages were modified since
      it was built


 8 buildlink3 methodology
 ========================

"buildlink3" is a pkgsrc framework that controls what headers and libraries
are seen by a package's configure and build processes.  This is implemented
in a two step process:

 (1) Symlink headers and libraries for dependencies into ${BUILDLINK_DIR},
     which by default is a subdirectory of ${WRKDIR};

 (2) Create wrapper scripts that are used in place of the normal compiler
     tools that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib
     into references into ${BUILDLINK_DIR}.  The wrapper scripts also make
     native compiler on some operating systems look like GCC, so that
     packages that expect GCC won't require modifications to build with
     those native compilers.

This normalizes the environment in which a package is built so that the
package may be built consistently despite what may other software may
installed.  Please note that the normal system header and library paths,
e.g. /usr/include, /usr/lib, etc., are always searched -- buildlink3 is
designed to insulate the package build from non-system-supplied software.


 8.1 Converting packages to use buildlink3
 =========================================

The process of "bl3ifying" a package, or converting a package to use
the buildlink3 framework, is surprisingly easy.  The things to keep in
mind are:

  (1) Set USE_BUILDLINK3 to "yes".

  (2) Ensure that the build always calls the wrapper scripts instead of
      the actual toolchain.  Some packages are tricky, and the only way to
      know for sure is the check ${WRKDIR}/.work.log to see if the
      wrappers are being invoked.

  (3) Don't override PREFIX from within the package Makefile, e.g.
      Java VMs, standalone shells, etc., because the code to symlink
      files into ${BUILDLINK_DIR} looks for files relative to
      "pkg_info -qp <pkgname>".

  (4) Remember that _only_ the buildlink3.mk files that you list in a
      package's Makefile are added as dependencies for that package.

If a dependency on a particular package is required for its libraries and
headers, then we replace:

	DEPENDS+=	foo>=1.1.0:../../category/foo
with
	.include "../../category/foo/buildlink3.mk"

There are several buildlink3.mk files in pkgsrc/mk that handle special
package issues:

 * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
   implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.

 * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between
   adding a dependency on Heimdal or MIT-krb5 for packages that require
   a Kerberos 5 implementation.

 * motif.buildlink3.mk checks for a system-provided Motif installation
   or adds a dependency on x11/lesstif or x11/openmotif;

 * ossaudio.buildlink3.mk defines several variables that may be used by
   packages that use the Open Sound System (OSS) API;

 * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for
   native pthreads or adds a dependency on devel/pth as needed;

 * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular
   Athena widgets library.

The comments in those *.buildlink3.mk files provide a more complete
description of how to use them properly.


 8.2 Writing buildlink3.mk files
 ===============================

A package's buildlink3.mk file is included by Makefiles to indicate the
need to compile and link against header files and libraries provided by
the package.  A buildlink3.mk file should always provide enough information
to add the correct type of dependency relationship and include any other
buildlink3.mk files that it needs to find headers and libraries that it
needs in turn.

To generate an initial buildlink3.mk file for further editing, Rene Hexel's
pkgtools/createbuildlink package is highly recommended.  For most packages,
the following command will generate a good starting point for buildlink3.mk
files:

    cd pkgsrc/category/pkgdir; createbuildlink -3 > buildlink3.mk


 8.3.1 Anatomy of a buildlink3.mk file
 =====================================

The following real-life example buildlink3.mk is taken from graphics/tiff:

------------8<------------8<------------8<------------8<------------
# <$>NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp <$>

BUILDLINK_DEPTH:=	${BUILDLINK_DEPTH}+
TIFF_BUILDLINK3_MK:=	${TIFF_BUILDLINK3_MK}+

.if !empty(BUILDLINK_DEPTH:M+)
BUILDLINK_DEPENDS+=	tiff
.endif

BUILDLINK_PACKAGES:=	${BUILDLINK_PACKAGES:Ntiff}
BUILDLINK_PACKAGES+=	tiff

.if !empty(TIFF_BUILDLINK3_MK:M+)
BUILDLINK_DEPENDS.tiff+=	tiff>=3.6.1
BUILDLINK_PKGSRCDIR.tiff?=	../../graphics/tiff
.endif	# TIFF_BUILDLINK3_MK

.include "../../devel/zlib/buildlink3.mk"
.include "../../graphics/jpeg/buildlink3.mk"

BUILDLINK_DEPTH:=	${BUILDLINK_DEPTH:S/+$//}
------------8<------------8<------------8<------------8<------------

The header and footer manipulate BUILDLINK_DEPTH, which is common across
all buildlink3.mk files and is used to track at what depth we are including
buildlink3.mk files.

The first section controls if the dependency on <pkg> is added.
BUILDLINK_DEPENDS is the global list of packages for which dependencies
are added by buildlink3.

The second section advises pkgsrc that the buildlink3.mk file for <pkg>
has been included at some point.  BUILDLINK_PACKAGES is the global list
of packages for which buildlink3.mk files have been included.  It must
_always_ be appended to within a buildlink3.mk file.

The third section is protected from multiple inclusion and controls how
the dependency on <pkg> is added.  Several important variables are set in
the section:

  (1) BUILDLINK_DEPENDS.<pkg> is the actual dependency recorded in the
      installed package; this should always be set using += to ensure that
      we're appending to any pre-existing list of values.  This variable
      should be set to the first version of the package that had the last
      change in the major number of a shared library or that had a major
      API change.

  (2) BUILDLINK_PKGSRCDIR.<pkg> is the location of the <pkg> pkgsrc
      directory;

  (3) BUILDLINK_DEPMETHOD.<pkg> (not shown above) controls whether we use
      BUILD_DEPENDS or DEPENDS to add the dependency on <pkg>.  The build
      dependency is selected by setting BUILDLINK_DEPMETHOD.<pkg> to
      "build".  By default, the full dependency is used.

  (4) BUILDLINK_INCDIRS.<pkg> and BUILDLINK_LIBDIRS.<pkg> (not shown above)
      are lists of subdirectories of ${BUILDLINK_PREFIX.<pkg>} to add the
      header and library search paths.  These default to "include" and
      "lib" respectively.

  (5) BUILDLINK_CPPFLAGS.<pkg> (not shown above) is the list of
      preprocessor flags to add to CPPFLAGS, which are passed on to the
      configure and build phases.  The "-I" option should be avoided and
      instead be handled using BUILDLINK_INCDIRS.<pkg> as above.

The following variables are all optionally defined within this second
section (protected against multiple inclusion) and control which package
files are symlinked into ${BUILDLINK_DIR} and how their names are
transformed during the symlinking:

  (6) BUILDLINK_FILES.<pkg> (not shown above) is a shell glob pattern
      relative to ${BUILDLINK_PREFIX.<pkg>} to be symlinked into
      ${BUILDLINK_DIR}, e.g. include/*.h

  (7) BUILDLINK_FILES_CMD.<pkg> (not shown above) is a shell pipeline that
      outputs to stdout a list of files relative to
      ${BUILDLINK_PREFIX.<pkg>}.  The resulting files are to be symlinked
      into ${BUILDLINK_DIR}.  By default, this takes the +CONTENTS of a
      <pkg> and filters it through ${BUILDLINK_CONTENTS_FILTER.<pkg>}.

  (8) BUILDLINK_CONTENTS_FILTER.<pkg> (not shown above) is a filter command
      that filters +CONTENTS input into a list of files relative to
      ${BUILDLINK_PREFIX.<pkg>} on stdout.  By default for overwrite
      packages, BUILDLINK_CONTENTS_FILTER.<pkg> outputs the contents of
      the include and lib directories in the package +CONTENTS, and for
      pkgviews packages, it outputs any libtool archives in lib
      directories.

  (9) BUILDLINK_TRANSFORM.<pkg> (not shown above) is a list of sed
      arguments used to transform the name of the source filename into a
      destination filename, e.g. -e "s|/curses.h|/ncurses.h|g"

The last section includes any buildlink3.mk needed for <pkg>'s library
dependencies.  Including these buildlink3.mk files means that the headers
and libraries for these dependencies are also symlinked into
${BUILDLINK_DIR} whenever the <pkg> buildlink3.mk file is included.


 8.3.2 Updating BUILDLINK_DEPENDS.<pkg> in buildlink3.mk files
 =============================================================

There are two situations that require increasing the dependency listed
in BUILDLINK_DEPENDS.<pkg> after a package update:

  (1) if the sonames (major number of the library version) of any installed
      shared libraries change;

  (2) if the API or interface to the header files change.

In these cases, BUILDLINK_DEPENDS.<pkg> should be adjusted to require at
least the new package version.  In some cases, the packages that depend
on this new version may need their PKGREVISIONs increased and, if they
have buildlink3.mk files, their BUILDLINK_DEPENDS.<pkg> adjusted, too.
This is needed so that binary packages made using it will require the
correct package dependency and not settle for an older one which will not
contain the necessary shared libraries.

Please take careful consideration before adjusting BUILDLINK_DEPENDS.<pkg>
as we don't want to cause unneeded package deletions and rebuilds.  In
many cases, new versions of packages work just fine with older
dependencies.  See section 11 for more information about dependencies on
other packages, including the BUILDLINK_RECOMMENDED and RECOMMENDED
definitions.


 8.4 Writing builtin.mk files
 ============================

Some packages in pkgsrc install headers and libraries that coincide with
headers and libraries present in the base system.  Aside from a
buildlink3.mk file, these packages should also include a builtin.mk file
that includes the necessary checks to decide whether using the built-in
software or the pkgsrc software is appropriate.

The only requirements of a builtin.mk file for <pkg> are:

  (1) It should set USE_BUILTIN.<pkg> to either "yes" or "no" after it
      is included.

  (2) It should *not* override any USE_BUILTIN.<pkg> which is already
      set before the builtin.mk file is included.

  (3) It should be written to allow multiple inclusion.  This is _very_
      important and takes careful attention to Makefile coding.


 8.4.1 Anatomy of a builtin.mk file
 ==================================

The following is the recommended template for builtin.mk files:

-------------8<-------------8<-------------8<-------------8<-------------
.if !defined(IS_BUILTIN.foo)
#
# IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
# genuinely exists in the system or not.
#
IS_BUILTIN.foo?=	no

# BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
# version can be determined.
#
.  if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
BUILTIN_PKG.foo?=	foo-1.0
.  endif
.endif  # IS_BUILTIN.foo

.if !defined(USE_BUILTIN.foo)
USE_BUILTIN.foo?=	${IS_BUILTIN.foo}
.  if defined(BUILTIN_PKG.foo)
.    for _depend_ in ${BUILDLINK_DEPENDS.foo}
.      if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
USE_BUILTIN.foo!=							\
      if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then	\
              ${ECHO} "yes";						\
      else								\
              ${ECHO} "no";						\
      fi
.      endif
.    endfor
.  endif
.endif	# USE_BUILTIN.foo

CHECK_BUILTIN.foo?=	no
.if !empty(CHECK_BUILTIN.foo:M[nN][oO])
#
# Here we place code that depends on whether USE_BUILTIN.foo is set to
# "yes" or "no".
#
.endif  # CHECK_BUILTIN.foo
-------------8<-------------8<-------------8<-------------8<-------------

The first section sets IS_BUILTIN.<pkg> depending on if <pkg> really exists
in the base system.  This should not be a base system software with similar
functionality to <pkg>; it should only be "yes" if the actual package is
included as part of the base system.  This variable is only used internally
within the builtin.mk file.

The second section sets BUILTIN_PKG.<pkg> to the version of <pkg> in the
base system if it exists (if IS_BUILTIN.<pkg> is "yes").  This variable
is only used internally within the builtin.mk file.

The third section sets USE_BUILTIN.<pkg> and is _required_ in all
builtin.mk files.  The code in this section must make the determination
whether the built-in software is adequate to satisfy the dependencies
listed in BUILDLINK_DEPENDS.<pkg>.  This is typically done by comparing
BUILTIN_PKG.<pkg> against each of the dependencies in
BUILDLINK_DEPENDS.<pkg>.  USE_BUILTIN.<pkg> _must_ be set to the correct
value by the end of the builtin.mk file.  Note that USE_BUILTIN.<pkg> may
be "yes" even if IS_BUILTIN.<pkg> is "no" because we may make the
determination that the built-in version of the software is similar enough
to be used as a replacement.

The last section is guarded by CHECK_BUILTIN.<pkg>, and includes code that
uses the value of USE_BUILTIN.<pkg> set in the previous section.  This
typically includes, e.g., adding additional dependency restrictions and
listing additional files to symlink into ${BUILDLINK_DIR} (via
BUILDLINK_FILES.<pkg>).


 8.4.2 Global preferences for native or pkgsrc software
 ======================================================

When building packages, it's possible to choose whether to set a global
preference for using either the built-in (native) version or the pkgsrc
version of software to satisfy a dependency.  This is controlled by setting
PREFER_PKGSRC and PREFER_NATIVE.  These variables take values of either
"yes", "no", or a list of packages.  PREFER_PKGSRC tells pkgsrc to use
the pkgsrc versions of software, while PREFER_NATIVE tells pkgsrc to use
the built-in versions.  Preferences are determined by the most specific
instance of the package in either PREFER_PKGSRC or PREFER_NATIVE.  If a
package is specified in neither or in both variables, then PREFER_PKGSRC
has precedence over PREFER_NATIVE.  For example, to require using pkgsrc
versions of software for all but the most basic bits on a NetBSD system,
you can set:

	PREFER_PKGSRC=	yes
	PREFER_NATIVE=	getopt skey tcp_wrappers

A package _must_ have a builtin.mk file to be listed in PREFER_NATIVE,
otherwise it is simply ignored in that list.


 9 Options handling
 ==================

Many packages have the ability to be built to support different sets
of features.  bsd.options.mk is a pkgsrc framework that provides
generic handling of those options that determine different ways in
which the packages can be built.  It's possible for the user to specify
exactly which sets of options will be built into a package or to allow
a set of global default options apply.


 9.1 Global default options
 ==========================

Global default options are listed in PKG_DEFAULT_OPTIONS, which is a
list of the options that should be built into every package if that
option is supported.  This variable should be set in /etc/mk.conf.


 9.2 Converting packages to use bsd.options.mk
 =============================================

The following example shows how bsd.options.mk should be use in a package
Makefile, or in a file, e.g. options.mk, that is included by the main
package Makefile.

-------------8<-------------8<-------------8<-------------8<-------------
# Global and legacy options
.if defined(WIBBLE_USE_OPENLDAP) && !empty(WIBBLE_USE_OPENLDAP:M[yY][eE][sS])
PKG_DEFAULT_OPTIONS+=	ldap
.endif
.if defined(USE_SASL2) && !empty(USE_SASL2:M[yY][eE][sS])
PKG_DEFAULT_OPTIONS+=	sasl
.endif

PKG_OPTIONS_VAR=	PKG_OPTIONS.wibble
PKG_SUPPORTED_OPTIONS=	ldap sasl
#
# Default options for "wibble" package.
#
.if !defined(PKG_OPTIONS.wibble)
PKG_DEFAULT_OPTIONS+=	sasl
endif
.include "../../mk/bsd.options.mk"

# Package-specific option-handling

###
### LDAP support
###
.if !empty(PKG_OPTIONS:Mldap)
.  include "../../databases/openldap/buildlink3.mk"
CONFIGURE_ARGS+=      --enable-ldap=${BUILDLINK_PREFIX.openldap}
.endif

###
### SASL authentication
###
.if !empty(PKG_OPTIONS:Msasl)
.  include "../../security/cyrus-sasl2/buildlink3.mk"
CONFIGURE_ARGS+=	--enable-sasl=${BUILDLINK_PREFIX.sasl}
.endif
# -------------8<-------------8<-------------8<-------------8<-------------

The first section only exists if you are converting a package that
had its own ad-hoc options handling to use bsd.options.mk.  It converts
global or legacy options variables into an equivalent PKG_OPTIONS.<pkg>
value.  These sections will be removed over time as the old options
are in turn deprecated and removed.

The second section contains the information about which build options
are supported by the package, and any default options settings if
needed.

  (1) PKG_OPTIONS_VAR is a list of the name of the make(1) variables
      that contain the options the user wishes to select.  The
      recommended value is "PKG_OPTIONS.<pkg>" but any package-specific
      value may be used.  This variable should be set in a package
      Makefile.

  (2) PKG_SUPPORTED_OPTIONS is a list of build options supported by
      the package.  This variable should be set in a package Makefile.

  (3) ${PKG_OPTIONS_VAR} (the variables named in PKG_OPTIONS_VAR) are
      variables that list the selected build options and override any
      default options given in PKG_DEFAULT_OPTIONS.  If any of the
      options begin with a '-', then that option is always removed
      from the selected build options, e.g.

	PKG_DEFAULT_OPTIONS=	kerberos ldap sasl
	PKG_OPTIONS_VAR=	WIBBLE_OPTIONS
	WIBBLE_OPTIONS=		${PKG_DEFAULT_OPTIONS} -sasl
	# implies PKG_OPTIONS == "kerberos ldap"

      or

	PKG_OPTIONS_VAR=	WIBBLE_OPTIONS
	WIBBLE_OPTIONS=		kerberos -ldap ldap
	# implies PKG_OPTIONS == "kerberos"

      This variable should be set in /etc/mk.conf.

After the inclusion of bsd.options.mk, the following variables are set:

    * PKG_OPTIONS contains the list of the selected build options,
      properly filtered to remove unsupported and duplicate options.

The remaining sections contain the logic that is specific to each
option.  There should be a check for every option listed in
PKG_SUPPORTED_OPTIONS, and there should be clear documentation on what
turning on the option will do in the comments preceding each section.
The correct way to check for an option is to check whether it is listed
in PKG_OPTIONS.


 10 Debugging
 ============

To check out all the gotchas when building a package, here are the steps
that I do in order to get a package working. Please note this is basically
the same as what was explained in the previous sections, only with some
debugging aids.

 * Make sure PKG_DEVELOPER=1 is in /etc/mk.conf
 * Create a new directory, and run

	# url2pkg http://www.example.com/path/to/distfile.tar.gz

   You'll need to have pkgsrc/pkgtools/url2pkg installed for that.
 * Edit the Makefile as requested.
 * Fill in DESCR
 * ``make configure''
 * Add any dependencies glimpsed from the configure step to the package's
   Makefile.
 * Make the package compile, doing multiple rounds of

	# make
	# pkgvi ${WRKSRC}/some/file/that/does/not/compile
	# mkpatches
	# patchdiff
	# mv ${WRKDIR}/.newpatches/* patches
	# make mps
	# make clean
   [ mkpatches, patchdiff and pkgvi are from pkgsrc/pkgtools/pkgdiff ]

   Doing as non-root user will assure that no files are modified that
   shouldn't, esp. not during the build phase.
 * Look at Makefile, fix if necessary; see section 4.1.
 * Generate a PLIST:

	# make install
	# make print-PLIST > PLIST
	# make deinstall
	# make install
	# make deinstall

   You usually need to be root to do this.
 * Look if there are any files left:

	# make print-PLIST

   If this brings up any files that are missing in PLIST, add them.
 * Now that the PLIST is ok, install the package again and make a binary
   package:
  
	# make reinstall && make package
	
 * Delete the installed package:

	# pkg_delete blub
	
 * Repeat the above find command, which shouldn't find anything now:

	# make print-PLIST

 * Reinstall the binary package:

	# pkg_add ..../blub.tgz
	
 * Play with it. Make sure everything works.
 * Run pkglint from pkgsrc/pkgtools/pkglint, and fix the problems it reports.

	# pkglint

 * Submit (or commit, if you have cvs access); see section 11.


 11 FAQs & features of the package system
 ========================================

 11.1 Packages using GNU autoconf
 ================================

If your package uses GNU autoconf created configure scripts, add the following
to your package's Makefile:

	GNU_CONFIGURE= yes

Note that this appends --prefix=${PREFIX} to CONFIGURE_ARGS, so you don't
have to do that yourself, and this may not be what you want.


 11.2 Other distrib methods than .tar.gz
 =======================================

If your package uses a different distribution method from .tar.gz, take a
look at the package for pkgsrc/editors/sam, which uses a gzipped shell archive
(shar), but the quick solution is to set EXTRACT_SUFX to the name after the
DISTNAME field, and add the following to your package's Makefile:

	EXTRACT_SUFX=		.msg.gz
	EXTRACT_CMD=		zcat -d < ${DOWNLOADED_DISTFILE} | ${SH}


 11.3 Packages not creating their own subdirectory
 =================================================

Your package doesn't create a subdirectory for itself (like GNU software
does, for instance), but extracts itself in the current directory: see
pkgsrc/editors/sam again, but the quick answer is:

	WRKSRC=		${WRKDIR}

Please note that the old

	NO_WRKSUBDIR=   yes

has been deprecated and should not be used.


 11.4 Custom configuration process
 =================================

Your package uses a weird Configure script: See the top package, but the
quick answer is:

	HAS_CONFIGURE=          yes
	CONFIGURE_SCRIPT=       Configure
	CONFIGURE_ARGS+=        netbsd13


 11.5 Packages not building in their DISTNAME directory
 ======================================================

Your package builds in a different directory from its base DISTNAME - see
tcl and tk packages:

	WRKSRC=         ${WRKDIR}/${DISTNAME}/unix


 11.6 How to fetch all distfiles at once
 =======================================

You would like to download all the distfiles in a single batch from work or
university, where you can't run a "make fetch". But there's no archive of
the distfiles on ftp.NetBSD.org and the one on ftp.freebsd.org contains
many distfiles for which there are no ports (yet).

The answer here is to do a "make fetch-list" in /usr/pkgsrc, carry the
resulting list to your machine at work/school and use it there. If you don't
have a NetBSD-compatible ftp(1) (like lukemftp) at work, don't forget to
set FETCH_CMD to something that fetches an URL:

At home:

	% cd /usr/pkgsrc
	% make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
	% scp /tmp/fetch.sh work:/tmp

At work:

	% sh /tmp/fetch.sh
	% tar up /tmp/distfiles and take it home

If you have a machine running NetBSD, and you want to get *all* distfiles
(even ones that aren't for your machine architecture), you can do so by
using the above-mentioned 'make fetch-list'-approach, or fetch the distfiles
directly by typing:

	% make mirror-distfiles

If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can
get all & everything by typing

	% make fetch NO_SKIP=yes


 11.7 How to fetch files from behind a firewall
 ==============================================

If you are sitting behind a firewall which does not allow direct connections
to Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts.
This is done using an environment variable in the form of a URL
e.g. in Amdahl, the machine orpheus.amdahl.com is one of the firewalls, and
it uses port 80 as the proxy port number. So the proxy environment
variables look like:

	ftp_proxy=ftp://orpheus.amdahl.com:80/
	http_proxy=http://orpheus.amdahl.com:80/


 11.8 If your patch contains an RCS ID
 =====================================

See section 4.3 on how to remove RCS IDs from patch files.


 11.9 How to pull in variables from /etc/mk.conf
 ===============================================

The problem with package-defined variables that can be overridden via
MAKECONF or /etc/mk.conf is that make(1) expands a variable as it is
used, but evaluates preprocessor like statements (.if, .ifdef and
.ifndef) as they are read.  So, to use any variable (which may be set
in /etc/mk.conf) in one of the .if* statements, the file /etc/mk.conf
must be included before that .if* statement.

Rather than have a number of ad-hoc ways of including /etc/mk.conf,
should it exist, or MAKECONF, should it exist, include the
pkgsrc/mk/bsd.prefs.mk file in the package Makefile before any
preprocessor-like .if, .ifdef, or .ifndef statements:

	.include "../../mk/bsd.prefs.mk"

	.if defined(USE_MENUS)
	...
	.endif

If you wish to set the CFLAGS variable in /etc/mk.conf please make sure
to use:
  
   CFLAGS+= -your -flags

Using 'CFLAGS=' (ie without the '+') may lead to problems with packages
that need to add their own flags.  Also, you may want to take a look at
the devel/cpuflags package, if you're interested in optimization for the
current CPU.


 11.10 Is there a mailing list for pkg-related discussion?
 =========================================================

Yes. We are using tech-pkg@@NetBSD.org for discussing package related
issues. To subscribe do:

	% echo subscribe tech-pkg | mail majordomo@@NetBSD.org


 11.11 How do i tell "make fetch" to do passive FTP?
 ===================================================

This depends on which utility is used to retrieve distfiles. From
bsd.pkg.mk, FETCH_CMD is assigned the first available command from the
following list:

	/usr/bin/fetch
	${LOCALBASE}/bsd/bin/ftp
	/usr/bin/ftp

On a default NetBSD install, this will be /usr/bin/ftp, which automatically
tries passive connections first, and falls back to active connections if the
server refuses to do passive. For the other tools, add the following to your
/etc/mk.conf file: PASSIVE_FETCH=1

Having that option present will prevent /usr/bin/ftp from falling back to
active transfers.


 11.12 Dependencies on other packages
 ====================================

Your package may depend on some other package being present - and there are
various ways of expressing this dependency. NetBSD supports the
BUILD_DEPENDS and DEPENDS definitions, as well as dependencies via
buildlink3.mk (see section 8).

The basic difference between the two definitions is as follows: The
DEPENDS definition registers that pre-requisite in the binary package,
whilst the BUILD_DEPENDS definition does not.

This means that if you only need a package present whilst you are building,
it should be noted as a BUILD_DEPENDS.

The format for a BUILD_DEPENDS and a DEPENDS definition is:

	<pre-req-package-name>:../../<category>/<pre-req-package>

Please note that the "pre-req-package-name" may include any of the wildcard
version numbers recognised by pkg_info(1).

(a) If your package needs to use another package to build itself, this
is specified using the BUILD_DEPENDS definition.

	BUILD_DEPENDS+=  autoconf-2.13:../../devel/autoconf

(b) If your package needs a library with which to link, this is specified
using the DEPENDS definition.  An example of this is the pkgsrc/print/lyx
package, which uses the xpm library, version 3.4j to build.

	DEPENDS+=       xpm-3.4j:../../graphics/xpm

You can also use wildcards in package dependences:

	DEPENDS+=	xpm-[0-9]*:../../graphics/xpm

Note that such wildcard dependencies are retained when creating binary
packages.  The dependency is checked when installing the binary
package and any package which matches the pattern will be used.
Wildcard dependencies should be used with care.

The -[0-9]* should be used instead of -* to avoid potentially
ambiguous matches such as tk-postgresql matching a tk-* DEPEND.

Wildcards can also be used to specify that a package will only build against
a certain minimum version of a pre-requisite:

	DEPENDS+=       tiff>=3.5.4:../../graphics/tiff

This means that the package will build against version 3.5.4 of the tiff library
or newer.  Such a dependency may be warranted if, for example, the API of the
library has changed with version 3.5.4 and a package would not compile against
an earlier version of tiff.

Please note that such dependencies should only be updated if a package requires
a newer pre-requisite, but not to denote recommendations such as security
updates or ABI changes that do not prevent a package from building correctly.
Such recommendations can be expressed using RECOMMENDED:

	RECOMMENDED+=   tiff>=3.6.1:../../graphics/tiff

In addition to the above DEPENDS line, this denotes that while a package will
build against tiff>=3.5.4, at least version 3.6.1 is recommended.  RECOMMENDED
entries will be turned into dependencies unless explicitly ignored (in which
case a warning will be printed).  Packages that are built with recommendations
ignored may not be uploaded to ftp.NetBSD.org by developers and should not be
used across different systems that may have different versions of binary
packages installed.

For security fixes, please update the package vulnerabilities file as well as
setting RECOMMENDED (see section 11.21 for more information). Also, if
applicable, please submit for pullup to the stable branch.

(c) If your package needs some executable to be able to run correctly, this
is specified using the DEPENDS definition. The pkgsrc/print/lyx package needs
to be able to execute the latex binary from the teTeX package when it runs,
and that is specified:

	DEPENDS+=        teTeX-[0-9]*:../../print/teTeX

The comment about wildcard dependencies from previous paragraph
applies here, too.

If your package needs files from another package to build, see the
first part of the "do-configure" target pkgsrc/print/ghostscript5 package
(it relies on the jpeg sources being present in source form during the
build):

	if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then	\
		cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract;	\
	fi

If you build any other packages that way, please make sure the working
files are deleted too when this package's working files are cleaned up.
The easiest way to do so is by adding a pre-clean target:

	pre-clean:
		cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean

Please also note the BUILD_USES_MSGFMT and BUILD_USES_GETTEXT_M4 definitions,
which are provided as convenience definitions.  The former works out whether
msgfmt(1) is part of the base system, and, if it isn't, installs the
pkgsrc/devel/gettext package.  The latter adds a build dependency on either an
installed version of an older gettext package, or if it isn't, installs the
pkgsrc/devel/gettext-m4 package.


 11.13 Conflicts with other packages
 ===================================

Your package may conflict with other packages a user might already have
installed on his system, e.g. if your package installs the same set of
files like another package in our pkgsrc tree.

In this case you can set CONFLICTS to a space separated list of packages
(including version string) your package conflicts with.

For example pkgsrc/x11/Xaw3d and pkgsrc/x11/Xaw-Xpm install provide the
same shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile:

	CONFLICTS=      Xaw-Xpm-[0-9]*

and in pkgsrc/x11/Xaw-Xpm/Makefile:

	CONFLICTS=      Xaw3d-[0-9]*

Packages will automatically conflict with other packages with the name prefix
and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
with the older version "Xaw3d-1.3".


 11.14 Software which has a WWW Home Page
 ========================================

The NetBSD packages system now supports a variable called HOMEPAGE.
If the software being packaged has a home page, the Makefile should
include the URL for that page in the HOMEPAGE variable. The definition
of the variable should be placed immediately after the MAINTAINER
variable.


 11.15 How to handle modified distfiles with the 'old' name
 ==========================================================

Sometimes authors of a software package make some modifications after the
software was released, and they put up a new distfile without changing the
package's version number. If a package is already in pkgsrc at that time,
the md5 checksum will no longer match. The correct way to work around this
is to update the package's md5 checksum to match the package on the master
site (beware, any mirrors may not be up to date yet!), and to remove the
old distfile from ftp.NetBSD.org's /pub/NetBSD/packages/distfiles directory.
Furthermore, a mail to the package's author seems appropriate making sure
the distfile was really updated on purpose, and that no trojan horse or so
crept in.


 11.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
 =========================================================================

When compiling the pkgsrc/pkgtools/pkg_install package, you get the error
from make that it doesn't know how to make /usr/share/tmac/tmac.andoc? This
indicates that you don't have installed the "text" set on your machine
(nroff, ...). It is recommended that you do that.

In the case of the pkg_install package, you can get away with setting
NOMAN=YES either in the environment or in /etc/mk.conf.


 11.17 How to handle incrementing versions when fixing an existing package
 =========================================================================

When making fixes to an existing package it can be useful to change
the version number in PKGNAME. To avoid conflicting with future versions
by the original author, a 'nb1' ('nb2', ...) suffix can be used on package
versions by setting PKGREVISION=1 (2,. ..). The "nb" is treated like a "."
by the pkg tools. E.g.

DISTNAME=	foo-17.42
PKGREVISION=	9

will result in a PKGNAME of foo-17.42nb9.

When a new release of the package is released, the PKGREVISION should be
removed. E.g. on a new minor release of the above package, things should
be like:

DISTNAME=	foo-17.43


 11.18 "Could not find bsd.own.mk" - what's wrong?
 =================================================

You didn't install the compiler set, comp.tgz, when you installed your
NetBSD machine. Please get it and install it, by extracting it in /:

	# tar --unlink -pvxf .../comp.tgz

comp.tgz is part of every NetBSD release, please get the one matching
the release you have installed (determine via "uname -r").


 11.19 Restricted packages
 =========================

Some licenses restrict how software may be re-distributed.  In order to
satisfy these restrictions, the package system defines five make variables
that can be set to note these restrictions:

 * RESTRICTED:
   This variable should be set whenever a restriction exists
   (regardless of its kind).  Set this variable to a string
   containing the reason for the restriction.

 * NO_BIN_ON_CDROM:
   Binaries may not be placed on CD-ROM.  Set this variable to
   ${RESTRICTED} whenever a binary package may not be included
   on a CD-ROM.

 * NO_BIN_ON_FTP:
   Binaries may not be placed on an ftp server.  Set this
   variable to ${RESTRICTED} whenever a binary package may not
   not be made available on the Internet.

 * NO_SRC_ON_CDROM:
   Distfiles may not be placed on CD-ROM.  Set this variable to
   ${RESTRICTED} if re-distribution of the source code or other
   distfile(s) is not allowed on CD-ROMs.

 * NO_SRC_ON_FTP:
   Distfiles may not be placed on FTP.  Set this variable to
   ${RESTRICTED} if re-distribution of the source code or other
   distfile(s) via the Internet is not allowed.

Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic
make variables to denote restrictions is deprecated, because they
unconditionally prevent users from generating binary packages!


 11.20 Packages using (n)curses
 ==============================

Some packages need curses functionality that wasn't present in NetBSD's own
curses prior to 1.4Y.

If ../../devel/ncurses/buildlink3.mk is included in a package's Makefile,
then a curses library and headers with ncurses functionality are linked
into ${BUILDLINK_DIR} at pre-configure time.  If ncurses is actually
required, then define USE_NCURSES in the package's Makefile:

	USE_NCURSES=	# KEY_RESIZE

The comment should indicate which functions are missing.


 11.21 Automated security check
 ==============================

Please be aware that there can often be bugs in third-party software,
and some of these bugs can leave a machine vulnerable to exploitation
by attackers.  In an effort to lessen the exposure, the NetBSD
packages team maintains a database of known-exploits to packages which
have at one time been included in pkgsrc.  The database can be
downloaded automatically, and a security audit of all packages
installed on a system can take place.  To do this, install the
pkgsrc/security/audit-packages package.  It has two components:

 (1) download-vulnerability-list, an easy way to download a list of the
     security vulnerabilities information. This list is kept up to date by
     the NetBSD security officer and the NetBSD packages team, and is
     distributed from the NetBSD ftp server:

	ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities

 (2) audit-packages, an easy way to audit the current machine, checking
     each vulnerability which is known. If a vulnerable package is
     installed, it will be shown by output to stdout, including a
     description of the type of vulnerability, and a URL containing more
     information.

Use of the audit-packages package is strongly recommended.

The following message is displayed as part of the audit-packages
installation procedure:

        ======================================================================
	You may wish to have the vulnerabilities file downloaded daily so that
	it remains current.  This may be done by adding an appropriate entry
	to the root users crontab(5) entry.  For example the entry
	
	# download vulnerabilities file
	0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1
	
	will update the vulnerability list every day at 3AM.
	
	In addition, you may wish to run the package audit from the daily
	security script.  This may be accomplished by adding the following
	lines to /etc/security.local
	
	if [ -x ${PREFIX}/sbin/audit-packages ]; then
	        ${PREFIX}/sbin/audit-packages
	fi
        ======================================================================


Note to package developers: When a vulnerability is found, this should
be noted in localsrc/security/advisories/pkg-vulnerabilities, and after
the commit of that file, it should be copied to both
/pub/NetBSD/packages/distfiles/pkg-vulnerabilities and vulnerabilities
on ftp.NetBSD.org by localsrc/security/advisories/Makefile.  In addition,
if a buildlink3.mk file exists for an affected package, bumping PKGREVISION
and creating a corresponding BUILDLINK_RECOMMENDED.<pkg> entry should
be considered. See section 8 for more information about writing
buildlink3.mk files and BUILDLINK_* definitions. Also if the fix should
be made in the stable pkgsrc branch, be sure to submit a pullup request.


 11.22 What's the proper way to create an account from a package?
 ================================================================

There are two make variables used to control the creation of package-specific
groups and users at pre-install time.  The first is PKG_GROUPS, which is a
list of group[:groupid] elements, where the groupid is optional.  The second
is PKG_USERS, which is a list of elements of the form:

	user:group[:[userid][:[description][:[home][:shell]]]]

where only the user and group are required, the rest being optional.  A
simple example is:

	PKG_GROUPS=	foogroup
	PKG_USERS=	foouser:foogroup

A more complex example is that creates two groups and two users is:

	PKG_GROUPS=	group1 group2:1005
	PKG_USERS=	first:group1::First\\ User			\
			second:group2::Second\\ User:/home/second:${SH}

By default, a new user will have home directory /nonexistent, and login shell
/sbin/nologin unless they are specified as part of the user element.

The package Makefile must also set USE_PKGINSTALL to "YES" prior to the
inclusion of bsd.pkg.mk.  This will cause the users and groups to be created
at pre-install time, and the admin will be prompted to remove them at
post-deinstall time.  Automatic creation of the users and groups can be
toggled on and off by setting the environment variable PKG_CREATE_USERGROUP
prior to package installation.


 11.23 How to handle compiler bugs
 =================================

Some source files trigger bugs in the compiler, based on combinations
of compiler version and architecture and almost always relation to
optimisation being enabled.  Common symptoms are gcc internal errors
or never finishing compiling a file.

Typically a workaround involves testing the MACHINE_ARCH and compiler
version, disabling optimisation for that file/MACHINE_ARCH/compiler
combination, and documenting it in doc/HACKS. See doc/HACKS for
examples.


 11.24 Packages providing info files
 ===================================

Some packages install info files or use the makeinfo or install-info
commands. Each of the info files:

	- is considered to be installed in the directory
	  ${PREFIX}/${INFO_DIR};
	- is registered in the Info directory file
	  ${PREFIX}/${INFO_DIR}/dir;
	- and must be listed as a filename in the INFO_FILES variable
	  in the package Makefile.
 
INFO_DIR defaults to `info' and can be overridden in the package Makefile.
INSTALL and DEINSTALL scripts will be generated to handle the registration
of the info files in the Info directory file.
The install-info command (used for the info files registration) is either
provided by the system or by a special purpose package automatically 
added as dependency if needed.

A package which needs the makeinfo command at build time must define
the variable USE_MAKEINFO in its Makefile.  If a minimum version of
the makeinfo command is needed, it should be noted with the
TEXINFO_REQD variable in the package Makefile.  By default a minimum
version of 3.12 is required.  If the system does not provide a
makeinfo command or if it does not match the required minimum, a build
dependency on the devel/gtexinfo package will be added automatically.

The build and installation process of the software provided by the package
should not use the install-info command as the registration of info files
is the task of the package INSTALL script, and it must use the appropriate
makeinfo command.

To achieve this goal the pkgsrc infrastructure creates overriding scripts
for the install-info and makeinfo command in a directory listed early in PATH.

The script overriding install-info has no effect except the logging of a
message. The script overriding makeinfo logs a message and according to the
value of USE_MAKEINFO and TEXINFO_REQD either run the appropriate makeinfo
command or exit on error.

 11.25 Packages whose distfiles aren't available for plain downloading
 =====================================================================

If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES
and a 'make fetch' will call files/getsite.sh with the name of each file
to download as an argument, expecting it to output the URL of the directory
from which to download it. graphics/ns-cult3d is an example of this usage.

If the download can't be automated, because the user must submit personal
information to apply for a password, or must pay for the source, or whatever,
you can set _FETCH_MESSAGE to a macro which displays a message explaining
the situation. _FETCH_MESSAGE must be executable shell commands, not just a
message. (Generally, it executes ${ECHO}). As of this writing, the following
packages use this: audio/realplayer, cad/simian, devel/ipv6socket,
emulators/vmware-module, fonts/acroread-jpnfont, sysutils/storage-manager,
www/ap-aolserver, www/openacs. Try to be consistent with them.


 11.26 Using pkgsrc on non-NetBSD (Darwin, FreeBSD, IRIX, Linux, OpenBSD, Solaris)
 =================================================================================

In order to use pkgsrc on a non-NetBSD operating system, you must first
bootstrap the necessary utilities (BSD make, pkg_*, ...). See
http://www.NetBSD.org/Documentation/software/packages.html#bootstrap
for information on boostrapping.  Binary bootstrap-kits are available from that
URL as well.  If your Operating System is not yet supported, we encourage you to
port the bootstrap-kit and submit your changes.


 11.27 Configuration files handling and placement
 ================================================

The global variable PKG_SYSCONFBASE (and some others) can be set by the
system administrator in /etc/mk.conf to define the place where
configuration files get installed. Therefore, packages must be adapted to
support this feature. Keep in mind that you should only install files that
are strictly necessary in the configuration directory, files that can
go to $PREFIX/share should go there.

We will take a look at available variables first (bsd.pkg.mk contains more
information). PKG_SYSCONFDIR is where the configuration files for a package
may be found (that is, the full path, e.g. /etc or /usr/pkg/etc). This
value may be customized in various ways:

 1) PKG_SYSCONFBASE is the main config directory under which all package
    configuration files are to be found. Users will typically want to set
    it to /etc, or accept the default location of $PREFIX/etc.

 2) PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which
    the configuration files for a particular package may be found. Defaults
    to $SYSCONFBASE

 3) PKG_SYSCONFVAR is the special suffix used to distinguish any overriding
    values for a particular package (see next item). It defaults to
    ${PKGBASE}, but for a collection of related packages that should all
    have the same PKG_SYSCONFDIR value, it can be set in each of the
    package Makefiles to a common value.

 4) PKG_SYSCONFDIR.${PKG_SYSCONFVAR} overrides the value of
    ${PKG_SYSCONFDIR} for packages with the same value for PKG_SYSCONFVAR.

    As an example, all the various KDE packages may want to set
    PKG_SYSCONFVAR to "kde" so admins can set ${PKG_SYSCONFDIR.kde} in
    /etc/mk.conf to define where to install KDE config files.

Programs' configuration directory should be defined during the configure
stage. Packages that use GNU autoconf can usually do this by using the
--sysconfdir parameter, but this brings some problems as we will see now.
When you change this pathname in packages, you should not allow them to
install files in that directory directly. Instead they need to install
those files under share/examples/${PKGNAME} so PLIST can register them.

Once you have the required configuration files in place (under the
share/examples directory) the variable CONF_FILES should be set to copy
them into PKG_SYSCONFDIR. The contents of this variable is formed by pairs
of filenames; the first element of the pair specifies the file inside the
examples directory (registered by PLIST) and the second element specifies
the target file. This is done this way to allow binary packages to place
files in the right directory using INSTALL/DEINSTALL scripts which are
created automatically.  The package Makefile must also set USE_PKGINSTALL
to "YES" prior to the inclusion of bsd.pkg.mk to use these automatically
generated scripts.  The automatic copying of config files can be toggled by
setting the environment variable PKG_CONFIG prior to package installation.

Here is an example, taken from mail/mutt/Makefile:

	EGDIR=	${PREFIX}/share/doc/mutt/samples
	CONF_FILES=	${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc

As you can see, this package installs configuration files inside EGDIR,
which are registered by PLIST. After that, the variable CONF_FILES lists
the installed file first and then the target file. Users will also get an
automatic message when files are installed using this method.


 11.28 Packages providing login shells
 =====================================

If the purpose of the package is to provide a login shell, the variable
PKG_SHELL should contain the full pathname of the shell executable installed
by this package. The package Makefile also must set USE_PKGINSTALL to "YES"
prior to the inclusion of bsd.pkg.mk to use the automatically generated
INSTALL/DEINSTALL scripts.

An example taken from shells/zsh:

	USE_PKGINSTALL=	YES
	PKG_SHELL=	${PREFIX}/bin/zsh

The shell is registered into /etc/shells file automatically in the
post-install step by the auto-generated INSTALL script and removed in the
deinstall step by the DEINSTALL script.


 11.29 Packages providing locale catalogues
 ==========================================

If the package provides its own locale catalogues, the variable
USE_PKGLOCALEDIR should be defined.  It will ensure that the package's
Makefile template files are fixed and point to the correct locale
directories (which may vary, depending on OS), if necessary.  See also
section 5.1 for details about ${PKGLOCALEDIR}.


 11.30 Using 'sudo' with pkgsrc
 ==============================

When installing packages as non-root user and using the just-in-time
su(1) feature of pkgsrc, it can become annoying to type in the root
password for each required package installed. To avoid this, the sudo
package can be used, which does password caching over a limited time.
To use it, install sudo (either as binary package or from
pkgsrc/security/sudo) and then put the following into your /etc/mk.conf:

	.if exists(/usr/pkg/bin/sudo)
	SU_CMD=/usr/pkg/bin/sudo /bin/sh -c
	.endif


 11.31 Packages that cannot or should not be built
 =================================================

There are several reasons why a package might be instructed to not
build under certain circumstances. If the package builds and runs
on most platforms, the exceptions should be noted with NOT_FOR_PLATFORM.
If the package builds and runs on a small handful of platforms,
set ONLY_FOR_PLATFORM instead. If the package should be skipped
(for example, because it provides functionality already provided
by the system), set PKG_SKIP_REASON to a descriptive message. If
the package should fail because some preconditions are not met,
set PKG_FAIL_REASON to a descriptive message.

IGNORE is deprecated because it didn't provide enough information
to determine whether the build should fail.


 11.32 Packages which should not be deleted, once installed
 ==========================================================

To ensure that a package may not be deleted, once it has been installed,
the PKG_PRESERVE definition should be set in the package Makefile. This
will be carried into any binary package that is made from this pkgsrc
entry. A "preserved" package will not be deleted using pkg_delete(1),
unless the "-f" option is used.


 11.33 Packages containing perl scripts
 ======================================

If your package contains interpreted perl scripts, set REPLACE_PERL to
ensure that the proper interpreter path is set. REPLACE_PERL should
contain a list of scripts, relative to WRKSRC, that you want adjusted.


 11.34 Packages with hardcoded paths to other interpreters
 =========================================================

Your package may also contain scripts with hardcoded paths to other
interpreters besides (or as well as) perl.  To correct the full
pathname to the script interpreter, you need to set the following
definitions in your Makefile (we shall use tclsh in this example):

REPLACE_INTERPRETER+=	tcl
_REPLACE.tcl.old=	.*/bin/tclsh
_REPLACE.tcl.new=	${PREFIX}/bin/tclsh
_REPLACE_FILES.tcl=	...list of tcl scripts which need to be fixed,
			relative to ${WRKSRC}, just as in REPLACE_PERL


 11.35 Utilities for package management (pkgtools)
 =================================================

The directory pkgtools contains a number of useful utilities.  This section
attempts only to make the reader aware of the utilities and when they might
be useful, and not to duplicate the documentation that comes with each
package.

Utilities used by pkgsrc (automatically installed when needed):
  x11-links - symlinks for use by buildlink

OS tool augmentation (automatically installed when needed):
  digest - calculates SHA1 checksums (and other kinds)
  libnbcompat - compat library for pkg tools
  mtree - installed on non-BSD systems due to lack of native mtree
  pkg_install - up-to-date replacement for /usr/sbin/pkg_install, or for
	        use on operating systems where pkg_install is not present

Utilities used by pkgsrc (not automatically installed):
  pkg_tarup - create a binary package from an already-installed package.
	      used by 'make replace' to save the old package
  xpkgwedge - put X11 packages someplace else (see above)

Utilities for keeping track of installed packages, being up to date, etc:
  pkgchk - installs pkg_chk, which reports on packages whose installed
	   versions do not match the latest pkgsrc entries
  pkgdep - makes dependency graphs of packages, to aid in choosing a
	   strategy for updating
  pkgdepgraph - make graph from above (uses graphviz)
  pkglint - This provides two distinct abilities:
	      check a pkgsrc entry for correctness (pkglint)
	      check for and remove out-of-date distfiles and binary
	      packages (lintpkgsrc)
  pkgsurvey - report what packages you have installed

Utilities for people maintaining or creating individual packages:
  pkgdiff - automate making and maintaining patches for a package
  rpm2pkg, url2pkg - aids in converting to pkgsrc
  gensolpkg - convert pkgsrc to a Solaris package

Utilities for people maintaining pkgsrc (or more obscure pkg utilities)
  pkgconflict - find packages that conflict but aren't marked as such
  pkgcomp - build packages in a chrooted area
  libkver - spoof kernel version for chrooted cross builds


 11.36 How to use pkgsrc as non-root?
 ====================================

If you want to use pkgsrc as non-root user, you can set some variables
to make pkgsrc work under these conditions. Please see 
http://mail-index.NetBSD.org/tech-pkg/2003/09/27/0023.html
for more details.


 11.37 Packages installing GConf2 data files
 ===========================================

If a package installs .schemas or .entries files, used by GConf2, you need
to take some extra steps to make sure they get registered in the database:

 1) Include "../../devel/GConf2/schemas.mk" instead of its buildlink[23].mk
    file.  This takes care of rebuilding the GConf2 database at installation
    and deinstallation time, and tells the package where to install GConf2
    data files using some standard configure arguments.  It also disallows
    any access to the database directly from the package.

 2) Ensure that the package installs its .schemas files under
    ${PREFIX}/share/gconf/schemas.  If they get installed under ${PREFIX}/etc,
    you will need to manually patch the package.  Please send your changes
    back to authors!

 3) Check the PLIST and remove any entries under the etc/gconf directory,
    as they will be handled automatically.  See section 11.27 for more
    information.

 4) Define the GCONF2_SCHEMAS variable in your Makefile with a list of all
    .schemas files installed by the package, if any.  Names must not contain
    any directories in them.

 5) Define the GCONF2_ENTRIES variable in your Makefile with a list of all
    .entries files installed by the package, if any.  Names must not contain
    any directories in them.


 11.38 Packages installing scrollkeeper data files
 =================================================

If a package installs .omf files, used by scrollkeeper, you need to take some
extra steps to make sure they get registered in the database:

 1) Include "../../textproc/scrollkeeper/omf.mk" instead of its
    buildlink[23].mk file.  This takes care of rebuilding the scrollkeeper
    database at installation and deinstallation time, and disallows any
    access to it directly from the package.

 2) Check the PLIST and remove any entries under the libdata/scrollkeeper
    directory, as they will be handled automatically.

 3) Remove the share/omf directory from the PLIST.  It will be handled by
    scrollkeeper.


 11.39 Packages installing X11 fonts
 ===================================

If a package installs font files, you will need to rebuild the fonts database
in the directory where they get installed at installation and deinstallation
time.  This can be automatically done by using mk/fonts.mk, which you need to
include in your Makefile.

When the file is included, you can list the directories where fonts are
installed in the FONTS_<TYPE>_DIRS variables, where <TYPE> can be one of TTF,
TYPE1 or X11.  Also make sure that the database file "fonts.dir" is not listed
in the PLIST.

Note that you should not create new directories for fonts; instead use the
standard ones to avoid the user having the manually configure the X server
to find them.


 11.40 Packages installing GTK2 modules
 ======================================

If a package installs gtk2 immodules or loaders, you need to take some extra
steps to get them registered in the GTK2 database properly:

 1) Include "../../x11/gtk2/modules.mk" instead of its buildlink[23].mk file.
    This takes care of rebuilding the database at installation and
    deinstallation time.

 2) Set GTK2_IMMODULES to YES if your package installs GTK2 immodules.

 3) Set GTK2_LOADERS to YES if your package installs GTK2 loaders.

 4) Patch the package to not touch any of the gtk2 databases directly.  These
    are:

        * libdata/gtk-2.0/gdk-pixbuf.loaders
        * libdata/gtk-2.0/gtk.immodules

 4) Check the PLIST and remove any entries under the libdata/gtk-2.0 directory,
    as they will be handled automatically.


 11.41 Packages installing SGML or XML data
 ==========================================

If a package installs SGML or XML data files that need to be registered in
system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
extra steps:

 1) Include "../../textproc/xmlcatmgr/catalogs.mk" in your Makefile, which
    takes care of registering those files in system-wide catalogs at
    installation and deinstallation time.

 2) Set SGML_CATALOGS to the full path of any SGML catalogs installed by
    the package.

 3) Set XML_CATALOGS to the full path of any XML catalogs installed by
    the package.

 4) Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
    These come in groups of three strings; see xmlcatmgr(1) for more
    information (specifically, arguments recognized by the 'add' action).
    Note that you will normally not use this variable.

 5) Set XML_ENTRIES to individual entries to be added to the XML catalog.
    These come in groups of three strings; see xmlcatmgr(1) for more
    information (specifically, arguments recognized by the 'add' action).
    Note that you will normally not use this variable.


 11.42 Packages using intltool
 =============================

If a package uses intltool during its build, include the
"../../textproc/intltool/buildlink3.mk" file, which forces it to use the
intltool package provided by pkgsrc, instead of the one bundled with the
distribution file.

This tracks intltool's build-time dependencies and uses the latest available
version; this way, the package benefits of any bug fixes that may have appeared
since it was released.


 11.43 How can I install/use XFree86 from pkgsrc?
 ================================================

If you want to use XFree86 from pkgsrc instead of your system's own
X11 (/usr/X11R6, /usr/openwin, ...), you will have to add the following
lines into mk.conf:

    X11_TYPE=XFree86

 11.44 How can I install/use X.org from pkgsrc?
 ==============================================

If you want to use X.org from pkgsrc instead of your system's own
X11 (/usr/X11R6, /usr/openwin, ...) you will have to add the following
lines into mk.conf:

    X11_TYPE=xorg

 11.45 Where's the pkgviews documentation?
 =========================================

Pkgviews is tightly integrated with buildlink. You can find a
pkgviews User's Guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.


 11.46 How do I handle common shared directories?
 ================================================

A "shared directory" is a directory where multiple (and unrelated)
packages install files.  These directories are problematic because
you have to add special tricks in the PLIST to conditionally remove
them, or have some centralized package handle them.

Within pkgsrc, you'll find both approaches.  If a directory is
shared by a few unrelated packages, it's often not worth to add an
extra package to remove it.  Therefore, one simply does:

    @@unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE}

in the PLISTs of all affected packages, instead of the regular "@@dirrm" line.

However, if the directory is shared across many packages, two different
solutions are available:

1) If the packages have a common dependency, the directory can be removed
   in that.  For example, see textproc/scrollkeeper, which removes the
   shared directory share/omf.

2) If the packages using the directory are not related at all (they have no
   common dependencies), a *-dirs package is used.
  
From now on, we'll discuss the second solution.  To get an idea of the
*-dirs packages available, issue:

    % cd .../pkgsrc
    % ls -d */*-dirs

Their use from other packages is very simple.  The USE_DIRS variable takes
a list of package names (without the -dirs part) together with the required
version number (always pick the latest one when writting new packages).

For example, if a package installs files under share/applications, it should
have the following line in it:

    USE_DIRS+= xdg-1.1

After regenerating the PLIST using 'make print-PLIST', you should get the
right (commented out) lines.

Note that, even if your package is using X11BASE, it must not depend on
the *-x11-dirs packages.  Just specify the name without that part and pkgsrc
(in particular, mk/dirs.mk) will take care of it.


 11.47 How can I tweak 'make print-PLIST' output?
 ================================================

If you have used any of the *-dirs packages, as explained in 11.45, you
may have noticed that 'make print-PLIST' outputs a set of @@comment's
instead of real @@dirrm lines.  You can also do this for specific directories
and files, so that the results of that command are very close to reality.
This helps _a lot_ during the update of packages.

The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that
are used to filter the output of print-PLIST.  You can _append_ any chunk
of AWK scripting you like to it, but be careful with quoting.

For example, to get all files inside the libdata/foo directory removed from
the resulting PLIST:

    PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }

And to get all the @@dirrm lines referring to a specific (shared) directory
converted to @@comment's:

    PRINT_PLIST_AWK+= /^@@dirrm share\/special/ { print "@@comment " $$0; next; }


 11.48 Packages that install score files
 =======================================

Certain packages, most of them in the games category, install a score file
that allows all users on the system to record their highscores.  In order for
this to work, the binaries need to be installed setgid and the score files
owned by the appropriate group and/or owner (traditionally the "games"
user/group).  The following variables, documented in more detail in
mk/bsd.pkg.defaults.mk, control this behaviour:  SETGIDGAME, GAMEDATAMODE,
GAMEGRP, GAMEMODE, GAMEOWN.

Note that per default, setgid installation of games is disabled;  setting
SETGIDGAME=YES will set all the other variables accordingly.

A package should therefor never hard code file ownership or access permissions
but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly.


 11.49 Packages installing extensions to the MIME database
 =========================================================

If a package provides extensions to the MIME database by installing .xml
files inside ${PREFIX}/share/mime/packages, you need to take some extra
steps to ensure that the database is kept consistent with respect to these
new files:

 1) Include "../../databases/shared-mime-info/mimedb.mk" (avoid using
    the buildlink3.mk file from this same directory, which is reserved
    for inclusion from other buildlink3.mk files).  It takes care of
    rebuilding the MIME database at installation and deinstallation time,
    and disallows any access to it directly from the package.

 2) Check the PLIST and remove any entries under the share/mime directory,
    _except_ for files saved under share/mime/packages.  The former are
    handled automatically by the update-mime-database program, but the
    later are package-dependent and must be removed by the package that
    installed them in the first place.

 3) Remove any share/mime/* directories from the PLIST.  They will be
    handled by the shared-mime-info package.


 12 Submitting & Committing
 ==========================

 12.1 Submitting your packages
 =============================

You have to separate between binary and "normal" (source) packages here:

 * precompiled binary packages:
   Our policy is that we accept binaries only from NetBSD developers to
   guarantee that the packages don't contain any trojan horses etc.
   This is not to piss anyone off but rather to protect our users!
   You're still free to put up your home-made binary packages and tell
   the world where to get them.

 * packages:
   First, check that your package is complete, compiles and runs well; see
   section 9 and the rest of this document. Next, generate an uuencoded
   gzipped tar(1) archive, preferably with all files in a single directory.
   Finally, send-pr(1) with category "pkg", a synopsis which includes the
   package name and version number, a short description of your package
   (contents of the COMMENT variable or DESCR file are OK) and attach the
   archive to your PR.

   If you want to submit several packages, please send a separate PR for
   each one, it's easier for us to track things that way.

   Alternatively, you can also import new packages into pkgsrc-wip
   (pkgsrc work-in-progress); see the homepage at
	http://pkgsrc-wip.sourceforge.net/
   for details.


 12.2 Committing: Importing the package into CVS
 ===============================================

This section is only of interest for NetBSD developers with write
access to the NetBSD pkgsrc repository. Please remember that cvs
imports files relative to the cwd, and that the pathname that you
give the "cvs import" command is so that it knows where to place
the files in the repository.  Newly created packages should be
imported with a vendor tag of "TNF" and a release tag of "pkgsrc-base",
e.g:

	% cd .../pkgsrc/<category>/<pkgname>
	% cvs import pkgsrc/<category>/<pkgname> TNF pkgsrc-base

and remember to move the directory from which you imported out of
the way, or cvs will complain the next time you "cvs update" your
source tree.  Also don't forget to add the new package to the
category's Makefile.

The commit message of the initial import should include part of the
DESCR file, so people reading the mailing lists know what the package
is/does.

Please note all package updates/additions in pkgsrc/doc/CHANGES! It's very
important to keep this file up to date and conforming to the existing
format, because it will be used by scripts to automatically update pages on
www.NetBSD.org and other sites. Additionally, check the pkgsrc/doc/TODO
file and remove the entry for the package you updated, in case it was
mentioned there.

For new packages, "cvs import" is preferred to "cvs add" because
the former gets everything with a single command, and provides a
consistent tag.


 12.3 Updating a Package to a Newer Version
 ==========================================

Please always put a concise, appropriate and relevant summary of the
changes between old and new versions into the commit log when updating
a package. There are various reasons for this:

+ a URL is volatile, and can change over time. It may go away completely,
or its information may be overwritten by newer information.

+ having the change information between old and new versions in our CVS
repository is very useful for people who use either cvs or anoncvs.

+ having the change information between old and new versions in our CVS
repository is very useful for people who read the pkgsrc-changes mailing
list, so that they can make tactical decisions about when to upgrade
the package.

Please also recognise that, just because a new version of a package
has been released, it should not automatically be upgraded in the CVS
repository.  We prefer to be conservative in the packages that are
included in pkgsrc - development or beta packages are not really the
best thing for most places in which pkgsrc is used. Please use your
judgement about what should go into pkgsrc, and bear in mind that
stability is to be preferred above new and possibly untested features.


 12.4 Moving a Package in pkgsrc
 ===============================

 1. Make a copy of the directory somewhere else.
 2. Remove all CVS dirs.
    Alternatively to the first two steps you can also do:
	  cvs -d user@@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
    and use that for further work.
 3. Fix CATEGORIES and any DEPENDS paths that just did ../package
    instead of ../../category/package.
 4. "cvs import" the modified package in the new place.
 5. Check if any package depends on it:
	cd /usr/pkgsrc
	grep /package */*/Makefile* */*/buildlink*
 6. Fix paths in packages from step 5 to point to new location.
 7. "cvs rm (-f)" the package at the old location.
 8. Remove from oldcategory/Makefile.
 9. Add to newcategory/Makefile.
10. Commit the changed and removed files:
	cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
    and any packages from step 5, of course.


 13 A simple example of a package: bison
 =======================================

I checked to find a piece of software that wasn't in the packages
collection, and picked GNU bison. Quite why someone would want to have
bison when Berkeley yacc is already present in the tree is beyond me, but
it's useful for the purposes of this exercise.


 13.1 files
 ==========

The file contents in this section must be used without the "> " prefix.


 13.1.1 Makefile
 ===============

	# <$>NetBSD<$>
	
	DISTNAME=       bison-1.25
	CATEGORIES=     devel
	MASTER_SITES=   ${MASTER_SITE_GNU}
	MAINTAINER=     thorpej@@NetBSD.org
	HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
	COMMENT=        GNU yacc clone
	
	GNU_CONFIGURE=  yes
	INFO_FILES=     bison.info
	
	.include "../../mk/bsd.pkg.mk"


 13.1.2 DESCR
 ================

	GNU version of yacc.  Can make re-entrant parsers, and numerous other
	improvements.  Why you would want this when Berkeley yacc(1) is part
	of the NetBSD source tree is beyond me.


 13.1.3 PLIST
 ================

	@@comment <$>NetBSD<$>
	bin/bison
	man/man1/bison.1.gz
	info/bison.info
	info/bison.info-1
	info/bison.info-2
	info/bison.info-3
	info/bison.info-4
	info/bison.info-5
	share/bison.simple
	share/bison.hairy


 13.1.4 Checking a package "pkglint"
 ===================================

The NetBSD package system comes with a tool called "pkglint" (located in the
directory "pkgsrc/pkgtools/pkglint") which helps to check the contents of these
files. After installation it is quite easy to use, just change to the
directory of the package you wish to examine and execute "pkglint":

	% pkglint
	OK: checking ./DESCR.
	OK: checking Makefile.
	OK: checking distinfo.
	OK: checking patches/patch-aa.
	looks fine.

Depending on the supplied command line arguments (see "man pkglint") more
verbose checks will be performed. Use e.g. "pkglint -v" for a very verbose
check.


 13.2 Steps for building, installing, packaging
 ==============================================

Create the directory where the package lives, plus any auxiliary directories:

	# cd /usr/pkgsrc/lang
	# mkdir bison
	# cd bison
	# mkdir patches pkg

Create Makefile, DESCR and PLIST, then continue with fetching the distfile:

	# make fetch
	>> bison-1.25.tar.gz doesn't seem to exist on this system.
	>> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
	Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
	ftp: Error retrieving file: 500 Internal error
	
	>> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
	Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
	ftp: Error retrieving file: 500 Internal error
	
	>> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
	Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
	Successfully retrieved file.

Generate the checksum of the distfile into distinfo:

	# make makesum

Now compile:

	# make
	>> Checksum OK for bison-1.25.tar.gz.
	===>  Extracting for bison-1.25
	===>  Patching for bison-1.25
	===>   Ignoring empty patch directory
	===>  Configuring for bison-1.25
	creating cache ./config.cache
	checking for gcc... cc
	checking whether we are using GNU C... yes
	checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
	checking how to run the C preprocessor... cc -E
	checking for minix/config.h... no
	checking for POSIXized ISC... no
	checking whether cross-compiling... no
	checking for ANSI C header files... yes
	checking for string.h... yes
	checking for stdlib.h... yes
	checking for memory.h... yes
	checking for working const... yes
	checking for working alloca.h... no
	checking for alloca... yes
	checking for strerror... yes
	updating cache ./config.cache
	creating ./config.status
	creating Makefile
	===>  Building for bison-1.25
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g LR0.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g allocate.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g closure.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g conflicts.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g derives.c
	cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getargs.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g gram.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
	cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o getopt.o getopt1.o
	./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
	rm -f bison.s1
	sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1

Everything seems OK, so install the files:

	# make install
	>> Checksum OK for bison-1.25.tar.gz.
	===>  Installing for bison-1.25
	sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
	rm -f /usr/pkg/bin/bison
	cd /usr/pkg/share; rm -f bison.simple bison.hairy
	rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
	install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
	/usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
	/usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
	cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
	/usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
	===>  Registering installation for bison-1.25

You can now use bison, and also - if you decide so - remove it with
"pkg_delete bison-1.25". Should you decide that you want a binary package,
do this now:

	# make package
	>> Checksum OK for bison-1.25.tar.gz.
	===>  Building package for bison-1.25
	Creating package bison-1.25.tgz
	Registering depends:.
	Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'

Now that you don't need the source and object files any more, clean up:

	# make clean
	===>  Cleaning for bison-1.25


======================
Appendix A: build logs
======================

 A.1 Building top
 ================

	# make
	>> top-3.5beta5.tar.gz doesn't seem to exist on this system.
	>> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
	Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
	Successfully retrieved file.
	>> Checksum OK for top-3.5beta5.tar.gz.
	===>  Extracting for top-3.5beta5
	===>  Patching for top-3.5beta5
	===>  Applying NetBSD patches for top-3.5beta5
	===>  Configuring for top-3.5beta5
	/bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
	chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
	
	Reading configuration from last time...
	
	Using these settings:
	        Bourne Shell   /bin/sh
	          C compiler   cc
	    Compiler options   -DHAVE_GETOPT -O
	         Awk command   awk
	     Install command   /usr/bin/install
	
	              Module   netbsd13
	             LoadMax   5.0
	        Default TOPN   -1
	        Nominal TOPN   18
	       Default Delay   2
	Random passwd access   yes
	          Table Size   47
	               Owner   root
	         Group Owner   kmem
	                Mode   2755
	       bin directory   $(PREFIX)/bin
	       man directory   $(PREFIX)/man/man1
	       man extension   1
	       man style       man
	
	Building Makefile...
	Building top.local.h...
	Building top.1...
	Doing a "make clean".
	rm -f *.o top core core.* sigdesc.h
	To create the executable, type "make".
	To install the executable, type "make install".
	===>  Building for top-3.5beta5
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c top.c
	awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c commands.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c display.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c screen.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c username.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c utils.c
	utils.c: In function `errmsg':
	utils.c:348: warning: return discards `const' from pointer target type
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c version.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c getopt.c
	cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
	rm -f top
	cc -o top top.o commands.o display.o screen.o username.o  utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
	#
	#
	#
	#
	# make install
	>> Checksum OK for top-3.5beta5.tar.gz.
	===>  Installing for top-3.5beta5
	/usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
	/usr/bin/install top.1 /usr/pkg/man/man1/top.1
	strip /usr/pkg/bin/top
	===>  Registering installation for top-3.5beta5
	#


 A.2 Packaging top
 =================

	# make package
	>> Checksum OK for top-3.5beta5.tar.gz.
	===>  Building package for top-3.5beta5
	Creating package top-3.5beta5.tgz
	Registering depends:.
	Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'


======================================================
Appendix B: Layout of the FTP server's package archive
======================================================

Layout for precompiled binary packages on ftp.NetBSD.org:

/pub/NetBSD/packages/
                distfiles/

		# Unpacked pkgsrc trees
		pkgsrc-current -> /pub/NetBSD/NetBSD-current/pkgsrc
		pkgsrc-2003Q4 -> N/A
		pkgsrc-2004Q1/pkgsrc

		# pkgsrc archives
		pkgsrc-current.tar.gz -> ../NetBSD-current/tar_files/pkgsrc.tar.gz
		pkgsrc-2003Q4.tar.gz -> N/A
		pkgsrc-2004Q1.tar.gz -> N/A

		# Per pkgsrc-release/OS-release/arch package archives
		pkgsrc-2003Q4/
			NetBSD-1.6.2/
				i386/
					All/
					archivers/
						foo -> ../All/foo
					...
		pkgsrc-2004Q1/
			NetBSD-1.6.2/
				i386/
					All/
					...
			NetBSD-2.0/
				i386/
					All/
					...
			SunOS-5.9/
				sparc/
					All/
					...
				x86/
					All/
					...

		# Per os-release package archive convenience links
		NetBSD-1.6.2 -> 1.6.2
                1.6.2/
			i386 -> ../pkgsrc-2004Q1/NetBSD-1.6.2/i386
                        m68k/
                                All/
                                archivers/
                                        foo -> ../All/foo
                                ...
                        amiga -> m68k
                        atari -> m68k
                        ...

		2.0 -> NetBSD-2.0	# backward compat, historic
		NetBSD-2.0/
			i386 -> ../pkgsrc-2004Q1/NetBSD-2.0/i386
		SunOS-5.9/
			sparc -> ../pkgsrc-2004Q1/SunOS-5.9/sparc
			x86 -> ../pkgsrc-2004Q1/SunOS-5.9/x86

To create:
 - Run bulk build, see #3.2
 - Upload /usr/pkgsrc/packages to
   ftp://ftp.NetBSD.org/pub/NetBSD/packages/\
	pkgsrc-2004Q1/\				# pkgsrc-branch
	`uname -s`-`uname -r`/			# OS & version
	`uname -p`				# architecture
 - if necessary ln -s `uname -m` `uname -p`	# amiga -> m68k, ...

Disk space needed: unknown.


###########################################################################
# Local Variables:
# mode:				Indented-Text
# fill-column:			75
# sentence-end-double-space:	t
# End:
@


1.362
log
@put a line back where it seems to belong.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.361 2004/10/16 00:36:10 dan Exp $
a837 25
Patch files which are optional and will depend on local site configuration
can be included with names matching the pattern "patches/patch-optional-*".
Their suffixes should match the configuration options.  The selected
optional patch file names should be assigned to the variable
$OPTIONAL_PATCHFILES.  They will not be applied by default.

For example if a package data file needs patching to indicate the default
local printer paper size as specified in the $PAPERSIZE file you can
include patches for all the possible paper sizes other than the one the
package comes configured for by default.  In this case you might have a
patch called "patch-optional-Letter-papersize" and/or another patch called
"patch-optional-A4-papersize".  In your Makefile you would select between
them with the following construct:

   PATCHDIR=	${.CURDIR}/patches
   .if exists(${PATCHDIR}/patch-optional-${PAPERSIZE}-papersize)
	OPTIONAL_PATCHFILES+= ${PATCHDIR}/patch-optional-${PAPERSIZE}-papersize
   .endif

Note that you have to define the value of $PATCHDIR in order to use it in a
".if" statement like this as otherwise it's not defined until too late
during the processing of the Makefile.  You should use a ".if" statement in
order to avoid problems should the configuration item ($PAPERSIZE in this
example) be set to an unexpected value.

@


1.361
log
@add missing w. this is not a political statement.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.360 2004/09/29 11:33:38 hubertf Exp $
a3085 1
	        use on operating systems where pkg_install is not present
d3089 1
@


1.360
log
@Some changes to sort-of sync this with the XML version
(to be committed later):

 * capitalize "NetBSD" (thanks, symka!)
 * "User Interaction" has nothing to do with PLIST - move it somewhere
   more appropriate
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.359 2004/09/19 20:13:26 hubertf Exp $
d2898 1
a2898 1
emulators/vmare-module, fonts/acroread-jpnfont, sysutils/storage-manager,
@


1.359
log
@Update the sudo-instructions so it even works when upgrading sudo
(when there is no sudo binary temporarily!)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.358 2004/09/15 20:18:26 minskim Exp $
d83 1
a83 1
   archive on ftp.netbsd.org.
d127 1
a127 1
Precompiled packages are stored on ftp.netbsd.org and its mirrors in the
d152 1
a152 1
	# pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.tgz
d197 1
a197 1
from ftp://ftp.netbsd.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz and
d207 1
a207 1
your system, it can be found as precompiled binary on ftp.netbsd.org.
d210 1
a210 1
	% setenv CVSROOT anoncvs@@anoncvs.netbsd.org:/cvsroot
d325 1
a325 1
ftp.netbsd.org. Any flags that should be added to pkg_add(8) can be put
d555 1
a555 1
ftp.netbsd.org, make sure you are using the default X version for your
d578 1
a578 1
   cvs -d cvs.netbsd.org:/cvsroot co pkgsrc
a1092 21
 5.5 User Interaction
 ====================

Occasionally, packages require interaction from the user, and this can be
in a number of ways:

+ help in fetching the distfiles
+ help to configure the package before it is built
+ help during the build process
+ help during the installation of a package

The INTERACTIVE_STAGE definition is provided, to notify the pkgsrc mechanism
of an interactive stage which will be needed, and this should be set in the
package's Makefile. e.g.

INTERACTIVE_STAGE= build

Multiple interactive stages can be specified:

INTERACTIVE_STAGE= configure install

d1333 23
a1355 1
 6.6 Feedback to the author
d1503 1
a1503 1
   patches with some lines of fuzz. Please fix (regen) the patches
d1505 1
a1505 1
   patches that apply cleanly may end up being applied in the wrong
d2366 1
a2366 1
the distfiles on ftp.netbsd.org and the one on ftp.freebsd.org contains
d2456 1
a2456 1
	% echo subscribe tech-pkg | mail majordomo@@netbsd.org
d2545 1
a2545 1
ignored may not be uploaded to ftp.netbsd.org by developers and should not be
d2630 1
a2630 1
old distfile from ftp.netbsd.org's /pub/NetBSD/packages/distfiles directory.
d2751 1
a2751 1
	ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities
d2788 1
a2788 1
on ftp.netbsd.org by localsrc/security/advisories/Makefile.  In addition,
d2907 1
a2907 1
http://www.netbsd.org/Documentation/software/packages.html#bootstrap
d3049 1
d3124 1
a3124 1
http://mail-index.netbsd.org/tech-pkg/2003/09/27/0023.html
d3458 1
a3458 1
www.netbsd.org and other sites. Additionally, check the pkgsrc/doc/TODO
d3500 1
a3500 1
	  cvs -d user@@cvs.netbsd.org:/cvsroot export -D today pkgsrc/category/package
d3806 1
a3806 1
Layout for precompiled binary packages on ftp.netbsd.org:
d3869 1
a3869 1
   ftp://ftp.netbsd.org/pub/NetBSD/packages/\
@


1.358
log
@patters -> patterns
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.357 2004/09/10 10:53:13 sketch Exp $
d3017 1
d3019 1
@


1.357
log
@Correct the location of Solaris packages.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.356 2004/09/09 12:25:27 hubertf Exp $
d3338 1
a3338 1
The PRINT_PLIST_AWK variable takes a set of AWK patters and actions that
@


1.356
log
@xpkgwedge is now the default (3.2.1.1)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.355 2004/09/03 17:22:42 reed Exp $
d3834 1
a3834 1
			Solaris-9/
d3858 3
a3860 3
		Solaris-9/
			sparc -> ../pkgsrc-2004Q1/Solaris-9/sparc
			x86 -> ../pkgsrc-2004Q1/Solaris-9/x86
@


1.355
log
@Added notes to submit pullups (for stable branch) for security
issues.

TODO: reorganize Packages.txt because it has a lot of repeated information.

TODO: explain stable branches and how to use.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.354 2004/08/31 13:51:23 jmmv Exp $
a424 4
If you wish to use xpkgwedge for the entire build, then add:

    BULK_PREREQ+=           pkgtools/xpkgwedge

d429 1
@


1.354
log
@New section: 11.49 Packages installing extensions to the MIME database.
It documents the new databases/shared-mime-info/mimedb.mk file.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.353 2004/08/31 00:14:51 rh Exp $
d2552 2
a2553 1
setting RECOMMENDED (see section 11.21 for more information).
d2794 2
a2795 1
buildlink3.mk files and BUILDLINK_* definitions.
@


1.353
log
@Fix section references that were overlooked when section 10 became
section 11
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.352 2004/08/22 19:42:10 jlam Exp $
d3372 24
@


1.352
log
@Match documentation to reality to reflect recent change in semantics for
PKG_DEFAULT_OPTIONS.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.351 2004/08/12 10:07:28 jlam Exp $
d1990 1
a1990 1
dependencies.  See section 10 for more information about dependencies on
d2552 1
a2552 1
setting RECOMMENDED (see section 10.21 for more information).
d3143 1
a3143 1
    as they will be handled automatically.  See section 10.27 for more
d3333 1
a3333 1
If you have used any of the *-dirs packages, as explained in 10.45, you
@


1.351
log
@Note why USE_BUILTIN.<pkg> may be "yes" even if IS_BUILTIN.<pkg> is "no".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.350 2004/08/07 10:15:47 wiz Exp $
d2141 5
a2145 9
.if defined(USE_OPENLDAP) || defined(USE_SASL2)
.  if !defined(PKG_OPTIONS.wibble)
.    if defined(USE_OPENLDAP) && !empty(USE_OPENLDAP:M[yY][eE][sS])
PKG_OPTIONS.wibble+=	ldap
.    endif
.    if defined(USE_SASL2) && !empty(USE_SASL2:M[yY][eE][sS])
PKG_OPTIONS.wibble+=	sasl
.    endif
.  endif
a2148 1
PKG_OPTIONS.wibble?=	sasl			# package-specific default
d2150 6
@


1.350
log
@Fix typos.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.349 2004/08/06 15:27:21 jlam Exp $
d2064 1
a2064 1
functionality to <pkg>; it should only be "yes" if the actual package
d2078 4
a2081 1
value by the end of the builtin.mk file.
@


1.349
log
@Clear up a common misconception about buildlink3.  The reality is that
everything in /usr/include and /usr/lib (system header and library
paths) is always considered part of the package build environment;
buildlink3 only isolates package builds from everything outside of
those system paths.  As a consequence of this, LOCALBASE == "/usr"
effectively makes buildlink3 do nothing.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.348 2004/08/05 20:55:11 jlam Exp $
d2118 1
a2118 1
a set of global default options apply .
d2224 1
a2224 1
 11 Debugging
@


1.348
log
@Document how to use bsd.options.mk.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.347 2004/08/04 16:14:34 jschauma Exp $
d1786 3
a1788 1
installed.
@


1.347
log
@Mention that hier(7) helps with the layout of files within PREFIX
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.345 2004/07/30 20:52:44 jlam Exp $
d2108 116
a2223 2
 9 Debugging
 ===========
d2294 1
a2294 1
 10 FAQs & features of the package system
d2297 1
a2297 1
 10.1 Packages using GNU autoconf
d2309 1
a2309 1
 10.2 Other distrib methods than .tar.gz
d2321 1
a2321 1
 10.3 Packages not creating their own subdirectory
d2337 1
a2337 1
 10.4 Custom configuration process
d2348 1
a2348 1
 10.5 Packages not building in their DISTNAME directory
d2357 1
a2357 1
 10.6 How to fetch all distfiles at once
d2394 1
a2394 1
 10.7 How to fetch files from behind a firewall
d2408 1
a2408 1
 10.8 If your patch contains an RCS ID
d2414 1
a2414 1
 10.9 How to pull in variables from /etc/mk.conf
d2446 1
a2446 1
 10.10 Is there a mailing list for pkg-related discussion?
d2455 1
a2455 1
 10.11 How do i tell "make fetch" to do passive FTP?
d2475 1
a2475 1
 10.12 Dependencies on other packages
d2582 1
a2582 1
 10.13 Conflicts with other packages
d2606 1
a2606 1
 10.14 Software which has a WWW Home Page
d2616 1
a2616 1
 10.15 How to handle modified distfiles with the 'old' name
d2631 1
a2631 1
 10.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
d2643 1
a2643 1
 10.17 How to handle incrementing versions when fixing an existing package
d2664 1
a2664 1
 10.18 "Could not find bsd.own.mk" - what's wrong?
d2676 1
a2676 1
 10.19 Restricted packages
d2713 1
a2713 1
 10.20 Packages using (n)curses
d2729 1
a2729 1
 10.21 Automated security check
d2790 1
a2790 1
 10.22 What's the proper way to create an account from a package?
d2823 1
a2823 1
 10.23 How to handle compiler bugs
d2837 1
a2837 1
 10.24 Packages providing info files
d2878 1
a2878 1
 10.25 Packages whose distfiles aren't available for plain downloading
d2896 1
a2896 1
 10.26 Using pkgsrc on non-NetBSD (Darwin, FreeBSD, IRIX, Linux, OpenBSD, Solaris)
d2907 1
a2907 1
 10.27 Configuration files handling and placement
d2973 1
a2973 1
 10.28 Packages providing login shells
d2992 1
a2992 1
 10.29 Packages providing locale catalogues
d3002 1
a3002 1
 10.30 Using 'sudo' with pkgsrc
d3015 1
a3015 1
 10.31 Packages that cannot or should not be built
d3032 1
a3032 1
 10.32 Packages which should not be deleted, once installed
d3041 1
a3041 1
 10.33 Packages containing perl scripts
d3049 1
a3049 1
 10.34 Packages with hardcoded paths to other interpreters
d3064 1
a3064 1
 10.35 Utilities for package management (pkgtools)
d3110 1
a3110 1
 10.36 How to use pkgsrc as non-root?
d3119 1
a3119 1
 10.37 Packages installing GConf2 data files
d3149 1
a3149 1
 10.38 Packages installing scrollkeeper data files
d3167 1
a3167 1
 10.39 Packages installing X11 fonts
d3185 1
a3185 1
 10.40 Packages installing GTK2 modules
d3209 1
a3209 1
 10.41 Packages installing SGML or XML data
d3237 1
a3237 1
 10.42 Packages using intltool
d3250 2
a3251 2
 10.43 How can I install/use XFree86 from pkgsrc?
 ========================================
d3259 2
a3260 2
 10.44 How can I install/use X.org from pkgsrc?
 ======================================
d3268 1
a3268 1
 10.45 Where's the pkgviews documentation?
d3275 1
a3275 1
 10.46 How do I handle common shared directories?
d3324 1
a3324 1
 10.47 How can I tweak 'make print-PLIST' output?
d3348 1
a3348 1
 10.48 Packages that install score files
d3366 1
a3366 1
 11 Submitting & Committing
d3369 1
a3369 1
 11.1 Submitting your packages
d3399 1
a3399 1
 11.2 Committing: Importing the package into CVS
d3434 1
a3434 1
 11.3 Updating a Package to a Newer Version
d3461 1
a3461 1
 11.4 Moving a Package in pkgsrc
d3484 1
a3484 1
 12 A simple example of a package: bison
d3493 1
a3493 1
 12.1 files
d3499 1
a3499 1
 12.1.1 Makefile
d3517 1
a3517 1
 12.1.2 DESCR
d3525 1
a3525 1
 12.1.3 PLIST
d3541 1
a3541 1
 12.1.4 Checking a package "pkglint"
d3561 1
a3561 1
 12.2 Steps for building, installing, packaging
d3571 1
a3571 2
Create Makefile, DESCR and PLIST as in section 11.1,
then continue with fetching the distfile:
@


1.346
log
@Document use of SETGIDGAME and the other GAME variables.
(Suggested by wiz@@)
@
text
@d1455 4
@


1.345
log
@Update documentation for the current state of buildlink3.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.344 2004/07/30 07:48:56 xtraeme Exp $
d3230 18
@


1.344
log
@Add a new variable to specify the installation prefix for
X11 packages (currently XFree86 and xorg), X11ROOT_PREFIX.

Defaults:

xorg: X11ROOT_PREFIX = xorg.
XFree86: X11ROOT_PREFIX = XFree86.

Otherwise it's undefined.

With this modification we don't have to specify X11BASE anymore,
because it's assigned automatically via bsd.pkg.defaults.mk.

If you want to change the defaults, specify X11ROOT_PREFIX in mk.conf.

Update Packages.txt now that we don't need X11BASE.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.343 2004/07/29 06:40:35 xtraeme Exp $
d1265 1
a1265 1
include the libtool buildlink2.mk (and set USE_BUILDLINK2 to YES).
d1763 1
a1763 1
 8 buildlink2 methodology
d1766 1
a1766 1
"buildlink2" is a pkgsrc framework that controls what headers and libraries
d1775 4
a1778 1
     into references into ${BUILDLINK_DIR}.
d1782 1
a1782 3
installed.  Please refer to pkgsrc/mk/buildlink2/buildlink2.txt for some
FAQs and answers regarding buildlink2, and to pkgsrc/mk/buildlink2/README
for a description of how buildlink2 is implemented in pkgsrc.
d1785 1
a1785 1
 8.1 Converting packages to use buildlink2
d1788 21
a1808 4
The process of converting packages to use the buildlink2 framework is
fairly straightforward.  The package Makefile must define USE_BUILDLINK2.
If a dependency on a particular package, e.g.  foo, is required for its
libraries and headers, then we replace:
d1812 1
a1812 1
	.include "../../category/foo/buildlink2.mk"
d1814 1
a1814 1
There are several buildlink2.mk files in pkgsrc/mk that handle special
d1817 8
a1824 1
 * motif.buildlink2.mk checks for a system-provided Motif installation
d1827 1
a1827 1
 * ossaudio.buildlink2.mk defines several variables that may be used by
d1830 1
a1830 1
 * pthread.buildlink2.mk uses the value of PTHREAD_OPTS and checks for
d1833 1
a1833 1
 * xaw.buildlink2.mk uses the value of XAW_TYPE to choose a particular
d1836 1
a1836 1
The comments in those buildlink2.mk files provide a more complete
d1840 1
a1840 1
 8.2 Writing buildlink2.mk files
d1843 259
a2101 2
A simple example of a buildlink2.mk file for a mythical package foo
follows:
a2102 66
	BUILDLINK_PACKAGES+=          foo
	BUILDLINK_PKGBASE.foo=        foo
	BUILDLINK_DEPENDS.foo?=       foo>=1.0
	BUILDLINK_PKGSRCDIR.foo?=     ../../category/foo

	EVAL_PREFIX+=                 BUILDLINK_PREFIX.foo=foo
	BUILDLINK_PREFIX.foo_DEFAULT= ${LOCALBASE}
	BUILDLINK_FILES.foo=          include/foo.h
	BUILDLINK_FILES.foo+=         include/bar.h
	BUILDLINK_FILES.foo+=         lib/libfoo.*

	BUILDLINK_TARGETS+=           foo-buildlink

	foo-buildlink: _BUILDLINK_USE

The first section controls how the dependency on foo is added.  The
dependency is constructed from four parts:

 (1) BUILDLINK_PACKAGES is the global list of packages for which
     dependencies will be added by buildlink2;

 (2) BUILDLINK_DEPENDS.foo is the actual dependency recorded in the
     installed package;

 (3) BUILDLINK_PKGSRCDIR.foo is the location of the foo pkgsrc
     directory;

 (4) BUILDLINK_DEPMETHOD.foo (not shown above) controls whether we use
     BUILD_DEPENDS or DEPENDS to add the foo dependency, where the
     full dependency is added if BUILDLINK_DEPMETHOD.foo contains "full".

The second section controls which files are linked into ${BUILDLINK_DIR}:

 (1) BUILDLINK_PREFIX.foo is the installation prefix of the package which
     we derive by using EVAL_PREFIX;

 (2) BUILDLINK_FILES.foo is a list of files (shell globs allowed) relative
     to the BUILDLINK_PREFIX.foo directory and will be symlinked into
     ${BUILDLINK_DIR};

 (3) BUILDLINK_FILES_CMD.foo (not shown above) is a shell pipeline that
     outputs a list of files relative to the BUILDLINK_PREFIX.foo
     directory and will be symlinked into ${BUILDLINK_DIR}.

The remaining parts create the foo-buildlink target that actually performs
the symlinking and adds the foo-buildlink target to BUILDLINK_TARGETS,
which is the global list of targets to execute at do-buildlink time.

When updating a package be sure to check if the sonames (library
versions) change and adjust the BUILDLINK_DEPENDS.foo to at least
the new package version. For example, if the installed library
changed from libfoo.so.4 to libfoo.so.5 then the BUILDLINK_DEPENDS.foo
needs to be changed so binary packages (made using it) will require
the correct package. It is also important to update the
BUILDLINK_DEPENDS.foo when the API or interface to the included
files change.  In some cases, the packages that depend on this new
version may need their PKGREVISIONs increased and, if they have
buildlink?.mk files, their BUILDLINK_DEPENDS.bar adjusted too. This
is so binary packages will require correct versions (so a new
package built against old library won't be installed with a new
library, for example). Please take careful consideration before
adjusting the BUILDLINK_DEPENDS so it doesn't cause unneeded package
deletions and rebuilds. (In many cases, new versions of packages
work just fine with older dependencies.) See section 10 for more
information about dependencies on other packages, including the
BUILDLINK_RECOMMENDED and RECOMMENDED definitions.
d2363 1
a2363 1
buildlink2.mk (see section 8).
d2601 1
a2601 1
If ../../devel/ncurses/buildlink2.mk is included in a package's Makefile,
d2605 1
d2607 1
d2661 9
a2669 9
Note to package developers: When a vulnerability is found, this should be
noted in localsrc/security/advisories/pkg-vulnerabilities, and after the
commit of that file, it should be copied to both
/pub/NetBSD/packages/distfiles/pkg-vulnerabilities and vulnerabilities 
on ftp.netbsd.org by localsrc/security/advisories/Makefile.  In addition, if
a buildlink2.mk or buildlink3.mk file exists for an affected package, bumping
PKGREVISION and creating a corresponding BUILDLINK_RECOMMENDED.<pkg> entry
should be considered. See section 8 for more information about
writing buildlink?.mk files and BUILDLINK_* definitions.
d2879 3
a2881 3
Makefile template files are fixed and point to the correct locale directories
(which may vary, depending on OS), if necessary.  See also section 5.1 for
details about ${PKGLOCALEDIR}.  This functionality is buildlink2-only.
@


1.343
log
@Update section 10.44, xorg will be installed by default into
${PREFIX}/xorg.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.342 2004/07/29 05:15:31 xtraeme Exp $
a2921 3
    X11BASE=/usr/pkg/X11R6

`LOCALBASE' by default is `/usr/pkg'.
a2930 3
    X11BASE=/usr/pkg/xorg

`LOCALBASE' by default is `/usr/pkg'.
@


1.342
log
@Added section 10.44 "How can I install/use X.org from pkgsrc?".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.341 2004/07/24 01:57:07 hubertf Exp $
d2934 1
a2934 1
    X11BASE=/usr/pkg/X11R6
@


1.341
log
@A few updates WRT patches etc., submitted by Greg Woods in PR 22949
VS: ----------------------------------------------------------------------
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.340 2004/07/04 17:41:58 wiz Exp $
d2914 2
a2915 2
 10.43 How can I use XFree86 from pkgsrc?
 =======================================================
d2919 1
a2919 1
lines into /etc/mk.conf:
d2926 11
d2938 1
a2938 1
 10.44 Where's the pkgviews documentation?
d2945 1
a2945 1
 10.45 How do I handle common shared directories?
d2994 1
a2994 1
 10.46 How can I tweak 'make print-PLIST' output?
@


1.340
log
@Various improvements for previous.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.339 2004/07/04 17:35:41 jmmv Exp $
d714 4
a717 3
specify a subdirectory of that site.  Since these macros may expand to
more than one actual site, you MUST use the following construct to specify
a subdirectory:
d720 1
d837 1
a837 1
will compile and run perfectly on NetBSD. The files are applied
d841 30
a870 5
The patch-?? files should be in "diff -bu" format, and apply without
a fuzz to avoid problems (To force patches to apply with fuzz you
can set PATCH_FUZZ_FACTOR=-F2).  Furthermore, do not put changes
for more than one file into a single patch-file, as this will make
future modifications more difficult.
d897 3
d1169 1
a1169 1
	${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor
d1178 23
d1241 3
a1243 2
7. In your PLIST, include all of the .a, .la, and so, .so.major and
   .so.major.minor files (this is a change from the previous behaviour).
d1318 3
d1983 2
a1984 2
	EXTRACT_SUFX=   .msg.gz
	EXTRACT_CMD=            zcat
d2229 2
a2230 2
	if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
		cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract;              \
d2303 1
a2303 1
(nroff, ...). It is recommended to do that.
d3489 1
a3489 1
# mode:				Text
d3491 1
a3491 1
# sentence-end-double-space:	nil
@


1.339
log
@+ 10.45 How do I handle common shared directories?
+ 10.46 How can I tweak 'make print-PLIST' output?
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.338 2004/06/06 12:46:37 grant Exp $
d2881 3
a2883 3
packages install files.  These directories are problematic because you
have to add special tricks in the PLIST to conditionally remove them,
or have some centralized package handle them.
d2885 3
a2887 3
Within pkgsrc, you'll find both approaches mixed.  If a directory is shared
by few unrelated packages, it's often not worth to add an extra package to
remove it.  Therefore, one simply does:
d2889 1
a2889 1
    @@unexec ${RMDIR} %D/path/to/shared/package 2>/dev/null || ${TRUE}
d2891 1
a2891 1
in the PLISTs of all packages affected, instead of the regular "@@dirrm" line.
d2897 1
a2897 1
   from it.  For example, see textproc/scrollkeeper, which removes the
d2918 1
a2918 1
After regenerating the PLIST, using 'make print-PLIST', you should get the
d2923 1
a2923 1
(specially, mk/dirs.mk) will take care of it.
d2930 1
a2930 1
may have noticed that 'make print-PLIST' outputs a set of @@comment's,
@


1.338
log
@s/has no effect expect/has no effect except/ ..
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.337 2004/05/02 10:37:48 hubertf Exp $
d2877 73
@


1.337
log
@Add 10.44 Where's the pkgviews documentation?

XXX Packages.txt needs a rewrite (at least when pkgsrc finally gets
XXX out of a state of constant movement
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.336 2004/04/19 17:20:23 hubertf Exp $
d2480 1
a2480 1
The script overriding install-info has no effect expect the logging of a
@


1.336
log
@Update Appendix B for new ftp server layout
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.335 2004/04/08 17:17:16 reed Exp $
d2856 1
d2869 8
@


1.335
log
@Add some notes about the BUILDLINK_DEPENDS definition.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.334 2004/04/08 09:38:39 xtraeme Exp $
a3278 1
                README
d3280 40
a3319 7
		pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc
                1.5/
                        i386/
                                All/
                                archivers/
                                        foo -> ../All/foo
                                ...
d3329 6
d3337 2
a3338 2
 - cd /usr/pkgsrc ; make install ; make package
 - upload /usr/pkgsrc/packages to
d3340 4
a3343 2
    `uname -r | sed 's@@\.\([0-9]*\)[\._].*@@\.\1@@'`/`uname -p`
 - if necessary ln -s `uname -m` `uname -p`
a3346 10
Packages for a release version of NetBSD should be uploaded to the
directory major.minor corresponding to the appropriate release.  Packages
for NetBSD with versions such as "1.5.1" should be uploaded to the "1.5"
directory, stripping the tiny number off the directory name.  For packages
that need to be tightly coupled with the OS Version, such as LKM's, you
may create a major.minor.tiny release directory, and place those packages
therein.  Such packages should be marked with the variable
"OSVERSION_SPECIFIC=yes" to mark them in some way for binary package
builders.

@


1.334
log
@New sub-section: 10.43 How can I use XFree86 from pkgsrc?
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.333 2004/04/07 22:57:16 dmcmahill Exp $
d1812 18
d2393 2
a2394 1
should be considered.
@


1.333
log
@document how to do a bulk build of a subset of pkgsrc
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.332 2004/02/18 18:06:24 jlam Exp $
d2837 11
@


1.332
log
@Document "mipspro-ucode".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.331 2004/02/17 03:24:28 snj Exp $
d601 21
@


1.332.2.1
log
@Pull up documentation fix to the pkgsrc-2004Q1 branch.

Requested by dmcmahill in ticket pkgsrc-15.

"document how to do a bulk build of a subset of pkgsrc".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.333 2004/04/07 22:57:16 dmcmahill Exp $
a600 21
 3.2.7 Building a partial set of packages
 ========================================

In addition to building a complete set of all packages in pkgsrc, the
pkgsrc/mk/bulk/build script may be used to build a subset of the
packages contained in pkgsrc.  By setting defining SPECIFIC_PKGS
in /etc/mk.conf, the variables 

	SITE_SPECIFIC_PKGS
	HOST_SPECIFIC_PKGS
	GROUP_SPECIFIC_PKGS
	USER_SPECIFIC_PKGS

will define the set of packages which should be built.  The bulk build
code will also include any packages which are needed as dependencies
for the explicitly listed packages.

One use is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
periodically to have a complete set of the binary packages needed for
your site available without the overhead of building extra packages
that are not needed.
@


1.332.2.2
log
@Pull up a documentation fix to the pkgsrc-2004Q1 branch.

Requested by hubertf in ticket pkgsrc-26.

"Update Appendix B for new ftp server layout"
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.332.2.1 2004/04/27 07:56:38 agc Exp $
d3249 1
d3251 7
a3257 40

		# Unpacked pkgsrc trees
		pkgsrc-current -> /pub/NetBSD/NetBSD-current/pkgsrc
		pkgsrc-2003Q4 -> N/A
		pkgsrc-2004Q1/pkgsrc

		# pkgsrc archives
		pkgsrc-current.tar.gz -> ../NetBSD-current/tar_files/pkgsrc.tar.gz
		pkgsrc-2003Q4.tar.gz -> N/A
		pkgsrc-2004Q1.tar.gz -> N/A

		# Per pkgsrc-release/OS-release/arch package archives
		pkgsrc-2003Q4/
			NetBSD-1.6.2/
				i386/
					All/
					archivers/
						foo -> ../All/foo
					...
		pkgsrc-2004Q1/
			NetBSD-1.6.2/
				i386/
					All/
					...
			NetBSD-2.0/
				i386/
					All/
					...
			Solaris-9/
				sparc/
					All/
					...
				x86/
					All/
					...

		# Per os-release package archive convenience links
		NetBSD-1.6.2 -> 1.6.2
                1.6.2/
			i386 -> ../pkgsrc-2004Q1/NetBSD-1.6.2/i386
a3266 6
		2.0 -> NetBSD-2.0	# backward compat, historic
		NetBSD-2.0/
			i386 -> ../pkgsrc-2004Q1/NetBSD-2.0/i386
		Solaris-9/
			sparc -> ../pkgsrc-2004Q1/Solaris-9/sparc
			x86 -> ../pkgsrc-2004Q1/Solaris-9/x86
d3269 2
a3270 2
 - Run bulk build, see #3.2
 - Upload /usr/pkgsrc/packages to
d3272 2
a3273 4
	pkgsrc-2004Q1/\				# pkgsrc-branch
	`uname -s`-`uname -r`/			# OS & version
	`uname -p`				# architecture
 - if necessary ln -s `uname -m` `uname -p`	# amiga -> m68k, ...
d3277 10
@


1.331
log
@Change info regarding LIBTOOL_OVERRIDE.  Most packages need not define
this variable, since, as of revision 1.1404 of mk/bsd.pkg.mk,
LIBTOOL_OVERRIDE is set to "libtool */libtool */*/libtool", which will
suffice in most cases.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.330 2004/02/16 18:44:32 snj Exp $
d351 2
a352 1
	mipspro		Silicon Graphics, Inc. MIPSpro
@


1.330
log
@Some minor English fixes.

Change step 3 in section 10.38 to indicate that "share/omf" _should_ be
removed from PLIST (previously it said to not remove it).

XML_CATALOGS should hold XML catalogs, not SGML.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.329 2004/02/16 18:11:59 jmmv Exp $
d1173 10
a1182 5
Add USE_LIBTOOL=yes and LIBTOOL_OVERRIDE=${WRKSRC}/libtool to the
package Makefile as the quick way to bypass the pkg's own libtool.
For older libtool using packages, libtool is made by ltconfig script
during the do-configure step; you can check the libtool script
location by doing "make configure; find work*/ -name libtool".
@


1.329
log
@Very beleatedly add documentation for the following items:
- 10.37 Packages installing GConf2 data files
- 10.38 Packages installing scrollkeeper data files
- 10.39 Packages installing X11 fonts
- 10.40 Packages installing GTK2 modules
- 10.41 Packages installing SGML or XML data
- 10.42 Packages using intltool
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.328 2004/02/12 07:08:21 minskim Exp $
d2684 1
a2684 1
to do some extra steps to make sure they get registered in the database:
d2703 1
a2703 1
    any directory in them.
d2707 1
a2707 1
    any directory in them.
d2713 1
a2713 1
If a package installs .omf files, used by scrollkeeper, you need to do some
d2724 2
a2725 2
 3) Do not remove the share/omf directory from the PLIST.  This will be
    handled by scrollkeeper.
d2784 1
a2784 1
 3) Set XML_CATALOGS to the full path of any SGML catalogs installed by
d2789 1
a2789 1
    information (concretely, arguments recognized by the 'add' action).
d2794 1
a2794 1
    information (concretely, arguments recognized by the 'add' action).
@


1.328
log
@Replace netbsd with NetBSD in email addresses for MAINTAINER.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.327 2004/02/01 01:56:28 jlam Exp $
d2609 1
d2624 1
d2680 131
@


1.327
log
@Document PKGSRC_COMPILER.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.326 2004/02/01 00:29:01 snj Exp $
d770 1
a770 1
   tech-pkg@@netbsd.org.
d2013 1
a2013 1
Yes. We are using tech-pkg@@netbsd.org for discussing package related
d2819 1
a2819 1
	MAINTAINER=     thorpej@@netbsd.org
@


1.326
log
@It's "its."  Use a semicolon instead of a comma.  Tweak a sentence for
consistency.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.325 2004/01/27 09:10:26 agc Exp $
d338 27
@


1.325
log
@Add the multimedia category.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.324 2004/01/24 15:32:59 grant Exp $
d1634 1
a1634 1
   package it (and it's depends, if PKG_DEPENDS is set properly, see
d1636 2
a1637 2
   just-installed package and it's required packages are removed,
   preserving free disk space.
@


1.324
log
@replace reference to USE_GMAKE with USE_GNU_TOOLS make.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.323 2004/01/23 23:46:44 wiz Exp $
d715 1
@


1.323
log
@Update USE_NCURSES example with a still missing function.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.322 2004/01/14 07:25:48 wiz Exp $
d1418 3
a1420 3
   USE_GMAKE is set, "make" otherwise.  MAKEFILE is set to "Makefile"
   by default, and ALL_TARGET defaults to "all".  Any of these
   variables can be set to change the default build process.
@


1.322
log
@Fix typo.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.321 2004/01/14 06:57:45 rh Exp $
d2259 1
a2259 1
	USE_NCURSES=	# redrawwin
@


1.321
log
@  Add *RECOMMENDED variables as discussed on tech-pkg@@ to allow for a more
fine-grained distinction between required versions of pre-requisites
(DEPENDS) and versions that are recommended for security or library ABI
consistency reasons (RECOMMENDED).

  The contents of ${RECOMMENDED} are added to DEPENDS unless
IGNORE_RECOMMENDED is set to YES, in which case a warning will be printed
and IGNORE_RECOMMENDED will be added to BUILD_DEFS.

  Add a corresponding BUILDLINK_RECOMMENDED.<pkg> variable for use with
buildlink2 and buildlink3.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.320 2003/12/14 21:47:32 kristerw Exp $
d2069 1
a2069 1
Such recommendations can be expressed using RECOMENDED:
@


1.320
log
@Correct path in pre-build.local example.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.319 2003/11/19 22:31:47 hubertf Exp $
d2056 28
d2317 4
a2320 1
on ftp.netbsd.org by localsrc/security/advisories/Makefile.
@


1.319
log
@3.2.6 Setting up a sandbox for chroot'ed builds:
Remove redundant paragraphs, and remind creating a user account if
$CVS_USER is set in build.conf. (We should probably check for a few
things there...)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.318 2003/11/12 21:16:39 wiz Exp $
d424 1
a424 1
		> pkgsrc/games/crafty-book-enormous/$BROKENF
@


1.318
log
@Mention pkgsrc-wip in the "submitting packages" section.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.317 2003/10/29 19:55:19 reed Exp $
d527 6
a532 3
After extracting all the sets from a NetBSD installation or doing a
"make distribution DESTDIR=/usr/sandbox" in src/etc, make sure the following
items are present and properly configured:
d534 1
a534 1
 * kernel:
d554 2
d559 2
a560 13

!!! Don't forget to install X !!!
If you are a developer and want to upload the resulting binary packages
to ftp.netbsd.org, make sure you are using the default X version for your
architecture and release (up to 1.6, that is 3.3.6 for all architectures).

Next thing you will want to is make sure /usr/sandbox/usr/pkgsrc contains a
fresh checkout of pkgsrc (e.g. from anoncvs). Do not mount/link this to the
copy of your pkgsrc tree you do development in, as this will likely cause
problems! Adjust .../pkgsrc/packages and .../pkgsrc/distfiles to point to
some places outside the sandbox if you want to make the files public.

Then, configure .../pkgsrc/mk/bulk/build.conf to fit your needs!
@


1.317
log
@Add note about SHLIBTOOL_OVERRIDE.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.316 2003/10/10 01:17:55 reed Exp $
d2651 5
@


1.316
log
@Note that print-PLIST will not descend into different filesystems.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.315 2003/10/04 23:44:29 wiz Exp $
d1156 3
@


1.315
log
@pkglocate and templates are not categories.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.314 2003/10/04 19:59:38 agc Exp $
d1623 2
a1624 1
   An attempt is made to care for shared libs etc., but it is STRONGLY
@


1.314
log
@Correct some of the English text.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.313 2003/10/04 19:34:46 agc Exp $
a724 1
	pkglocate
a729 1
	templates
@


1.313
log
@Add a geography category, in anticipatino of a number of pending packages.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.312 2003/10/03 15:32:55 hubertf Exp $
d2347 2
a2348 1
commands. Each info files:
d2357 1
a2357 1
INSTALL and DEINSTALL scripts will be generated for handling registration
d2359 1
a2359 1
The command install-info used for the info files registration is either
d2363 7
a2369 7
A package which need the makeinfo command at build time must define
the variable USE_MAKEINFO in its Makefile. If a minimum version of the
makeinfo command is needed it should be noted with the TEXINFO_REQD variable
in the package Makefile. By default a minimum version of 3.12 is required.
If the system does not provide a makeinfo command or if it does not match
the required minimum a build dependency on the devel/gtexinfo package is
added.
d2372 1
a2372 1
should not use the install-info as the registration of info files
d2379 1
a2379 1
The script overriding install-info as no effect expect the logging of a
@


1.312
log
@Update space usage for bulk builds
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.311 2003/09/28 20:22:08 hubertf Exp $
d695 42
a736 8
       archivers  audio      benchmarks   biology       cad    
       chat       comms      converters   cross         databases
       devel      editors    emulators    finance       fonts
       games      graphics   ham          japanese      lang
       mail       math       mbone        misc          net
       news       parallel   print        security      shells
       sysutils   textproc   time         wm            www
       x11
@


1.311
log
@How to use pkgsrc as non-root. Thanks to Jeremy C. Reed!
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.310 2003/09/23 01:27:53 yyamano Exp $
d502 1
a502 1
1.5/i386:
d504 3
a506 3
 * Distfiles:                         1500MB (NFS ok)
 * Full set of all binaries:          1000MB (NFS ok)
 * Temp space for compiling:          1500MB (local disk recommended)
@


1.310
log
@vulnerabilities -> pkg-vulnerabilities
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.309 2003/09/22 13:18:31 wiz Exp $
d2577 9
@


1.309
log
@Mention doc/TODO, prompted by Kimmo Suominen.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.308 2003/09/17 19:04:21 jmmv Exp $
d2222 1
a2222 1
	ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/vulnerabilities
d2257 3
a2259 2
commit of that file, it should be copied to
/pub/NetBSD/packages/distfiles/vulnerabilities on ftp.netbsd.org.
@


1.308
log
@Document USE_X11 and explain when X11 packages should be placed under LOCALBASE
and when under X11BASE.  Closes PR pkg/21759.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.307 2003/08/30 22:01:36 seb Exp $
d2632 3
a2634 1
www.netbsd.org and other sites.
@


1.307
log
@Sync texinfo section with reality.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.306 2003/08/11 14:17:11 wiz Exp $
d1270 16
a1285 5
   X11BASE or LOCALBASE. To install X11 packages in LOCALBASE, simply
   install the xpkgwedge package (pkgsrc/pkgtools/xpkgwedge).
   If you need to find includes or libraries installed by a pkg that has
   USE_IMAKE  or USE_X11BASE in its pkg Makefile, you need to use _both_
   ${X11BASE} and ${LOCALBASE}.
@


1.306
log
@Add 10.35: Utilities for package management (pkgtools).
From Greg Troxel via tech-pkg, slight changes by me.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.305 2003/08/09 10:25:43 seb Exp $
d2324 12
a2335 12
The installation process of the software provided by the package should not
use the install-info as the registration of info files
is the task of the package INSTALL SCRIPT, and it must use
the right makeinfo command.

If the package use buildlink2 framework no special action should be needed
to achieve this goal.

If the package does not use the buildlink2 framework patch files are likely
to be needed so the build and installation process of the software
picks up the -possibly dummys- values of INSTALL_INFO and MAKEINFO in the
environment.
@


1.305
log
@USE_NEW_TEXINFO is no more.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.304 2003/07/28 08:08:59 seb Exp $
d2520 45
@


1.304
log
@Be a little more relax about install-info invocation during package
installation: it is best to avoid it but it does no harm.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.303 2003/07/14 21:23:51 wiz Exp $
a2335 5

*NOTE* Temporally the variable USE_NEW_TEXINFO must be defined in the
package Makefile. Previously info files, install-info and makeinfo
were handled somewhat differently and the two ways will coexist for
a short period of time until all older packages are updated.
@


1.303
log
@Remove duplicate word. PR 22137
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.302 2003/07/14 15:38:56 martti Exp $
d2324 1
a2324 1
The installation process of the software provided by the package must not
@


1.302
log
@COMMENTs should start with a capital letter
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.301 2003/07/09 16:59:25 agc Exp $
d370 1
a370 1
currently installed packages from your your system! Having a FTP server
@


1.301
log
@Clarify that the pathname of scripts relative to ${WRKSRC} is used in
_REPLACE_FILES.${interpreter}, just as in REPLACE_PERL
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.300 2003/07/09 16:14:51 agc Exp $
d721 1
a721 1
   package.
@


1.300
log
@Document how to enable fixups on scripts in a package which have hardcoded
pathnames to interpreters.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.299 2003/07/04 11:33:54 martti Exp $
d2523 2
a2524 1
_REPLACE_FILES.tcl=	...list of tcl scripts which need to be fixed
@


1.299
log
@The default MAINTAINER is now tech-pkg@@netbsd.org
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.298 2003/06/28 09:58:11 agc Exp $
d2511 14
@


1.298
log
@Resurrect the previous version of Packages.txt until the new docbook-style
documentation has been properly sorted out.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.295 2003/06/19 21:41:13 seb Exp $
d716 1
a716 1
   packages@@netbsd.org.
@


1.297
log
@the full documentation has more up-to-date information than the
README, deprecate it, too.
@
text
@d1 2
a2 1
$NetBSD: Packages.txt,v 1.296 2003/06/23 07:41:45 grant Exp $
d4 4
a7 1
The pkgsrc documentation now lives on the NetBSD web site.
d9 1
a9 2
Full documentation, one file per chapter:
	http://www.NetBSD.org/Documentation/pkgsrc/
a10 2
Full documentation in a single file:
	http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.html
d12 2
a13 2
Full documentation in a single plain-text file:
	http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.txt
d15 2946
a2960 2
pkgsrc.txt and pkgsrc.html are also provided in the top level pkgsrc
directory (this directory).
@


1.296
log
@deprecate Packages.txt.

now point users at documentation on the web and provide a copy of the
single file HTML and plain-text output.
@
text
@d1 1
a1 1
$Id$
@


1.295
log
@Introduce a new framework to handle info files, install-info and
makeinfo commands.

The goal of the new framework is twofold:
        - reduce the number of '@@exec' and '@@unexec' in PLIST by
using INSTALL/DEINSTALL scripts to handle entries addition/removal
Info directory file.
        - achieve lighter dependencies by avoiding unnecessary run-time
dependency on the gtexinfo package and if needed with the help of the
standalone install-info command provided by the recently imported package
pkgtools/pkg_install-info.

A package must be sightly updated to use this new framework and
must define the variable USE_NEW_TEXINFO. This variable will
be removed from the pkgsrc tree when all package would have been
updated.

For details see section 10.24 of Packages.txt, comments in
mk/{texinfo.mk,buildlink2/bsd.buildlink2.mk} and upcoming mail to
<tech-pkg at netbsd dot org>.
@
text
@d1 1
a1 2
# $NetBSD: Packages.txt,v 1.294 2003/06/05 17:32:13 jmmv Exp $
###########################################################################
d3 1
a3 4
			==========================
			   Documentation on the
			   NetBSD Package System
			==========================
d5 2
a6 1
		      Hubert Feyrer, Alistair Crooks
d8 2
d11 2
a12 2
Table of contents:
==================
d14 2
a15 2946
Run this command to produce a table of contents:
 sed '/^.====/{g;p;};h;d' Packages.txt


 0 Intro
 =======

There is a lot of software freely available for Unix based systems, which
usually runs on NetBSD, too, sometimes with some modifications. The NetBSD
packages collection incorporates any such changes necessary to make that
software run on NetBSD, and makes the installation (and re-installation) of
the software package easy by means of a single command.

The NetBSD package system is used to enable such freely available
third-party software to be built easily on NetBSD hosts. Once the software
has been built, it is manipulated with the pkg_* tools so that installation
and de-installation, printing of an inventory of all installed packages and
retrieval of one-line comments or more verbose descriptions are all simple.

Both the NetBSD packages collection and the NetBSD package system are
derived from FreeBSD.


 0.1 Overview
 ============

This document is divided into two parts.  The first, "User's Guide",
describes how one can use one of the packages in the Package
Collection, either by installing a precompiled binary package, or
by building one's copy using the NetBSD package system.  The
second part, "Package Constructor's Guide", explains how to prepare
a package so it can be easily built by other NetBSD users without
knowing about the package's building details.


 0.2 Terminology
 ===============

There has been a lot of talk about "ports", "packages", etc. so far. Here
is a description of all the terminology used within this document:

 * Package:
   A set of files and building instructions that describe what's necessary
   to build a certain piece of software using the NetBSD package
   system. Packages are traditionally stored under /usr/pkgsrc.

 * The NetBSD package system:
   This is the part of the NetBSD operating system handling building
   (compiling), installing, and removing of packages.

 * Distfile:
   This term describes the file or files that are provided by the author
   of the piece of freely available software to distribute his work. All
   the changes necessary to build on NetBSD are reflected in the
   corresponding package. Usually the distfile is in the form of a
   compressed tar-archive, but other types are possible, too. Distfiles
   are stored below /usr/pkgsrc/distfiles.

 * Port:
   This is the term used by FreeBSD people for what we call a package.
   In NetBSD terminology, "port" refers to a different architecture.

 * Precompiled (binary) package:
   A set of binaries built by the NetBSD package system from a distfile
   using the NetBSD package system and stuffed together in a single .tgz
   file so it can be installed on machines of the same machine architecture
   without the need to recompile. Packages are generated in
   /usr/pkgsrc/packages by the NetBSD package system; there is also an
   archive on ftp.netbsd.org.

   Sometimes, this is referred to by the term "package" too,
   especially in the context of precompiled packages.

 * Program:
   The piece of software to be installed which will be constructed from
   all the files in the Distfile by the actions defined in the
   corresponding package.

 * NetBSD RCS IDs:
   Some files in a package contain RCS IDs to reflect which version of
   that file this is (inserted automatically by cvs). These IDs are used
   in several examples within this document, but as this document itself
   is managed by CVS, it can't list the RCS IDs in plaintext. Instead, the
   $s are written as <$>, resulting in <$>NetBSD<$> and <$>Id<$>.


 0.3 Typography
 ==============

Right now this document is written in plain ASCII text, and there's not
much typography applied here. It's being moved to DocBook.

When giving examples for commands, shell prompts are used to show if the
command should/can be issued as root, or if "normal" user privileges are
sufficient. We use a "#" for root's shell prompt, and a "%" for users'
shell prompt, assuming they use the C-shell or tcsh.


====================
Part I: User's Guide
====================

 1 Installing a precompiled binary package
 =========================================

This section describes how to find, retrieve and install a precompiled
binary package that someone else already prepared for your type of machine.


 1.1 Where to get
 ================

Precompiled packages are stored on ftp.netbsd.org and its mirrors in the
directory /pub/NetBSD/packages for anon FTP access. Please pick the right
subdirectory there as indicated by "uname -p". In that directory, there
is a subdirectory for each category plus a subdirectory "All" which includes
the actual binaries in .tgz-files. The category subdirectories use symbolic
links to those files. (This is the same directory layout as in
/usr/pkgsrc/packages).

This same directory layout applies for CDROM distributions, only that the
directory may be rooted somewhere else, probably somewhere below /cdrom.
Please consult your CDROM's documentation for the exact location!


 1.2 How to use
 ==============

If you have the files on a CDROM or downloaded them to your hard disk, you
can install them with the following command (be sure to su to root first):

	# pkg_add /path/to/package.tgz

If you have FTP access and you don't want to download the packages via FTP
prior to installation, you can do this automatically by giving pkg_add an
ftp-URL:

	# pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.tgz

If there is any doubt, the uname utility can be used to determine the
<OS Ver>, and <arch> by running "uname -rp".

Also note that any prerequisite packages needed to run the package in
question will be installed, too, assuming they are present where you install
from.

After you've installed packages, be sure to have /usr/pkg/bin in your $PATH
so you can actually start the just installed program.


 1.3 A word of warning
 =====================

Please pay very careful attention to the warnings expressed in that manual
page about the inherent dangers of installing binary packages which you did
not create yourself, and the security holes that can be introduced onto
your system by indiscriminate adding of such files.


 2 Installing by Building
 ========================

This assumes that the package is already part of the NetBSD package system.
If it is not, then you are advised to read part II of this document,
"Package Constructor's Guide".


 2.1 Requirements
 ================

To build packages from source on a NetBSD system the "comp" and the "text"
distribution sets must be installed. If you want to build X11 related
packages the "xbase" and "xcomp" distribution sets are required, too.


 2.2 Where to get pkgsrc
 =======================

There are three ways to get pkgsrc. Either as a tar file, via SUP, or
via CVS. All three ways are described here.

To get the package source going, you need to get the pkgsrc.tar.gz file
from ftp://ftp.netbsd.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz and
unpack it into /usr.

As an alternative, you can get pkgsrc via the Software Update Protocol,
SUP. To do so, make sure your supfile has a line saying "release=pkgsrc" in
it, see the examples in /usr/share/examples/supfiles, and that the
directory /usr/pkgsrc does exist. Then, simply start "sup -v
/path/to/your/supfile".

To get pkgsrc via CVS, make sure you have cvs installed. If not present on
your system, it can be found as precompiled binary on ftp.netbsd.org.
To do an initial (full) checkout of pkgsrc, do the following steps:

	% setenv CVSROOT anoncvs@@anoncvs.netbsd.org:/cvsroot
	% setenv CVS_RSH ssh
	% cd /usr
	% cvs checkout -P pkgsrc

This will create the "pkgsrc" directory in your /usr, and all the
package source will be stored under /usr/pkgsrc.  To update pkgsrc
after the initial checkout, make sure you have CVS_RSH set as above,
then do:

	% cd /usr/pkgsrc
	% cvs -q update -dP

Please also note that it is possible to have multiple copies of the
pkgsrc hierarchy in use at any one time - all work is done relatively
within the pkgsrc tree.


 2.3 Fetching distfiles
 ======================

There is one gotcha: The distribution file (i.e. the unmodified source)
must exist on your system for the packages system to be able to build it.
If it does not, then ftp(1) is used to fetch the distribution files
automatically.

You can overwrite some of the major distribution sites to fit to sites
that are close to your own.  Have a look at
pkgsrc/mk/bsd.pkg.defaults.mk to find some examples - in particular,
look for the MASTER_SORT, MASTER_SORT_REGEX and INET_COUNTRY
definitions.  This may save some of your bandwidth and time.

You can change these settings either in your shell's environment, or,
if you want to keep the settings, by editing the /etc/mk.conf file,
and adding the definitions there.

If you don't have a permanent Internet connection and you want to know
which files to download, "make fetch-list" will tell you what you'll need.
Put these distfiles into /usr/pkgsrc/distfiles.


 2.4 How to build and install
 ============================

Assuming that the distfile has been fetched (see previous section), become
root and change into the relevant directory. Then you can type

	% make

at the shell prompt to build the various components of the package, and

	# make install

at the shell prompt to install the various components into the correct
places on your system.

Taking the top system utility as an example, we can install it on our
system by building as shown in appendix A.1.

The program is installed under the default root of the packages tree -
/usr/pkg. Should this not conform to your tastes, simply set the LOCALBASE
variable in your environment, and it will use that value as the root of
your packages tree. So, to use /usr/local, set

	LOCALBASE=/usr/local

in your environment.  Please note that you should use a root which is
dedicated to packages and not shared with other programs (ie, do not try
and use LOCALBASE=/usr).  Also, you should not try to add any of your
own files or directories (such as, for example, src, obj, or pkgsrc) below
the LOCALBASE tree.  This is to prevent possible conflicts between programs
and other files installed by the package system and whatever else may have
been installed there.

There is, of course, one exception to this - X11 packages are traditionally
installed in the X11 tree. The definition used to identify the root of the
X11 tree is the X11BASE definition.

It is possible to install X11 packages in the LOCALBASE tree, for
which you must install the xpkgwedge package
(pkgsrc/pkgtools/xpkgwedge) - see section 7.1 for further details.

Some packages look in /etc/mk.conf to alter some configuration options
at build time.  Have a look at pkgsrc/mk/bsd.pkg.defaults.mk to
get an overview of what will be set there by default.  Environment
variables such as LOCALBASE, and X11BASE can be set in /etc/mk.conf to
save having to remember to set them each time you want to use pkgsrc.

Occasionally, people want to "look under the covers" to see what is
going on when a package is building or being installed. This may be
for debugging purposes, or out of simple curiosity. A number of utility
values have been added to help with this.

(1) If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a
huge amount of information will be displayed.  As a worked example,

	make patch PKG_DEBUG_LEVEL=2

will show all the commands that are invoked, up to and including the
"patch stage".

(2) If you want to know the value of a certain make(1) definition, then
the VARNAME definition should be used, in conjunction with the show-var
target. e.g.

	make show-var VARNAME=DISTFILES

will show the expansion of the make(1) variable "DISTFILES".

If you want to de-install and re-install a binary package that you've
created (see next section), that you put into pkgsrc/packages manually or
that's located on a remote FTP server, you can use the the "bin-install"
target. This target will install a binary package - if available - via
pkg_add, and do a "make package" else. The list of remote FTP sites
searched is kept in the variable BINPKG_SITE, which defaults to
ftp.netbsd.org. Any flags that should be added to pkg_add(8) can be put
into BIN_INSTALL_FLAGS. See pkgsrc/mk/bsd.pkg.defaults.mk for more details.

A final word of warning: If you setup a system that has a non-standard
setting for LOCALBASE (or X11BASE, for that matter), be sure to set that
before any packages are installed, as you can not use several directories
for the same purpose. Doing so will result in pkgsrc not being able to
properly detect your installed packages, and fail miserably. Note also that
precompiled binary packages are usually built with the default LOCALBASE of
/usr/pkg, and that you should *not* install any if you use a non-standard
LOCALBASE.


 3 Making precompiled packages
 =============================


 3.1 Packaging a single package
 ==============================

Once you have built and installed the package as mentioned above, you can
build it into a "binary package" - you might want to do this so that you
can use the binaries you have just built on another NetBSD system, or to
provide a simple means for others to use your binary package instead of
wasting CPU time - this is done by changing to the appropriate directory in
the pkgsrc tree, and typing the command

	# make package

at the shell prompt. This will build and install your package (if not
already done), and then construct a binary package out of the results so
that you can use the pkg_* tools to manipulate this. The binary package is
stored under /usr/pkgsrc/packages, it's in the form of a gzipped file at
the present time. See appendix A.2 for a continuation of the above top
example.

Please see the "submitting" section later in this document on how to submit
such a binary package.


 3.2 Doing a bulk build of all packages
 ======================================

If you want to get a full set of precompiled binary packages, this section
describes how to get them. Beware that the bulk build will remove all
currently installed packages from your your system! Having a FTP server
configured either on the machine doing the bulk builds or on a nearby NFS
server can help to make the packages available to everyone. See ftpd(8) for
more information. If you use a remote NFS server's storage, be sure to not
actually compile on NFS storage, as this slows things down a lot.


 3.2.1 Configuration
 ===================

 3.2.1.1 /etc/mk.conf
 ====================

You may want to set things in /etc/mk.conf.  Look at
pkgsrc/mk/bsd.pkg.defaults.mk for details of the default settings.
You will want to make sure that ACCEPTABLE_LICENSES meet your local
policy:

    PACKAGES?=              ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
    WRKOBJDIR?=             /usr/tmp/pkgsrc   # build here instead of in pkgsrc
    BSDSRCDIR=              /usr/src
    BSDXSRCDIR=             /usr/xsrc         # for x11/xservers
    OBJHOSTNAME?=           yes               # use work.`hostname`
    FAILOVER_FETCH=         yes               # insist on the correct checksum
    PKG_DEVELOPER?=         yes
    _ACCEPTABLE=            yes

If you wish to use xpkgwedge for the entire build, then add:

    BULK_PREREQ+=           pkgtools/xpkgwedge

Other packages which must be installed during the bulk build to modify the
build behaviour may be added to the BULK_PREREQ variable.  Note that currently
the only package for which BULK_PREREQ makes sense is xpkgwedge.

 3.2.1.2 build.conf
 ==================

In pkgsrc/mk/bulk, copy ``build.conf-example'' to ``build.conf'' and
edit it, following the comments in that file. This is the config
file that determines where log files are generated after the build,
where to mail the build report, where your pkgsrc is located and
which user to su(8) to to do a 'cvs update'.

 3.2.1.3 pre-build.local
 =======================

It is possible to configure the bulk build to perform certain site
specific tasks at the end of the pre-build stage.  If the file
``pre-build.local'' exists in pkgsrc/mk/bulk it will be executed
(as a sh(1) script) at the end of the usual pre-build stage.  An
example use of pre-build.local is to have the line:

	# echo "I do not have enough disk space to build this pig." \
		> pkgsrc/games/crafty-book-enormous/$BROKENF

to prevent the system from trying to build a particular package
which requires nearly 3 Gb of disk space.
   
 3.2.2 Other environmental considerations
 ========================================

As /usr/pkg will be completely deleted at the start of bulk builds,
make sure your login shell is placed somewhere else. Either drop it into
/usr/local/bin (and adjust your login shell in the password file), or
(re-)install it via pkg_add from /etc/rc.local, so you can login after a
reboot (remember that your current process won't die if the package is
removed, you just can't start any new instances of the shell any more).
Also, if you use a OS version below 1.5 or you still want to use the
pkgsrc version of ssh for some reason, be sure to install ssh before
starting it from rc.local:

	( cd /usr/pkgsrc/security/ssh ; make bulk-install )
	if [ -f	/usr/pkg/etc/rc.d/sshd ]; then
	   /usr/pkg/etc/rc.d/sshd
	fi

Not doing so will result in you being not able to log in via ssh
after the bulk build is finished or if the machine gets rebooted
or crashes. You have been warned! :)


 3.2.3 Operation
 ===============

Make sure you don't need any of the packages still installed.
BEWARE: During the bulk build, ALL packages will be removed!!!
Be sure to remove all other things that might interfere with builds, like
some libs installed in /usr/local, etc. then become root and type:

        # cd /usr/pkgsrc
        # sh mk/bulk/build

If for some reason your last build didn't complete (power failure,
system panic, ...), you can continue it by running:

	# sh mk/bulk/build restart

At the end of the bulk run, you will get a summary via mail, and find
build logs in the directory specified by "FTP" in the "build.conf"
file.


 3.2.4 What it does
 ==================

The bulk builds consist of three steps:

1. pre-build: The script updates your pkgsrc via (anon)cvs, then cleans
	out any broken distfiles, and removes all packages installed.

2. the bulk build: This is basically 'make bulk-package' with an optimised
	order in which packages will be built. Packages that don't require
	other packages will be built first, and packages with many depends
	will be built later.

3. post-build: Generates a report that's placed in the directory specified
	in the build.conf file named ``broken.html'', a short version of
	that report will also be mailed to the build's admin.

During the build, a list of broken packages will be compiled in
/usr/pkgsrc/.broken  (or .../.broken.${MACHINE} if OBJMACHINE is set),
individual build logs of broken builds can be found in the package's
directory. These files are used by the bulk-targets to mark broken builds
to not waste time trying to rebuild them, and they can be used to debug
these broken package builds later.

	
 3.2.5 Disk space requirements
 =============================

Currently, roughly the following requirements are valid for
1.5/i386:

 * Distfiles:                         1500MB (NFS ok)
 * Full set of all binaries:          1000MB (NFS ok)
 * Temp space for compiling:          1500MB (local disk recommended)

For 1.5/alpha:

 * Full set of all binaries:          1300MB (NFS ok)

Note that all pkgs will be de-installed as soon as they are turned into a
binary package, and that work-sources are removed, so there is no huge
demand to disk space. Afterwards, if the package is needed again, it will
be installed via pkg_add instead of building again, so there are no cycles
wasted by recompiling.


 3.2.6 Setting up a sandbox for chroot'ed builds
 ===============================================

If you don't want all the pkgs nuked from a machine (rendering it useless
for anything but pkg compiling), there is the possibility of doing the pkg
bulk build inside a chroot environment.

The first step to do so is setting up a chroot sandbox, e.g. /usr/sandbox.
After extracting all the sets from a NetBSD installation or doing a
"make distribution DESTDIR=/usr/sandbox" in src/etc, make sure the following
items are present and properly configured:

 * kernel:
   cp /netbsd /usr/sandbox
 * /dev/*:
   cd /usr/sandbox/dev ; sh MAKEDEV all
 * /etc/resolv.conf (for security/smtpd and mail):
   cp /etc/resolv.conf /usr/sandbox/etc
 * working(!) mail config (hostname, sendmail.cf):
   cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
 * /etc/localtime (for security/smtpd):
   ln -sf /usr/share/zoneinfo/GMT /usr/sandbox/etc/localtime
 * /usr/src (system sources, for sysutils/aperture, net/ppp-mppe):
   ln -s ../disk1/cvs .
   ln -s cvs/src-1.6 src
   ln -s cvs/pkgsrc .
 * create /var/db/pkg (not part of default install):
   mkdir /usr/sandbox/var/db/pkg
 * create /usr/pkg (not part of default install)
   mkdir /usr/sandbox/usr/pkg
 * checkout pkgsrc from cvs, into /usr/sandbox/usr/pkgsrc
   cvs -d cvs.netbsd.org:/cvsroot co pkgsrc
 * /usr/pkgsrc/packages & .../distfiles (point outside of sandbox)
 * /etc/mk.conf, see 3.2.1.1
 * adjust .../mk/bulk/build.conf

!!! Don't forget to install X !!!
If you are a developer and want to upload the resulting binary packages
to ftp.netbsd.org, make sure you are using the default X version for your
architecture and release (up to 1.6, that is 3.3.6 for all architectures).

Next thing you will want to is make sure /usr/sandbox/usr/pkgsrc contains a
fresh checkout of pkgsrc (e.g. from anoncvs). Do not mount/link this to the
copy of your pkgsrc tree you do development in, as this will likely cause
problems! Adjust .../pkgsrc/packages and .../pkgsrc/distfiles to point to
some places outside the sandbox if you want to make the files public.

Then, configure .../pkgsrc/mk/bulk/build.conf to fit your needs!

When the chroot sandbox is setup, you can start the build with the following
steps:

	# cd /usr/sandbox/usr/pkgsrc
	# sh mk/bulk/do-sandbox-build

This will just jump inside the sandbox and start thrash^Wbuilding.
At the end of the build, mail will be sent with the results of the build.
Created binary pkgs will be in /usr/sandbox/usr/pkgsrc/packages (wherever
that points/mounts to/from).


 3.3 Creating a multiple CD-ROM packages collection
 ==================================================

After your bulk pkgsrc build has completed, you may wish to create a CD-ROM
set of the resulting binary packages to assist in installing packages on
other machines.  The package pkgsrc/pkgtools/cdpack provides a simple tool for
creating the ISO 9660 images.  `cdpack' arranges the packages on the CD-ROM's
in a way that keeps all the dependencies for given package on the same
CD as that package.


 3.3.1 Example of cdpack
 =======================

Complete documentation for cdpack is found in cdpack(1).  The following
short example assumes that the binary packages are left in
/usr/pkgsrc/packages/All and that sufficient disk space exists in /u2
to hold the ISO 9660 images.

        # mkdir /u2/images
        # pkg_add /usr/pkgsrc/packages/All/cdpack
	# cdpack /usr/pkgsrc/packages/All /u2/images

If you wish to include a common set of files (COPYRIGHT, README, etc)
on each CD in the collection, then you need to create a directory which
contains these files.  For example

	# mkdir /tmp/common
	# echo "This is a README" > /tmp/common/README
	# echo "Another file" > /tmp/common/COPYING
	# mkdir /tmp/common/bin
	# echo "#!/bin/sh" > /tmp/common/bin/myscript
	# echo "echo Hello world" >> /tmp/common/bin/myscript
	# chmod 755 /tmp/common/bin/myscript

Now create the images with

	# cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images

and each image will contain "README", "COPYING", and "bin/myscript"
in their root directories.


====================================
Part II: Package Constructor's Guide
====================================

 4 Package components - files, directories and contents
 ======================================================

Whenever you're preparing a package, there are a number of files involved
which are described in the following sections.


 4.1 Makefile
 ============

Building, installation and creation of a binary package are all controlled
by the package's Makefile.

There is a Makefile for each package. This file includes the standard
bsd.pkg.mk file (referenced as "../../mk/bsd.pkg.mk"), which sets all the
definitions and actions necessary for the package to compile and install
itself. The mandatory fields are the DISTNAME which specifies the base name
of the distribution file to be downloaded from the site on the Internet,
MASTER_SITES which specifies that site, CATEGORIES which denotes the
categories into which the package falls, PKGNAME which is the name of the
package, the MAINTAINER name, and the COMMENT variable, which should
contain a one-line description of the package (the package name should not
appear, it will be added automatically). The maintainer variable is there
so that anyone who quibbles with the (always completely correct) decisions
taken by the guy who maintains the port can complain vigorously.

The MASTER_SITES may be set to one of the predefined sites:

	${MASTER_SITE_APACHE}
	${MASTER_SITE_DEBIAN}
	${MASTER_SITE_GNOME}
	${MASTER_SITE_GNU}
	${MASTER_SITE_GNUSTEP}
	${MASTER_SITE_MOZILLA}
	${MASTER_SITE_PERL_CPAN}
	${MASTER_SITE_SOURCEFORGE}
	${MASTER_SITE_SUNSITE}
	${MASTER_SITE_R_CRAN}
	${MASTER_SITE_SUSE}
	${MASTER_SITE_TEX_CTAN}
	${MASTER_SITE_XCONTRIB}
	${MASTER_SITE_XEMACS}

If one of these predefined sites is chosen, you may require the ability to
specify a subdirectory of that site.  Since these macros may expand to
more than one actual site, you MUST use the following construct to specify
a subdirectory:

	${MASTER_SITE_GNU:=subdirectory/name/}

(Note the trailing slash after the subdirectory name.) Use of the deprecated
MASTER_SITE_SUBDIR will not work.

If the package has multiple DISTFILES or multiple PATCHFILES from different
sites, set SITES_foo to a list of URI's where file "foo" may be found. "foo"
includes the suffix, e.g.

	DISTFILES=${DISTNAME}${EXTRACT_SUFX}
	DISTFILES+=foo-file.tar.gz
	SITES_foo-file.tar.gz=http://www.somewhere.com/somehow/ \
			http://www.somewhereelse.com/mirror/somehow/

Note, that the normal default setting of DISTFILES must be made explicit
if you want to add to it (rather than replace it), as you usually would.

Currently the following values are available for CATEGORIES. If more than
one is used, they need to be separated by spaces:

       archivers  audio      benchmarks   biology       cad    
       chat       comms      converters   cross         databases
       devel      editors    emulators    finance       fonts
       games      graphics   ham          japanese      lang
       mail       math       mbone        misc          net
       news       parallel   print        security      shells
       sysutils   textproc   time         wm            www
       x11

See the NetBSD packages(7) manual page for a description of all available
options and variables.

Please pay attention to the following gotchas:

 - Add MANCOMPRESSED (if not already there) if manpages are installed in
   compressed form by the package; see comment in bsd.pkg.mk
 - Replace /usr/local by ${PREFIX} in all files  (see patches below)
 - If the package installs any info files, see the section `Packages providing
   info files' in this document.
 - Adjust MAINTAINER to be either yourself, if you plan to maintain the
   package for future updates, or set it to the default MAINTAINER
   packages@@netbsd.org.
 - If there exists a home page for the software in question, please
   add the variable HOMEPAGE right after MAINTAINER. The value of this
   variable should be the URL for the home page.
 - Please also set the COMMENT variable to a short description of the
   package.


 4.2 distinfo
 ============

Most important, the mandatory message digest, or checksum, of all the
distfiles needed for the package to compile, confirming they match the
original file distributed by the author.  This ensures that the
distfile retrieved from the Internet has not been corrupted during
transfer or altered by a malign force to introduce a security hole.
It is best generated using the "make makesum" command.  The digest
algorithm used was, at one stage, md5, but that was felt lacking
compared to sha1, and so sha1 is now the default algorithm.  The
distfile size is also generated and stored in new distinfo files.
The pkgsrc/pkgtools/digest utility calculates all of the digests
in the distinfo file, and it provides various different algorithms.
At the current time, the algorithms provided are:

	md5, rmd160, sha1, sha256, sha384 and sha512

Some packages have different sets of distfiles on a per architecture
basis. (A good example is pkgsrc/www/navigator). These are kept in the
same distinfo file and care should be taken when upgrading such a
package to ensure distfile information is not lost.

The message digest/checksum for all the official patches found in the
patches/ directory (see section 4.3) for the package is also stored in
the distinfo file.  This is a message digest/checksum of all lines in
the patch file except the NetBSD RCS Id.  This file is generated by
invoking "make makepatchsum".


 4.3 patches/*
 =============

This directory contains files that are used by the patch(1) command to
modify the sources as distributed in the distribution file into a form that
will compile and run perfectly on NetBSD. The files are applied
successively in alphabetic order (as returned by a shell "patches/patch-*"
glob expansion), so patch-aa is applied before patch-ab etc.

The patch-?? files should be in "diff -bu" format, and apply without
a fuzz to avoid problems (To force patches to apply with fuzz you
can set PATCH_FUZZ_FACTOR=-F2).  Furthermore, do not put changes
for more than one file into a single patch-file, as this will make
future modifications more difficult.

Similar, a file should be patched at most once, not several times by
several different patches. If a file needs several patches, they should
be combined into one file.

One important thing to mention is to pay attention that no RCS IDs
get stored in the patch files, as these will cause problems when
later checked into the NetBSD CVS tree. To avoid this, use either
the "-U 2" or "-U 1" option to diff, or let the 'pkgdiff' command
from pkgsrc/pkgtools/pkgdiff help you.

If you don't want to worry about the problems in the last two paragraphs
yourself, use pkgdiff from the pkgsrc/pkgtools/pkgdiff package, which takes
care of any RCS Ids by itself.

For even more automation, we recommend using mkpatches from the same
package to make a whole set of patches. You just have to backup files
before you edit them to "filename.orig", e.g. with "cp -p filename
filename.orig" or, easier, by using pkgvi from the same package. If you
upgrade a package this way, you can easily compare the new set of patches
with the previously existing one with patchdiff.

When you have finished a package, remember to generate the checksums
for the patch files by using the "make makepatchsum" command, see
section 4.2.

If it is desired to store any patches that should not be committed into
pkgsrc, they can be kept outside the pkgsrc tree in the $LOCALPATCHES
directory. The directory tree there is expected to have the same
"category/package" structure as pkgsrc, and patches are expected to be
stored inside these dirs (also known as $LOCALPATCHES/$PKGPATH). For
example if you want to keep a private patch for pkgsrc/graphics/png, keep
it in $LOCALPATCHES/graphics/png/mypatch. All files in the named directory
are expected to be patch files, and they are applied after the "normal"
pkgsrc patches are applied.


 4.4 Other mandatory files
 =========================

 * DESCR:
   A multi-line description of the piece of software.  This should include
   any credits where they are due.  Please bear in mind that others do not
   share your sense of humour (or spelling idiosyncrasies), and that others
   will read everything that you write here.

 * PLIST:
   This file governs the files that are installed on your system: all the
   binaries, manual pages, etc. There are other directives which may be
   entered in this file, to control the creation and deletion of
   directories, and the location of inserted files.


 4.5 Optional files
 ==================

 * INSTALL:
   Shell script invoked twice during pkg_add. First time after package
   extraction and before files are moved in place, the second time after
   the files to install are moved in place. This can be used to do any
   custom procedures not possible with @@exec commands in PLIST. See
   pkg_add(1) and pkg_create(1) for more information.

 * DEINSTALL:
   This script is executed before and after any files are removed.  It is
   this script's responsibility to clean up any additional messy details
   around the package's installation, since all pkg_delete knows is how to
   delete the files created in the original distribution. See pkg_delete(1)
   and pkg_create(1) for more information.

 * MESSAGE:
   Display this file after installation of the package.
   Useful for things like legal notices on almost-free software, etc.
   Please note that you can modify variables in it easily by using
   MESSAGE_SUBST in the package's Makefile:
  
	MESSAGE_SUBST+=  SOMEVAR="somevalue"
	
   replaces
  
	${SOMEVAR}
	
   in MESSAGE with "somevalue" before displaying the message.


 4.6 work/*
 ==========

When you type "make" the distribution files are unpacked into this
directory.  It can be removed by typing

	# make clean

at the shell prompt. Also, this directory is used to keep various
timestamp files.


 4.7 files/*
 ===========

If you have any files that you wish to be placed in the package prior
to configuration or building, you could place these files here and use
a ${CP} command in the pre-configure target to achieve this.
Alternatively, you could simply diff the file against /dev/null and
use the patch mechanism to manage the creation of this file.


 5 PLIST* issues
 ===============

This section addresses some special issues that one needs to pay attention
to when dealing with the PLIST file (or files, see below!).


 5.1 Miscellaneous
 =================

 * NetBSD RCS Id:
   Be sure to add a RCS ID line as the first thing in any PLIST file you
   write:

	@@comment <$>NetBSD<$>

 * ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}:
   Some packages like emacs and perl embed information about which
   architecture they were built on into the pathnames where they install
   their file. To handle this case, PLIST will be preprocessed before
   actually used, and the symbol "${MACHINE_ARCH}" will be replaced by
   what "uname -p" gives. The same is done if the string ${MACHINE_GNU_ARCH}
   is embedded in PLIST somewhere - use this on packages that have GNU
   autoconf created configure scripts.

   Legacy note: There used to be a symbol "<$ARCH>" that was replaced by
   the output of "uname -m", but that's no longer supported and has been
   removed.

 * ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}:
   Some packages want to embed the OS name and version into some paths.
   To do this, use these variables in the PLIST:

      * ${OPSYS} - output of "uname -s"
      * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
      * ${OS_VERSION} - "uname -r"

 * ${PKGLOCALEDIR}:
   Packages that install locale files should list them in the PLIST as
   "${PKGLOCALEDIR}/locale/de/LC_MESSAGES/..." instead of
   "share/locale/de/LC_MESSAGES/...".  This properly handles the fact that
   different OSes expect locale files to be either in "share" or "lib" by
   default.

 * Manpage-compression:
   Manpages should be installed in compressed form if MANZ is set (in
   bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST
   file, the suffix ".gz" is appended/removed automatically for manpages
   according to MANZ and MANCOMPRESSED being set or not, see above for
   details. This modification of the PLIST file is done on a copy of it,
   not PLIST itself.

 * Platform specific and differing PLISTs:
   Some packages decide to install a different set of files based on
   the operating system being used. These differences can be
   automatically handled by using the following files:

        * PLIST.common
        * PLIST.${OPSYS}
        * PLIST.common_end

   If PLIST.${OPSYS} exists, these files are used instead of PLIST. This
   allows packages which behave in this way to be handled gracefully.
   Manually overriding PLIST_SRC for other more exotic uses is also
   possible.

 * Semi-automatic PLIST generation:
   You can use the "make print-PLIST" command to output a PLIST that matches
   any new files since the package was extracted. See below for more
   information on this target.


 5.2 ${PLIST_SRC}
 ================

To use one or more files as source for the PLIST used in generating the
binary package, set the variable PLIST_SRC to the names of that file(s).
The files are later concatenated using cat(1), and order of things is
important.

 5.3 ${PLIST_SUBST}
 ==================

Similar to MESSAGE_SUBST (see above), you can add variables and their
expansions to this variable in the following way:

	   PLIST_SUBST+=    SOMEVAR="somevalue"

which replaces all occurrences of ${SOMEVAR} in the PLIST with "somevalue".
For the values which are replaced by default, please look in bsd.pkg.mk
(and search for PLIST_SUBST).

 5.4 Perl5 modules
 =================

Makefile of packages providing perl5 modules should include the
makefile fragment lang/perl5/module.mk.  It provides a do-configure
target for the standard perl configuration for such modules as well
as various hooks to tune this configuration.  See comments in this
file for details.

Perl5 modules will install into different places depending on the version
of perl used during the build process.  To address this, the NetBSD
packages system will append lines to the PLIST corresponding to the files
listed in the installed .packlist file generated by most perl5 modules.
This is invoked by defining PERL5_PACKLIST to a space-separated list of
paths to packlist files:

	PERL5_PACKLIST=	${PERL5_SITEARCH}/auto/Pg/.packlist

The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent
the three locations in which perl5 modules may be installed, and may be
used by perl5 packages that don't have a packlist.  These three variables
are also substituted for in the PLIST.

 5.5 User Interaction
 ====================

Occasionally, packages require interaction from the user, and this can be
in a number of ways:

+ help in fetching the distfiles
+ help to configure the package before it is built
+ help during the build process
+ help during the installation of a package

The INTERACTIVE_STAGE definition is provided, to notify the pkgsrc mechanism
of an interactive stage which will be needed, and this should be set in the
package's Makefile. e.g.

INTERACTIVE_STAGE= build

Multiple interactive stages can be specified:

INTERACTIVE_STAGE= configure install


 6 Notes on fixes for packages
 =============================

 6.1 CPP defines
 ===============

To port an application to NetBSD, it's usually necessary for the compiler
to be able to judge the system on which it's compiling, and we use
definitions so that the C pre-processor can do this.

To test whether you are working on a 4.4 BSD-derived system, you should use
the BSD definition, which is defined in <sys/param.h> on said systems.

        #include <sys/param.h>

and then you can surround the BSD-specific parts of your port using the
conditional:

	#if (defined(BSD) && BSD >= 199306)
	...
	#endif

Please use the __NetBSD__ definition sparingly - it should only apply to
features of NetBSD that are not present in other 4.4-lite derived BSDs.

 6.2 Shared libraries - libtool
 ==============================

Pkgsrc supports many different machines, with different object formats
like a.out and ELF, and varying abilities to do shared library and
dynamic loading at all. To accompany this, varying commands and options
have to be passed to the compiler, linker etc. to get the Right Thing,
which can be pretty annoying especially if you don't have all the
machines at your hand to test things.  The "libtool" pkg can help
here, as it just "knows" how to build both static and dynamic
libraries from a set of source files, thus being platform
independent.

Here's how to use libtool in a pkg in seven simple steps:

1. Add USE_LIBTOOL= yes to the package Makefile.

2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of
   ${CC}.  You could even add it to the definition of CC, if only
   libraries are being built in a given Makefile.  This one command will
   build both PIC and non-PIC library objects, so you need not have
   separate shared and non-shared library rules.

3. For the linking of the library, remove any "ar", "ranlib", and "ld
   -Bshareable" commands, and use instead:

	${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor

   Note that the library is changed to have a .la extension, and the
   objects are changed to have a .lo extension.  Change OBJS as necessary.
   This automatically creates all of the .a, .so.major.minor, and ELF
   symlinks (if necessary) in the build directory. Be sure to include
   the -version-info especially when major and minor are zero, as libtool
   will otherwise strip off the shared library version.

   The "-release" option will produce different results for a.out and ELF
   (excluding symlinks) in only one case. An ELF library of the form
   libfoo-release.so.x.y will have a symlink of libfoo.so.x.y on an a.out
   platform. This is handled automatically.

   The -rpath argument is the install directory of the library being built.

   PLIST should include all of the .a, .la and so, .so.major and
   .so.major.minor entries.

4. When linking shared object (.so) files, i.e. files that are loaded via
   dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
   them getting version tacked on.

   PLIST gets the foo.so entry.

5. When linking programs that depend on these libraries _before_ they are
   installed, preface the cc or ld line with "${LIBTOOL} --mode=link", and
   it will find the correct libraries (static or shared), but please be
   aware that libtool will not allow you to specify a relative path in -L
   (such as -L../somelib), because it expects you to change that argument
   to be the .la file.  For example:

	${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib

   should be changed to:

	${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la

   and it will DTRT with the libraries.

6. When installing libraries, preface the install or cp command with
   "${LIBTOOL} --mode=install", and change the library name to .la.  For
   example:

	${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib

   This will install the static .a, shared library, any needed symlinks,
   and run "ldconfig."

7. In your PLIST, include all of the .a, .la, and so, .so.major and
   .so.major.minor files (this is a change from the previous behaviour).


 6.3 Using libtool on GNU packages that already support libtool
 ==============================================================

Add USE_LIBTOOL=yes and LIBTOOL_OVERRIDE=${WRKSRC}/libtool to the
package Makefile as the quick way to bypass the pkg's own libtool.
For older libtool using packages, libtool is made by ltconfig script
during the do-configure step; you can check the libtool script
location by doing "make configure; find work*/ -name libtool".

If your package makes use of the platform independent library for loading
dynamic shared objects, that comes with libtool (libltdl), you should
include the libtool buildlink2.mk (and set USE_BUILDLINK2 to YES).

Some packages use libtool incorrectly so that the package may not work or
build in some circumstances. Some common errors are

 * The inclusion of a shared object (-module) as a dependent library in an
   executable or library. This in itself isn't a problem if one of two things
   has been done.

   1. The shared object is named correctly, i.e. libfoo.la and not foo.la

   2. The -dlopen option is used when linking an executable.

 * The use of libltdl without the correct calls to initialisation routines.
   The function lt_dlinit() should be called and the macro
   LTDL_SET_PRELOADED_SYMBOLS included in executables.


 6.4 GNU Autoconf/Automake
 =========================

If a package needs GNU autoconf or automake to be executed to regenerate
the configure script and Makefile.in makefile templates, then they should
be executed in a pre-configure target. Two makefile fragments are provided
in pkgsrc/mk/autoconf.mk and pkgsrc/mk/automake.mk to help dealing with
these tools. See comments in these files for details.

For packages that need only autoconf:

	AUTOCONF_REQD=	2.50	# if default version is not good enough
	...

	pre-configure:
		cd ${WRKSRC}; ${AUTOCONF}

	...
	.include "../../mk/autoconf.mk"

and for packages that need automake and autoconf:

	AUTOMAKE_REQD=	1.7.1	# if default version is not good enough
	...

	pre-configure:
		cd ${WRKSRC};						\
		${ACLOCAL};						\
		${AUTOHEADER};						\
		${AUTOMAKE} -a --foreign -i;				\
		${AUTOCONF}

	...
	.include "../mk/automake.mk"

There are times when the configure process makes additional changes to the
generated files, which then causes the build process to try to re-execute
the automake sequence.  This is prevented by touching various files in
the configure stage. If this causes problems with your package you can set
AUTOMAKE_OVERRIDE to NO in the package Makefile.


 6.5 Package configuration files
 ===============================

Packages should be taught to look for their configuration files in
${PKG_SYSCONFDIR}, which is passed through to the configure and build
processes.  PKG_SYSCONFDIR may be customized in various ways by setting
other make variables:

* PKG_SYSCONFBASE is the main config directory under which all package
  configuration files are to be found.  This defaults to ${PREFIX}/etc, but
  may be overridden in /etc/mk.conf.

* PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which the
  configuration files for a particular package may be found, e.g. the
  Apache configuration files may all be found under the "httpd" subdirectory
  of ${PKG_SYSCONFBASE}.  This is meant to be set in a package Makefile.

* By default PKG_SYSCONFDIR=${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}, but
  the default may be overridden by setting PKG_SYSCONFDIR.${PKG_SYSCONFVAR}
  for a particular package, where PKG_SYSCONFVAR defaults to ${PKGBASE}.
  This is not meant to be set by a package Makefile, but is reserved for
  users who wish to override the PKG_SYSCONFDIR setting for a particular
  package with a special location.

The only variables that users should customize are PKG_SYSCONFBASE and
PKG_SYSCONFDIR.${PKG_SYSCONFVAR}.  Users will typically want to set
PKG_SYSCONFBASE to /etc, or to accept the default location of ${PREFIX}/etc.


 6.6 Feedback to the author
 ==========================

If you have found any bugs in the package you make available, if you had to
do special steps to make it run under NetBSD or if you enhanced the software
in various other ways, be sure to report these changes back to the original
author of the program! With that kind of support, the next release of the
program can incorporate these fixes, and people not using the NetBSD packages
system can win from your efforts.

Support the idea of free software!


 7 The build process
 ===================

The basic steps for building a program are always the same.  First the
program's source (distfile) must be brought to the local system and
then extracted.  After any patches to compile properly on NetBSD are
applied, the software can be configured, then built (usually by
compiling), and finally the generated binaries etc.  can be put into
place on the system.  These are exactly the steps performed by the
NetBSD package system, which is implemented as a series of targets in
a central Makefile, pkgsrc/mk/bsd.pkg.mk.


 7.1 Program location
 ====================

Before outlining the process performed by the NetBSD package system in the
next section, here's a brief discussion on where programs are installed,
and which variables influence this.

The automatic variable PREFIX indicates where all files of the final
program shall be installed.  It is usually set to $LOCALBASE (/usr/pkg),
or $CROSSBASE for pkgs in the "cross" category, though its value becomes
that of $X11BASE if USE_IMAKE or USE_X11BASE is set.  The value ${PREFIX}
needs to be put into the various places in the program's source where paths
to these files are encoded; see sections 4.3 and 6.2 for details on this.

When choosing which of these variables to use, follow the following rules:

 * ${PREFIX} always points to the location where the current pkg will be
   installed.  When referring to a pkg's own installation path, use ${PREFIX}.

 * ${LOCALBASE} is where all non-X11 pkgs are installed.  If you need to
   construct a -I or -L argument to the compiler to find includes and
   libraries installed by another non-X11 pkg, use ${LOCALBASE}.

 * ${X11BASE} is where the actual X11 distribution (from xsrc etc.) is installed.
   When looking for _standard_ X11 includes (not those installed by a pkg), use
   ${X11BASE}.

 * X11 based pkgs are special in that they may be installed in either
   X11BASE or LOCALBASE. To install X11 packages in LOCALBASE, simply
   install the xpkgwedge package (pkgsrc/pkgtools/xpkgwedge).
   If you need to find includes or libraries installed by a pkg that has
   USE_IMAKE  or USE_X11BASE in its pkg Makefile, you need to use _both_
   ${X11BASE} and ${LOCALBASE}.

 * ${X11PREFIX} should be used to refer to the installed location of an X11
   package. X11PREFIX will be set to ${X11BASE} if xpkgwedge is not installed,
   and to ${LOCALBASE} if xpkgwedge is installed.

 * If xpkgwedge is installed, it is possible to have some packages installed in
   X11BASE and some in LOCALBASE. To determine the prefix of an installed
   package, the EVAL_PREFIX definition can be used. It takes pairs in the
   format DIRNAME=<package>, and the make(1) variable DIRNAME will be set
   to the prefix of the installed package <package>, or ${X11PREFIX} if the
   package is not installed.

   This is best illustrated by example.

   The following lines are taken from pkgsrc/wm/scwm/Makefile:

	EVAL_PREFIX+=	GTKDIR=gtk+
	CONFIGURE_ARGS+=	--with-guile-prefix=${LOCALBASE}	\
				--with-gtk-prefix="${GTKDIR}"		\
				--enable-multibyte

   Specific defaults can be defined for the packages evaluated using
   EVAL_PREFIX, by using a definition of the form:

	GTKDIR_DEFAULT= ${LOCALBASE}

   where "GTKDIR" corresponds to the first definition in the EVAL_PREFIX pair.

 7.2 Main targets
 ================

The main targets used during the build process defined in bsd.pkg.mk are:

 * fetch:
   This will check if the file(s) given in the variables DISTFILES and
   PATCHFILES (as defined in the package's Makefile) are present on the
   local system in /usr/pkgsrc/distfiles. If they are not present, an
   attempt will be made to fetch them using commands of the form

   ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}

   where ${site} varies through several possibilities in turn: first,
   ${MASTER_SITE_OVERRIDE} is tried, then the sites specified in either
   ${SITES_file}, if defined, else ${MASTER_SITES} or ${PATCH_SITES}, as
   applies, then finally the value of ${MASTER_SITE_BACKUP}. The order of
   all except the first can be optionally sorted by the user, via setting
   either ${MASTER_SORT_AWK} or ${MASTER_SORT_REGEX}.

 * checksum:
   After the distfile(s) are fetched, their checksum is generated and
   compared with the checksums stored in the distinfo file. If the
   checksums don't match, the build is aborted. This is to ensure the same
   distfile is used for building, and that the distfile wasn't changed,
   e.g. by some malign force, deliberately changed distfiles on the master
   distribution site or network lossage.

 * extract:
   When the distfiles are present on the local system, they need to be
   extracted, as they are usually in the form of some compressed archive
   format, most commonly .tar.gz. If only some of the distfiles need to be
   uncompressed, the files to be uncompressed should be put into
   EXTRACT_ONLY. If the distfiles are not in .tar.gz format, they can be
   extracted by setting EXTRACT_CMD.

 * patch:
   After extraction, all the patches named by the PATCHFILES, those present
   in the patches subdirectory of the package as well as in
   $LOCALPATCHES/$PKGPATH (e.g. /usr/local/patches/graphics/png) are
   applied. Patchfiles ending in .Z or .gz are uncompressed before they are
   applied, files ending in .orig or .rej are ignored. Any special options
   to patch(1) can be handed in PATCH_DIST_ARGS. See section 4.3 for more
   details.
  
   By default patch is given special args to make it fail if the
   patches with some lines of fuzz. Please fix (regen) the patches
   so that they apply cleanly. The rationale behind this is that
   patches that apply cleanly may end up being applied in the wrong
   place, and cause severe harm there.

 * configure:
   Most pieces of software need information on the header files,
   system calls, and library routines which are available in NetBSD.
   This is the process known as configuration, and is usually
   automated.  In most cases, a script is supplied with the source,
   and its invocation results in generation of header files,
   Makefiles, etc.

   If the program's distfile contains its own configure script, this can
   be invoked by setting HAS_CONFIGURE. If the configure script is a GNU
   autoconf script, GNU_CONFIGURE should be specified instead. In either
   case, any arguments to the configure script can be specified in the
   CONFIGURE_ARGS variable, and the configure script's name can be set in
   CONFIGURE_SCRIPT if it differs from the default "configure".

   If the program uses an Imakefile for configuration, the appropriate
   steps can be invoked by setting USE_IMAKE to YES. (If you only want the
   package installed in $X11PREFIX but xmkmf not being run, set USE_X11BASE
   instead!)

 * build:
   Once configuration has taken place, the software can be built on
   NetBSD by invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as
   the target to build.  The default MAKE_PROGRAM is "gmake" if
   USE_GMAKE is set, "make" otherwise.  MAKEFILE is set to "Makefile"
   by default, and ALL_TARGET defaults to "all".  Any of these
   variables can be set to change the default build process.

 * install:
   Once the build stage has completed, the final step is to install
   the software in public directories, for users.  As in the
   build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with
   the $INSTALL_TARGET instead, the latter defaulting to "install"
   (plus "install.man", if USE_IMAKE is set).

If no target is specified, the default is "build". If a subsequent stage
is requested, all prior stages are made: e.g. "make build" will also
perform the equivalent of:

	make fetch
	make checksum
	make extract
	make patch
	make configure
	make build


 7.3 Other helpful targets
 =========================

 * pre/post-*
   For any of the main targets described in the previous section, two
   auxiliary targets exist with "pre-" and "post-" used as a prefix
   for the main target's name.  These targets are invoked before and
   after the main target is called, allowing extra configuration or
   installation steps, for example, which program's configure script
   or install target omitted.

 * do-*:
   Should one of the main targets do the wrong thing, and should there
   be no variable to fix this, you can redefine it with the do-*
   target.  (Note that redefining the target itself instead of the
   do-* target is a bad idea, as the pre-* and post-* targets won't be
   called anymore, etc.) You will not usually need to do this.

 * reinstall:
   If you did a "make install" and you noticed some file was not installed
   properly, you can repeat the installation with this target, which will
   ignore the "already installed" flag.

 * deinstall:
   This target does a pkg_delete(1) in the current directory,
   effectively de-installing the package. The following variables can
   be used either on the command line or in /etc/mk.conf to tune the
   behaviour:

    - PKG_VERBOSE:
      Add a "-v" to the pkg_delete(1) command.
     
    - DEINSTALLDEPENDS:
      Remove all packages that require (depend on) the given package.
      This can be used to remove any packages that may have been pulled in
      by a given package, e.g. if "make deinstall DEINSTALLDEPENDS=1" is
      done in pkgsrc/x11/kde, this is likely to remove whole KDE. Works by
      adding a "-R" to the pkg_delete command line.

 * update:
   This target causes the current package to be updated to the latest
   version.  The package and all depending packages first get de-installed,
   then current versions of the corresponding packages get compiled and
   installed.  This is similar to manually noting which packages are
   currently installed, then performing a series of "make deinstall" and
   "make install" (or whatever UPDATE_TARGET is set to) for these packages.

   You can use the "update" target to resume package updating in case a
   previous "make update" was interrupted for some reason.  However, in
   this case, make sure you don't call "make clean" or otherwise remove
   the list of dependent packages in ${WRKDIR}.  Otherwise you lose the
   ability to automatically update the current package along with the
   dependent packages you have installed.

   Resuming an interrupted "make update" will only work as long as the
   package tree remains unchanged.  If the source code for one of the
   packages to be updated has been changed, resuming "make update" will
   most certainly fail!

   The following variables can be used either on the command line or in
   /etc/mk.conf to alter the behaviour of "make update":

    - UPDATE_TARGET:
      Install target to recursively use for the updated package and the
      dependent packages.  Defaults to ${DEPENDS_TARGET} if set, "install"
      otherwise for "make update".
      E.g. "make update UPDATE_TARGET=package"

    - NOCLEAN:
      Don't clean up after updating.  Useful if you want to leave the
      work sources of the updated packages around for inspection or
      other purposes.  Be sure you eventually clean up the source
      tree (see the "clean-update" target below) or you may run into
      troubles with old source code still lying around on your next
      "make" or "make update".

    - REINSTALL:
      Deinstall each package before installing (making ${DEPENDS_TARGET}).
      This may be necessary if the "clean-update" target (see below) was
      called after interrupting a running "make update".

    - DEPENDS_TARGET:
      Allows you to disable recursion and hardcode the target for
      packages.  The default is "update" for the update target,
      facilitating a recursive update of prerequisite packages.
      Only set DEPENDS_TARGET if you want to disable recursive updates.
      Use "UPDATE_TARGET" instead to just set a specific target for
      each package to be installed during "make update" (see above).

 * clean-update:
   Clean the source tree for all packages that would get updated if
   "make update" was called from the current directory.  This target
   should not be used if the current package (or any of its depending
   packages) have already been de-installed (e.g., after calling "make
   update") or you may lose some packages you intended to update.
   As a rule of thumb: only use this target _before_ the first time
   you call "make update" and only if you have a dirty package tree
   (e.g., if you used NOCLEAN).

   If you unsure about whether your tree is clean you can either perform
   a "make clean" at the top of the tree, or use the following sequence
   of commands from the directory of the package you want to update
   (*before* running "make update" for the first time, otherwise you lose
   all the packages you wanted to update!):

      make clean-update
      make clean CLEANDEPENDS=YES
      make update

   The following variables can be used either on the command line or in
   /etc/mk.conf to alter the behaviour of "make clean-update":

    - CLEAR_DIRLIST:
      After "make clean", do not reconstruct the list of directories to
      update for this package.  Only use this if "make update" successfully
      installed all packages you wanted to update.  Normally, this is done
      automatically on "make update", but may have been suppressed by the
      NOCLEAN variable (see above).

 * info:
   This target invokes "pkg_info" for the current package. You can use this
   e.g. to check which version of a package is installed.

 * readme:
   This target generates a README.html file, which can be viewed using a
   browser such as navigator (pkgsrc/www/navigator) or lynx
   (pkgsrc/www/lynx). The generated files contain references to any
   packages which are in the ${PACKAGES} directory on the local host. The
   generated files can be made to refer to URLs based on FTP_PKG_URL_HOST
   and FTP_PKG_URL_DIR. For example, if I wanted to generate README.html
   files which pointed to binary packages on the local machine, in the
   directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
   FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
   subdirectories will be searched for all the binary packages.

 * readme-all:
   Use this target to create a file README-all.html which contains a
   list of all packages currently available in the NetBSD Packages
   Collection, together with the category they belong to and a short
   description. This file is compiled from the pkgsrc/*/README.html
   files, so be sure to run this _after_ a "make readme".

 * cdrom-readme:
   This is very much the same as the readme: target (see above), but is
   to be used when generating a pkgsrc tree to be written to a CD-ROM.
   This target also produces README.html files, and can be made to refer
   to URLs based on CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.

 * show-distfiles:
   This target shows which distfiles and patchfiles are needed to build
   the package. (DISTFILES and PATCHFILES, but not patches/*)

 * show-downlevel:
   This target shows nothing if the package is not installed. If a version
   of this package is installed, but is not the version provided in this
   version of pkgsrc, then a warning message is displayed. This target can
   be used to show which of your installed packages are downlevel, and so
   the old versions can be deleted, and the current ones added.

 * show-pkgsrc-dir:
   This target shows the directory in the pkgsrc hierarchy from which the
   package can be built and installed. This may not be the same directory
   as the one from which the package was installed. This target is intended
   to be used by people who may wish to upgrade many packages on a single
   host, and can be invoked from the top-level pkgsrc Makefile by using the
   target "show-host-specific-pkgs"

 * show-installed-depends:
   This target shows which installed packages match the current package's
   DEPENDS. Useful if out of date DEPENDS are causing build problems.

 * check-shlibs:
   After a package is installed, check all its binaries and (on ELF
   platforms) shared libraries to see if they find the shared libs they need.
   Run by default if PKG_DEVELOPER is set in /etc/mk.conf.

 * print-PLIST:
   After a 'make install' from a new or upgraded pkg, this prints out an
   attempt to generate a new PLIST from a 'find -newer work/.extract_done'.
   An attempt is made to care for shared libs etc., but it is STRONGLY
   recommended to review the result before putting it into PLIST. On
   upgrades, it's useful to diff the output of this command against an already
   existing PLIST file.

   If the package installs files via tar(1) or other methods that don't update
   file access times, be sure to add these files manually to your PLIST,
   as 'find -newer' won't catch them!

 * bulk-package:
   Used to do bulk builds. If an appropriate binary package already exists,
   no action is taken. If not, this target will compile, install and
   package it (and it's depends, if PKG_DEPENDS is set properly, see
   section 3.2.1). After creating the binary package, the sources, the
   just-installed package and it's required packages are removed,
   preserving free disk space.

 * bulk-install:
   Used during bulk-installs to install required packages. If an
   appropriate binary package is available, it will be installed via
   pkg_add. If not, "make bulk-package" will be executed, but the installed
   binary not be removed. A binary package is "appropriate" to be installed
   via pkg_add if:

    - None of the package's files (Makefile, ...) were modified since it
      was built
    - None of the package's required (binary) packages were modified since
      it was built


 8 buildlink2 methodology
 ========================

"buildlink2" is a pkgsrc framework that controls what headers and libraries
are seen by a package's configure and build processes.  This is implemented
in a two step process:

 (1) Symlink headers and libraries for dependencies into ${BUILDLINK_DIR},
     which by default is a subdirectory of ${WRKDIR};

 (2) Create wrapper scripts that are used in place of the normal compiler
     tools that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib
     into references into ${BUILDLINK_DIR}.

This normalizes the environment in which a package is built so that the
package may be built consistently despite what may other software may
installed.  Please refer to pkgsrc/mk/buildlink2/buildlink2.txt for some
FAQs and answers regarding buildlink2, and to pkgsrc/mk/buildlink2/README
for a description of how buildlink2 is implemented in pkgsrc.


 8.1 Converting packages to use buildlink2
 =========================================

The process of converting packages to use the buildlink2 framework is
fairly straightforward.  The package Makefile must define USE_BUILDLINK2.
If a dependency on a particular package, e.g.  foo, is required for its
libraries and headers, then we replace:

	DEPENDS+=	foo>=1.1.0:../../category/foo
with
	.include "../../category/foo/buildlink2.mk"

There are several buildlink2.mk files in pkgsrc/mk that handle special
package issues:

 * motif.buildlink2.mk checks for a system-provided Motif installation
   or adds a dependency on x11/lesstif or x11/openmotif;

 * ossaudio.buildlink2.mk defines several variables that may be used by
   packages that use the Open Sound System (OSS) API;

 * pthread.buildlink2.mk uses the value of PTHREAD_OPTS and checks for
   native pthreads or adds a dependency on devel/pth as needed;

 * xaw.buildlink2.mk uses the value of XAW_TYPE to choose a particular
   Athena widgets library.

The comments in those buildlink2.mk files provide a more complete
description of how to use them properly.


 8.2 Writing buildlink2.mk files
 ===============================

A simple example of a buildlink2.mk file for a mythical package foo
follows:

	BUILDLINK_PACKAGES+=          foo
	BUILDLINK_PKGBASE.foo=        foo
	BUILDLINK_DEPENDS.foo?=       foo>=1.0
	BUILDLINK_PKGSRCDIR.foo?=     ../../category/foo

	EVAL_PREFIX+=                 BUILDLINK_PREFIX.foo=foo
	BUILDLINK_PREFIX.foo_DEFAULT= ${LOCALBASE}
	BUILDLINK_FILES.foo=          include/foo.h
	BUILDLINK_FILES.foo+=         include/bar.h
	BUILDLINK_FILES.foo+=         lib/libfoo.*

	BUILDLINK_TARGETS+=           foo-buildlink

	foo-buildlink: _BUILDLINK_USE

The first section controls how the dependency on foo is added.  The
dependency is constructed from four parts:

 (1) BUILDLINK_PACKAGES is the global list of packages for which
     dependencies will be added by buildlink2;

 (2) BUILDLINK_DEPENDS.foo is the actual dependency recorded in the
     installed package;

 (3) BUILDLINK_PKGSRCDIR.foo is the location of the foo pkgsrc
     directory;

 (4) BUILDLINK_DEPMETHOD.foo (not shown above) controls whether we use
     BUILD_DEPENDS or DEPENDS to add the foo dependency, where the
     full dependency is added if BUILDLINK_DEPMETHOD.foo contains "full".

The second section controls which files are linked into ${BUILDLINK_DIR}:

 (1) BUILDLINK_PREFIX.foo is the installation prefix of the package which
     we derive by using EVAL_PREFIX;

 (2) BUILDLINK_FILES.foo is a list of files (shell globs allowed) relative
     to the BUILDLINK_PREFIX.foo directory and will be symlinked into
     ${BUILDLINK_DIR};

 (3) BUILDLINK_FILES_CMD.foo (not shown above) is a shell pipeline that
     outputs a list of files relative to the BUILDLINK_PREFIX.foo
     directory and will be symlinked into ${BUILDLINK_DIR}.

The remaining parts create the foo-buildlink target that actually performs
the symlinking and adds the foo-buildlink target to BUILDLINK_TARGETS,
which is the global list of targets to execute at do-buildlink time.


 9 Debugging
 ===========

To check out all the gotchas when building a package, here are the steps
that I do in order to get a package working. Please note this is basically
the same as what was explained in the previous sections, only with some
debugging aids.

 * Make sure PKG_DEVELOPER=1 is in /etc/mk.conf
 * Create a new directory, and run

	# url2pkg http://www.example.com/path/to/distfile.tar.gz

   You'll need to have pkgsrc/pkgtools/url2pkg installed for that.
 * Edit the Makefile as requested.
 * Fill in DESCR
 * ``make configure''
 * Add any dependencies glimpsed from the configure step to the package's
   Makefile.
 * Make the package compile, doing multiple rounds of

	# make
	# pkgvi ${WRKSRC}/some/file/that/does/not/compile
	# mkpatches
	# patchdiff
	# mv ${WRKDIR}/.newpatches/* patches
	# make mps
	# make clean
   [ mkpatches, patchdiff and pkgvi are from pkgsrc/pkgtools/pkgdiff ]

   Doing as non-root user will assure that no files are modified that
   shouldn't, esp. not during the build phase.
 * Look at Makefile, fix if necessary; see section 4.1.
 * Generate a PLIST:

	# make install
	# make print-PLIST > PLIST
	# make deinstall
	# make install
	# make deinstall

   You usually need to be root to do this.
 * Look if there are any files left:

	# make print-PLIST

   If this brings up any files that are missing in PLIST, add them.
 * Now that the PLIST is ok, install the package again and make a binary
   package:
  
	# make reinstall && make package
	
 * Delete the installed package:

	# pkg_delete blub
	
 * Repeat the above find command, which shouldn't find anything now:

	# make print-PLIST

 * Reinstall the binary package:

	# pkg_add ..../blub.tgz
	
 * Play with it. Make sure everything works.
 * Run pkglint from pkgsrc/pkgtools/pkglint, and fix the problems it reports.

	# pkglint

 * Submit (or commit, if you have cvs access); see section 11.


 10 FAQs & features of the package system
 ========================================

 10.1 Packages using GNU autoconf
 ================================

If your package uses GNU autoconf created configure scripts, add the following
to your package's Makefile:

	GNU_CONFIGURE= yes

Note that this appends --prefix=${PREFIX} to CONFIGURE_ARGS, so you don't
have to do that yourself, and this may not be what you want.


 10.2 Other distrib methods than .tar.gz
 =======================================

If your package uses a different distribution method from .tar.gz, take a
look at the package for pkgsrc/editors/sam, which uses a gzipped shell archive
(shar), but the quick solution is to set EXTRACT_SUFX to the name after the
DISTNAME field, and add the following to your package's Makefile:

	EXTRACT_SUFX=   .msg.gz
	EXTRACT_CMD=            zcat


 10.3 Packages not creating their own subdirectory
 =================================================

Your package doesn't create a subdirectory for itself (like GNU software
does, for instance), but extracts itself in the current directory: see
pkgsrc/editors/sam again, but the quick answer is:

	WRKSRC=		${WRKDIR}

Please note that the old

	NO_WRKSUBDIR=   yes

has been deprecated and should not be used.


 10.4 Custom configuration process
 =================================

Your package uses a weird Configure script: See the top package, but the
quick answer is:

	HAS_CONFIGURE=          yes
	CONFIGURE_SCRIPT=       Configure
	CONFIGURE_ARGS+=        netbsd13


 10.5 Packages not building in their DISTNAME directory
 ======================================================

Your package builds in a different directory from its base DISTNAME - see
tcl and tk packages:

	WRKSRC=         ${WRKDIR}/${DISTNAME}/unix


 10.6 How to fetch all distfiles at once
 =======================================

You would like to download all the distfiles in a single batch from work or
university, where you can't run a "make fetch". But there's no archive of
the distfiles on ftp.netbsd.org and the one on ftp.freebsd.org contains
many distfiles for which there are no ports (yet).

The answer here is to do a "make fetch-list" in /usr/pkgsrc, carry the
resulting list to your machine at work/school and use it there. If you don't
have a NetBSD-compatible ftp(1) (like lukemftp) at work, don't forget to
set FETCH_CMD to something that fetches an URL:

At home:

	% cd /usr/pkgsrc
	% make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
	% scp /tmp/fetch.sh work:/tmp

At work:

	% sh /tmp/fetch.sh
	% tar up /tmp/distfiles and take it home

If you have a machine running NetBSD, and you want to get *all* distfiles
(even ones that aren't for your machine architecture), you can do so by
using the above-mentioned 'make fetch-list'-approach, or fetch the distfiles
directly by typing:

	% make mirror-distfiles

If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can
get all & everything by typing

	% make fetch NO_SKIP=yes


 10.7 How to fetch files from behind a firewall
 ==============================================

If you are sitting behind a firewall which does not allow direct connections
to Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts.
This is done using an environment variable in the form of a URL
e.g. in Amdahl, the machine orpheus.amdahl.com is one of the firewalls, and
it uses port 80 as the proxy port number. So the proxy environment
variables look like:

	ftp_proxy=ftp://orpheus.amdahl.com:80/
	http_proxy=http://orpheus.amdahl.com:80/


 10.8 If your patch contains an RCS ID
 =====================================

See section 4.3 on how to remove RCS IDs from patch files.


 10.9 How to pull in variables from /etc/mk.conf
 ===============================================

The problem with package-defined variables that can be overridden via
MAKECONF or /etc/mk.conf is that make(1) expands a variable as it is
used, but evaluates preprocessor like statements (.if, .ifdef and
.ifndef) as they are read.  So, to use any variable (which may be set
in /etc/mk.conf) in one of the .if* statements, the file /etc/mk.conf
must be included before that .if* statement.

Rather than have a number of ad-hoc ways of including /etc/mk.conf,
should it exist, or MAKECONF, should it exist, include the
pkgsrc/mk/bsd.prefs.mk file in the package Makefile before any
preprocessor-like .if, .ifdef, or .ifndef statements:

	.include "../../mk/bsd.prefs.mk"

	.if defined(USE_MENUS)
	...
	.endif

If you wish to set the CFLAGS variable in /etc/mk.conf please make sure
to use:
  
   CFLAGS+= -your -flags

Using 'CFLAGS=' (ie without the '+') may lead to problems with packages
that need to add their own flags.  Also, you may want to take a look at
the devel/cpuflags package, if you're interested in optimization for the
current CPU.


 10.10 Is there a mailing list for pkg-related discussion?
 =========================================================

Yes. We are using tech-pkg@@netbsd.org for discussing package related
issues. To subscribe do:

	% echo subscribe tech-pkg | mail majordomo@@netbsd.org


 10.11 How do i tell "make fetch" to do passive FTP?
 ===================================================

This depends on which utility is used to retrieve distfiles. From
bsd.pkg.mk, FETCH_CMD is assigned the first available command from the
following list:

	/usr/bin/fetch
	${LOCALBASE}/bsd/bin/ftp
	/usr/bin/ftp

On a default NetBSD install, this will be /usr/bin/ftp, which automatically
tries passive connections first, and falls back to active connections if the
server refuses to do passive. For the other tools, add the following to your
/etc/mk.conf file: PASSIVE_FETCH=1

Having that option present will prevent /usr/bin/ftp from falling back to
active transfers.


 10.12 Dependencies on other packages
 ====================================

Your package may depend on some other package being present - and there are
various ways of expressing this dependency. NetBSD supports the
BUILD_DEPENDS and DEPENDS definitions, as well as dependencies via
buildlink2.mk (see section 8).

The basic difference between the two definitions is as follows: The
DEPENDS definition registers that pre-requisite in the binary package,
whilst the BUILD_DEPENDS definition does not.

This means that if you only need a package present whilst you are building,
it should be noted as a BUILD_DEPENDS.

The format for a BUILD_DEPENDS and a DEPENDS definition is:

	<pre-req-package-name>:../../<category>/<pre-req-package>

Please note that the "pre-req-package-name" may include any of the wildcard
version numbers recognised by pkg_info(1).

(a) If your package needs to use another package to build itself, this
is specified using the BUILD_DEPENDS definition.

	BUILD_DEPENDS+=  autoconf-2.13:../../devel/autoconf

(b) If your package needs a library with which to link, this is specified
using the DEPENDS definition.  An example of this is the pkgsrc/print/lyx
package, which uses the xpm library, version 3.4j to build.

	DEPENDS+=       xpm-3.4j:../../graphics/xpm

You can also use wildcards in package dependences:

	DEPENDS+=	xpm-[0-9]*:../../graphics/xpm

Note that such wildcard dependencies are retained when creating binary
packages.  The dependency is checked when installing the binary
package and any package which matches the pattern will be used.
Wildcard dependencies should be used with care.

The -[0-9]* should be used instead of -* to avoid potentially
ambiguous matches such as tk-postgresql matching a tk-* DEPEND.

(c) If your package needs some executable to be able to run correctly, this
is specified using the DEPENDS definition. The pkgsrc/print/lyx package needs
to be able to execute the latex binary from the teTeX package when it runs,
and that is specified:

	DEPENDS+=        teTeX-[0-9]*:../../print/teTeX

The comment about wildcard dependencies from previous paragraph
applies here, too.

If your package needs files from another package to build, see the
first part of the "do-configure" target pkgsrc/print/ghostscript5 package
(it relies on the jpeg sources being present in source form during the
build):

	if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
		cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract;              \
	fi

If you build any other packages that way, please make sure the working
files are deleted too when this package's working files are cleaned up.
The easiest way to do so is by adding a pre-clean target:

	pre-clean:
		cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean

Please also note the BUILD_USES_MSGFMT and BUILD_USES_GETTEXT_M4 definitions,
which are provided as convenience definitions.  The former works out whether
msgfmt(1) is part of the base system, and, if it isn't, installs the
pkgsrc/devel/gettext package.  The latter adds a build dependency on either an
installed version of an older gettext package, or if it isn't, installs the
pkgsrc/devel/gettext-m4 package.


 10.13 Conflicts with other packages
 ===================================

Your package may conflict with other packages a user might already have
installed on his system, e.g. if your package installs the same set of
files like another package in our pkgsrc tree.

In this case you can set CONFLICTS to a space separated list of packages
(including version string) your package conflicts with.

For example pkgsrc/x11/Xaw3d and pkgsrc/x11/Xaw-Xpm install provide the
same shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile:

	CONFLICTS=      Xaw-Xpm-[0-9]*

and in pkgsrc/x11/Xaw-Xpm/Makefile:

	CONFLICTS=      Xaw3d-[0-9]*

Packages will automatically conflict with other packages with the name prefix
and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
with the older version "Xaw3d-1.3".


 10.14 Software which has a WWW Home Page
 ========================================

The NetBSD packages system now supports a variable called HOMEPAGE.
If the software being packaged has a home page, the Makefile should
include the URL for that page in the HOMEPAGE variable. The definition
of the variable should be placed immediately after the MAINTAINER
variable.


 10.15 How to handle modified distfiles with the 'old' name
 ==========================================================

Sometimes authors of a software package make some modifications after the
software was released, and they put up a new distfile without changing the
package's version number. If a package is already in pkgsrc at that time,
the md5 checksum will no longer match. The correct way to work around this
is to update the package's md5 checksum to match the package on the master
site (beware, any mirrors may not be up to date yet!), and to remove the
old distfile from ftp.netbsd.org's /pub/NetBSD/packages/distfiles directory.
Furthermore, a mail to the package's author seems appropriate making sure
the distfile was really updated on purpose, and that no trojan horse or so
crept in.


 10.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
 =========================================================================

When compiling the pkgsrc/pkgtools/pkg_install package, you get the error
from make that it doesn't know how to make /usr/share/tmac/tmac.andoc? This
indicates that you don't have installed the "text" set on your machine
(nroff, ...). It is recommended to do that.

In the case of the pkg_install package, you can get away with setting
NOMAN=YES either in the environment or in /etc/mk.conf.


 10.17 How to handle incrementing versions when fixing an existing package
 =========================================================================

When making fixes to an existing package it can be useful to change
the version number in PKGNAME. To avoid conflicting with future versions
by the original author, a 'nb1' ('nb2', ...) suffix can be used on package
versions by setting PKGREVISION=1 (2,. ..). The "nb" is treated like a "."
by the pkg tools. E.g.

DISTNAME=	foo-17.42
PKGREVISION=	9

will result in a PKGNAME of foo-17.42nb9.

When a new release of the package is released, the PKGREVISION should be
removed. E.g. on a new minor release of the above package, things should
be like:

DISTNAME=	foo-17.43


 10.18 "Could not find bsd.own.mk" - what's wrong?
 =================================================

You didn't install the compiler set, comp.tgz, when you installed your
NetBSD machine. Please get it and install it, by extracting it in /:

	# tar --unlink -pvxf .../comp.tgz

comp.tgz is part of every NetBSD release, please get the one matching
the release you have installed (determine via "uname -r").


 10.19 Restricted packages
 =========================

Some licenses restrict how software may be re-distributed.  In order to
satisfy these restrictions, the package system defines five make variables
that can be set to note these restrictions:

 * RESTRICTED:
   This variable should be set whenever a restriction exists
   (regardless of its kind).  Set this variable to a string
   containing the reason for the restriction.

 * NO_BIN_ON_CDROM:
   Binaries may not be placed on CD-ROM.  Set this variable to
   ${RESTRICTED} whenever a binary package may not be included
   on a CD-ROM.

 * NO_BIN_ON_FTP:
   Binaries may not be placed on an ftp server.  Set this
   variable to ${RESTRICTED} whenever a binary package may not
   not be made available on the Internet.

 * NO_SRC_ON_CDROM:
   Distfiles may not be placed on CD-ROM.  Set this variable to
   ${RESTRICTED} if re-distribution of the source code or other
   distfile(s) is not allowed on CD-ROMs.

 * NO_SRC_ON_FTP:
   Distfiles may not be placed on FTP.  Set this variable to
   ${RESTRICTED} if re-distribution of the source code or other
   distfile(s) via the Internet is not allowed.

Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic
make variables to denote restrictions is deprecated, because they
unconditionally prevent users from generating binary packages!


 10.20 Packages using (n)curses
 ==============================

Some packages need curses functionality that wasn't present in NetBSD's own
curses prior to 1.4Y.

If ../../devel/ncurses/buildlink2.mk is included in a package's Makefile,
then a curses library and headers with ncurses functionality are linked
into ${BUILDLINK_DIR} at pre-configure time.  If ncurses is actually
required, then define USE_NCURSES in the package's Makefile:
	USE_NCURSES=	# redrawwin
The comment should indicate which functions are missing.


 10.21 Automated security check
 ==============================

Please be aware that there can often be bugs in third-party software,
and some of these bugs can leave a machine vulnerable to exploitation
by attackers.  In an effort to lessen the exposure, the NetBSD
packages team maintains a database of known-exploits to packages which
have at one time been included in pkgsrc.  The database can be
downloaded automatically, and a security audit of all packages
installed on a system can take place.  To do this, install the
pkgsrc/security/audit-packages package.  It has two components:

 (1) download-vulnerability-list, an easy way to download a list of the
     security vulnerabilities information. This list is kept up to date by
     the NetBSD security officer and the NetBSD packages team, and is
     distributed from the NetBSD ftp server:

	ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/vulnerabilities

 (2) audit-packages, an easy way to audit the current machine, checking
     each vulnerability which is known. If a vulnerable package is
     installed, it will be shown by output to stdout, including a
     description of the type of vulnerability, and a URL containing more
     information.

Use of the audit-packages package is strongly recommended.

The following message is displayed as part of the audit-packages
installation procedure:

        ======================================================================
	You may wish to have the vulnerabilities file downloaded daily so that
	it remains current.  This may be done by adding an appropriate entry
	to the root users crontab(5) entry.  For example the entry
	
	# download vulnerabilities file
	0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1
	
	will update the vulnerability list every day at 3AM.
	
	In addition, you may wish to run the package audit from the daily
	security script.  This may be accomplished by adding the following
	lines to /etc/security.local
	
	if [ -x ${PREFIX}/sbin/audit-packages ]; then
	        ${PREFIX}/sbin/audit-packages
	fi
        ======================================================================


Note to package developers: When a vulnerability is found, this should be
noted in localsrc/security/advisories/pkg-vulnerabilities, and after the
commit of that file, it should be copied to
/pub/NetBSD/packages/distfiles/vulnerabilities on ftp.netbsd.org.


 10.22 What's the proper way to create an account from a package?
 ================================================================

There are two make variables used to control the creation of package-specific
groups and users at pre-install time.  The first is PKG_GROUPS, which is a
list of group[:groupid] elements, where the groupid is optional.  The second
is PKG_USERS, which is a list of elements of the form:

	user:group[:[userid][:[description][:[home][:shell]]]]

where only the user and group are required, the rest being optional.  A
simple example is:

	PKG_GROUPS=	foogroup
	PKG_USERS=	foouser:foogroup

A more complex example is that creates two groups and two users is:

	PKG_GROUPS=	group1 group2:1005
	PKG_USERS=	first:group1::First\\ User			\
			second:group2::Second\\ User:/home/second:${SH}

By default, a new user will have home directory /nonexistent, and login shell
/sbin/nologin unless they are specified as part of the user element.

The package Makefile must also set USE_PKGINSTALL to "YES" prior to the
inclusion of bsd.pkg.mk.  This will cause the users and groups to be created
at pre-install time, and the admin will be prompted to remove them at
post-deinstall time.  Automatic creation of the users and groups can be
toggled on and off by setting the environment variable PKG_CREATE_USERGROUP
prior to package installation.


 10.23 How to handle compiler bugs
 =================================

Some source files trigger bugs in the compiler, based on combinations
of compiler version and architecture and almost always relation to
optimisation being enabled.  Common symptoms are gcc internal errors
or never finishing compiling a file.

Typically a workaround involves testing the MACHINE_ARCH and compiler
version, disabling optimisation for that file/MACHINE_ARCH/compiler
combination, and documenting it in doc/HACKS. See doc/HACKS for
examples.


 10.24 Packages providing info files
 ===================================

Some packages install info files or use the makeinfo or install-info
commands. Each info files:
	- is considered to be installed in the directory
	  ${PREFIX}/${INFO_DIR};
	- is registered in the Info directory file
	  ${PREFIX}/${INFO_DIR}/dir;
	- and must be listed as a filename in the INFO_FILES variable
	  in the package Makefile.
 
INFO_DIR defaults to `info' and can be overridden in the package Makefile.
INSTALL and DEINSTALL scripts will be generated for handling registration
of the info files in the Info directory file.
The command install-info used for the info files registration is either
provided by the system or by a special purpose package automatically 
added as dependency if needed.

A package which need the makeinfo command at build time must define
the variable USE_MAKEINFO in its Makefile. If a minimum version of the
makeinfo command is needed it should be noted with the TEXINFO_REQD variable
in the package Makefile. By default a minimum version of 3.12 is required.
If the system does not provide a makeinfo command or if it does not match
the required minimum a build dependency on the devel/gtexinfo package is
added.

The installation process of the software provided by the package must not
use the install-info as the registration of info files
is the task of the package INSTALL SCRIPT, and it must use
the right makeinfo command.

If the package use buildlink2 framework no special action should be needed
to achieve this goal.

If the package does not use the buildlink2 framework patch files are likely
to be needed so the build and installation process of the software
picks up the -possibly dummys- values of INSTALL_INFO and MAKEINFO in the
environment.

*NOTE* Temporally the variable USE_NEW_TEXINFO must be defined in the
package Makefile. Previously info files, install-info and makeinfo
were handled somewhat differently and the two ways will coexist for
a short period of time until all older packages are updated.

 10.25 Packages whose distfiles aren't available for plain downloading
 =====================================================================

If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES
and a 'make fetch' will call files/getsite.sh with the name of each file
to download as an argument, expecting it to output the URL of the directory
from which to download it. graphics/ns-cult3d is an example of this usage.

If the download can't be automated, because the user must submit personal
information to apply for a password, or must pay for the source, or whatever,
you can set _FETCH_MESSAGE to a macro which displays a message explaining
the situation. _FETCH_MESSAGE must be executable shell commands, not just a
message. (Generally, it executes ${ECHO}). As of this writing, the following
packages use this: audio/realplayer, cad/simian, devel/ipv6socket,
emulators/vmare-module, fonts/acroread-jpnfont, sysutils/storage-manager,
www/ap-aolserver, www/openacs. Try to be consistent with them.


 10.26 Using pkgsrc on non-NetBSD (Darwin, FreeBSD, IRIX, Linux, OpenBSD, Solaris)
 =================================================================================

In order to use pkgsrc on a non-NetBSD operating system, you must first
bootstrap the necessary utilities (BSD make, pkg_*, ...). See
http://www.netbsd.org/Documentation/software/packages.html#bootstrap
for information on boostrapping.  Binary bootstrap-kits are available from that
URL as well.  If your Operating System is not yet supported, we encourage you to
port the bootstrap-kit and submit your changes.


 10.27 Configuration files handling and placement
 ================================================

The global variable PKG_SYSCONFBASE (and some others) can be set by the
system administrator in /etc/mk.conf to define the place where
configuration files get installed. Therefore, packages must be adapted to
support this feature. Keep in mind that you should only install files that
are strictly necessary in the configuration directory, files that can
go to $PREFIX/share should go there.

We will take a look at available variables first (bsd.pkg.mk contains more
information). PKG_SYSCONFDIR is where the configuration files for a package
may be found (that is, the full path, e.g. /etc or /usr/pkg/etc). This
value may be customized in various ways:

 1) PKG_SYSCONFBASE is the main config directory under which all package
    configuration files are to be found. Users will typically want to set
    it to /etc, or accept the default location of $PREFIX/etc.

 2) PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which
    the configuration files for a particular package may be found. Defaults
    to $SYSCONFBASE

 3) PKG_SYSCONFVAR is the special suffix used to distinguish any overriding
    values for a particular package (see next item). It defaults to
    ${PKGBASE}, but for a collection of related packages that should all
    have the same PKG_SYSCONFDIR value, it can be set in each of the
    package Makefiles to a common value.

 4) PKG_SYSCONFDIR.${PKG_SYSCONFVAR} overrides the value of
    ${PKG_SYSCONFDIR} for packages with the same value for PKG_SYSCONFVAR.

    As an example, all the various KDE packages may want to set
    PKG_SYSCONFVAR to "kde" so admins can set ${PKG_SYSCONFDIR.kde} in
    /etc/mk.conf to define where to install KDE config files.

Programs' configuration directory should be defined during the configure
stage. Packages that use GNU autoconf can usually do this by using the
--sysconfdir parameter, but this brings some problems as we will see now.
When you change this pathname in packages, you should not allow them to
install files in that directory directly. Instead they need to install
those files under share/examples/${PKGNAME} so PLIST can register them.

Once you have the required configuration files in place (under the
share/examples directory) the variable CONF_FILES should be set to copy
them into PKG_SYSCONFDIR. The contents of this variable is formed by pairs
of filenames; the first element of the pair specifies the file inside the
examples directory (registered by PLIST) and the second element specifies
the target file. This is done this way to allow binary packages to place
files in the right directory using INSTALL/DEINSTALL scripts which are
created automatically.  The package Makefile must also set USE_PKGINSTALL
to "YES" prior to the inclusion of bsd.pkg.mk to use these automatically
generated scripts.  The automatic copying of config files can be toggled by
setting the environment variable PKG_CONFIG prior to package installation.

Here is an example, taken from mail/mutt/Makefile:

	EGDIR=	${PREFIX}/share/doc/mutt/samples
	CONF_FILES=	${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc

As you can see, this package installs configuration files inside EGDIR,
which are registered by PLIST. After that, the variable CONF_FILES lists
the installed file first and then the target file. Users will also get an
automatic message when files are installed using this method.


 10.28 Packages providing login shells
 =====================================

If the purpose of the package is to provide a login shell, the variable
PKG_SHELL should contain the full pathname of the shell executable installed
by this package. The package Makefile also must set USE_PKGINSTALL to "YES"
prior to the inclusion of bsd.pkg.mk to use the automatically generated
INSTALL/DEINSTALL scripts.

An example taken from shells/zsh:

	USE_PKGINSTALL=	YES
	PKG_SHELL=	${PREFIX}/bin/zsh

The shell is registered into /etc/shells file automatically in the
post-install step by the auto-generated INSTALL script and removed in the
deinstall step by the DEINSTALL script.


 10.29 Packages providing locale catalogues
 ==========================================

If the package provides its own locale catalogues, the variable
USE_PKGLOCALEDIR should be defined.  It will ensure that the package's
Makefile template files are fixed and point to the correct locale directories
(which may vary, depending on OS), if necessary.  See also section 5.1 for
details about ${PKGLOCALEDIR}.  This functionality is buildlink2-only.


 10.30 Using 'sudo' with pkgsrc
 ==============================

When installing packages as non-root user and using the just-in-time
su(1) feature of pkgsrc, it can become annoying to type in the root
password for each required package installed. To avoid this, the sudo
package can be used, which does password caching over a limited time.
To use it, install sudo (either as binary package or from
pkgsrc/security/sudo) and then put the following into your /etc/mk.conf:

	SU_CMD=/usr/pkg/bin/sudo /bin/sh -c


 10.31 Packages that cannot or should not be built
 =================================================

There are several reasons why a package might be instructed to not
build under certain circumstances. If the package builds and runs
on most platforms, the exceptions should be noted with NOT_FOR_PLATFORM.
If the package builds and runs on a small handful of platforms,
set ONLY_FOR_PLATFORM instead. If the package should be skipped
(for example, because it provides functionality already provided
by the system), set PKG_SKIP_REASON to a descriptive message. If
the package should fail because some preconditions are not met,
set PKG_FAIL_REASON to a descriptive message.

IGNORE is deprecated because it didn't provide enough information
to determine whether the build should fail.


 10.32 Packages which should not be deleted, once installed
 ==========================================================

To ensure that a package may not be deleted, once it has been installed,
the PKG_PRESERVE definition should be set in the package Makefile. This
will be carried into any binary package that is made from this pkgsrc
entry. A "preserved" package will not be deleted using pkg_delete(1),
unless the "-f" option is used.

 10.33 Packages containing perl scripts
 ======================================

If your package contains interpreted perl scripts, set REPLACE_PERL to
ensure that the proper interpreter path is set. REPLACE_PERL should
contain a list of scripts, relative to WRKSRC, that you want adjusted.

 11 Submitting & Committing
 ==========================

 11.1 Submitting your packages
 =============================

You have to separate between binary and "normal" (source) packages here:

 * precompiled binary packages:
   Our policy is that we accept binaries only from NetBSD developers to
   guarantee that the packages don't contain any trojan horses etc.
   This is not to piss anyone off but rather to protect our users!
   You're still free to put up your home-made binary packages and tell
   the world where to get them.

 * packages:
   First, check that your package is complete, compiles and runs well; see
   section 9 and the rest of this document. Next, generate an uuencoded
   gzipped tar(1) archive, preferably with all files in a single directory.
   Finally, send-pr(1) with category "pkg", a synopsis which includes the
   package name and version number, a short description of your package
   (contents of the COMMENT variable or DESCR file are OK) and attach the
   archive to your PR.

   If you want to submit several packages, please send a separate PR for
   each one, it's easier for us to track things that way.


 11.2 Committing: Importing the package into CVS
 ===============================================

This section is only of interest for NetBSD developers with write
access to the NetBSD pkgsrc repository. Please remember that cvs
imports files relative to the cwd, and that the pathname that you
give the "cvs import" command is so that it knows where to place
the files in the repository.  Newly created packages should be
imported with a vendor tag of "TNF" and a release tag of "pkgsrc-base",
e.g:

	% cd .../pkgsrc/<category>/<pkgname>
	% cvs import pkgsrc/<category>/<pkgname> TNF pkgsrc-base

and remember to move the directory from which you imported out of
the way, or cvs will complain the next time you "cvs update" your
source tree.  Also don't forget to add the new package to the
category's Makefile.

The commit message of the initial import should include part of the
DESCR file, so people reading the mailing lists know what the package
is/does.

Please note all package updates/additions in pkgsrc/doc/CHANGES! It's very
important to keep this file up to date and conforming to the existing
format, because it will be used by scripts to automatically update pages on
www.netbsd.org and other sites.

For new packages, "cvs import" is preferred to "cvs add" because
the former gets everything with a single command, and provides a
consistent tag.


 11.3 Updating a Package to a Newer Version
 ==========================================

Please always put a concise, appropriate and relevant summary of the
changes between old and new versions into the commit log when updating
a package. There are various reasons for this:

+ a URL is volatile, and can change over time. It may go away completely,
or its information may be overwritten by newer information.

+ having the change information between old and new versions in our CVS
repository is very useful for people who use either cvs or anoncvs.

+ having the change information between old and new versions in our CVS
repository is very useful for people who read the pkgsrc-changes mailing
list, so that they can make tactical decisions about when to upgrade
the package.

Please also recognise that, just because a new version of a package
has been released, it should not automatically be upgraded in the CVS
repository.  We prefer to be conservative in the packages that are
included in pkgsrc - development or beta packages are not really the
best thing for most places in which pkgsrc is used. Please use your
judgement about what should go into pkgsrc, and bear in mind that
stability is to be preferred above new and possibly untested features.


 11.4 Moving a Package in pkgsrc
 ===============================

 1. Make a copy of the directory somewhere else.
 2. Remove all CVS dirs.
    Alternatively to the first two steps you can also do:
	  cvs -d user@@cvs.netbsd.org:/cvsroot export -D today pkgsrc/category/package
    and use that for further work.
 3. Fix CATEGORIES and any DEPENDS paths that just did ../package
    instead of ../../category/package.
 4. "cvs import" the modified package in the new place.
 5. Check if any package depends on it:
	cd /usr/pkgsrc
	grep /package */*/Makefile* */*/buildlink*
 6. Fix paths in packages from step 5 to point to new location.
 7. "cvs rm (-f)" the package at the old location.
 8. Remove from oldcategory/Makefile.
 9. Add to newcategory/Makefile.
10. Commit the changed and removed files:
	cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
    and any packages from step 5, of course.


 12 A simple example of a package: bison
 =======================================

I checked to find a piece of software that wasn't in the packages
collection, and picked GNU bison. Quite why someone would want to have
bison when Berkeley yacc is already present in the tree is beyond me, but
it's useful for the purposes of this exercise.


 12.1 files
 ==========

The file contents in this section must be used without the "> " prefix.


 12.1.1 Makefile
 ===============

	# <$>NetBSD<$>
	
	DISTNAME=       bison-1.25
	CATEGORIES=     devel
	MASTER_SITES=   ${MASTER_SITE_GNU}
	MAINTAINER=     thorpej@@netbsd.org
	HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
	COMMENT=        GNU yacc clone
	
	GNU_CONFIGURE=  yes
	INFO_FILES=     bison.info
	
	.include "../../mk/bsd.pkg.mk"


 12.1.2 DESCR
 ================

	GNU version of yacc.  Can make re-entrant parsers, and numerous other
	improvements.  Why you would want this when Berkeley yacc(1) is part
	of the NetBSD source tree is beyond me.


 12.1.3 PLIST
 ================

	@@comment <$>NetBSD<$>
	bin/bison
	man/man1/bison.1.gz
	info/bison.info
	info/bison.info-1
	info/bison.info-2
	info/bison.info-3
	info/bison.info-4
	info/bison.info-5
	share/bison.simple
	share/bison.hairy


 12.1.4 Checking a package "pkglint"
 ===================================

The NetBSD package system comes with a tool called "pkglint" (located in the
directory "pkgsrc/pkgtools/pkglint") which helps to check the contents of these
files. After installation it is quite easy to use, just change to the
directory of the package you wish to examine and execute "pkglint":

	% pkglint
	OK: checking ./DESCR.
	OK: checking Makefile.
	OK: checking distinfo.
	OK: checking patches/patch-aa.
	looks fine.

Depending on the supplied command line arguments (see "man pkglint") more
verbose checks will be performed. Use e.g. "pkglint -v" for a very verbose
check.


 12.2 Steps for building, installing, packaging
 ==============================================

Create the directory where the package lives, plus any auxiliary directories:

	# cd /usr/pkgsrc/lang
	# mkdir bison
	# cd bison
	# mkdir patches pkg

Create Makefile, DESCR and PLIST as in section 11.1,
then continue with fetching the distfile:

	# make fetch
	>> bison-1.25.tar.gz doesn't seem to exist on this system.
	>> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
	Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
	ftp: Error retrieving file: 500 Internal error
	
	>> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
	Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
	ftp: Error retrieving file: 500 Internal error
	
	>> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
	Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
	Successfully retrieved file.

Generate the checksum of the distfile into distinfo:

	# make makesum

Now compile:

	# make
	>> Checksum OK for bison-1.25.tar.gz.
	===>  Extracting for bison-1.25
	===>  Patching for bison-1.25
	===>   Ignoring empty patch directory
	===>  Configuring for bison-1.25
	creating cache ./config.cache
	checking for gcc... cc
	checking whether we are using GNU C... yes
	checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
	checking how to run the C preprocessor... cc -E
	checking for minix/config.h... no
	checking for POSIXized ISC... no
	checking whether cross-compiling... no
	checking for ANSI C header files... yes
	checking for string.h... yes
	checking for stdlib.h... yes
	checking for memory.h... yes
	checking for working const... yes
	checking for working alloca.h... no
	checking for alloca... yes
	checking for strerror... yes
	updating cache ./config.cache
	creating ./config.status
	creating Makefile
	===>  Building for bison-1.25
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g LR0.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g allocate.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g closure.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g conflicts.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g derives.c
	cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getargs.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g gram.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
	cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
	cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o getopt.o getopt1.o
	./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
	rm -f bison.s1
	sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1

Everything seems OK, so install the files:

	# make install
	>> Checksum OK for bison-1.25.tar.gz.
	===>  Installing for bison-1.25
	sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
	rm -f /usr/pkg/bin/bison
	cd /usr/pkg/share; rm -f bison.simple bison.hairy
	rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
	install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
	/usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
	/usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
	cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
	/usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
	===>  Registering installation for bison-1.25

You can now use bison, and also - if you decide so - remove it with
"pkg_delete bison-1.25". Should you decide that you want a binary package,
do this now:

	# make package
	>> Checksum OK for bison-1.25.tar.gz.
	===>  Building package for bison-1.25
	Creating package bison-1.25.tgz
	Registering depends:.
	Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'

Now that you don't need the source and object files any more, clean up:

	# make clean
	===>  Cleaning for bison-1.25


======================
Appendix A: build logs
======================

 A.1 Building top
 ================

	# make
	>> top-3.5beta5.tar.gz doesn't seem to exist on this system.
	>> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
	Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
	Successfully retrieved file.
	>> Checksum OK for top-3.5beta5.tar.gz.
	===>  Extracting for top-3.5beta5
	===>  Patching for top-3.5beta5
	===>  Applying NetBSD patches for top-3.5beta5
	===>  Configuring for top-3.5beta5
	/bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
	chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
	
	Reading configuration from last time...
	
	Using these settings:
	        Bourne Shell   /bin/sh
	          C compiler   cc
	    Compiler options   -DHAVE_GETOPT -O
	         Awk command   awk
	     Install command   /usr/bin/install
	
	              Module   netbsd13
	             LoadMax   5.0
	        Default TOPN   -1
	        Nominal TOPN   18
	       Default Delay   2
	Random passwd access   yes
	          Table Size   47
	               Owner   root
	         Group Owner   kmem
	                Mode   2755
	       bin directory   $(PREFIX)/bin
	       man directory   $(PREFIX)/man/man1
	       man extension   1
	       man style       man
	
	Building Makefile...
	Building top.local.h...
	Building top.1...
	Doing a "make clean".
	rm -f *.o top core core.* sigdesc.h
	To create the executable, type "make".
	To install the executable, type "make install".
	===>  Building for top-3.5beta5
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c top.c
	awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c commands.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c display.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c screen.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c username.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c utils.c
	utils.c: In function `errmsg':
	utils.c:348: warning: return discards `const' from pointer target type
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c version.c
	cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c getopt.c
	cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
	rm -f top
	cc -o top top.o commands.o display.o screen.o username.o  utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
	#
	#
	#
	#
	# make install
	>> Checksum OK for top-3.5beta5.tar.gz.
	===>  Installing for top-3.5beta5
	/usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
	/usr/bin/install top.1 /usr/pkg/man/man1/top.1
	strip /usr/pkg/bin/top
	===>  Registering installation for top-3.5beta5
	#


 A.2 Packaging top
 =================

	# make package
	>> Checksum OK for top-3.5beta5.tar.gz.
	===>  Building package for top-3.5beta5
	Creating package top-3.5beta5.tgz
	Registering depends:.
	Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'


======================================================
Appendix B: Layout of the FTP server's package archive
======================================================

Layout for precompiled binary packages on ftp.netbsd.org:

/pub/NetBSD/packages/
                README
                distfiles/
		pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc
                1.5/
                        i386/
                                All/
                                archivers/
                                        foo -> ../All/foo
                                ...
                        m68k/
                                All/
                                archivers/
                                        foo -> ../All/foo
                                ...
                        amiga -> m68k
                        atari -> m68k
                        ...


To create:
 - cd /usr/pkgsrc ; make install ; make package
 - upload /usr/pkgsrc/packages to
   ftp://ftp.netbsd.org/pub/NetBSD/packages/\
    `uname -r | sed 's@@\.\([0-9]*\)[\._].*@@\.\1@@'`/`uname -p`
 - if necessary ln -s `uname -m` `uname -p`

Disk space needed: unknown.

Packages for a release version of NetBSD should be uploaded to the
directory major.minor corresponding to the appropriate release.  Packages
for NetBSD with versions such as "1.5.1" should be uploaded to the "1.5"
directory, stripping the tiny number off the directory name.  For packages
that need to be tightly coupled with the OS Version, such as LKM's, you
may create a major.minor.tiny release directory, and place those packages
therein.  Such packages should be marked with the variable
"OSVERSION_SPECIFIC=yes" to mark them in some way for binary package
builders.


###########################################################################
# Local Variables:
# mode:				Text
# fill-column:			75
# sentence-end-double-space:	nil
# End:
@


1.294
log
@Add MASTER_SITE_GNUSTEP, MASTER_SITE_R_CRAN, MASTER_SITE_SUSE,
MASTER_SITE_MOZILLA, MASTER_SITE_XEMACS, MASTER_SITE_APACHE and
MASTER_SITE_DEBIAN to the list of known master sites, and sort it.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.293 2003/05/31 19:35:16 wiz Exp $
d2301 40
a2340 43
commands. In such cases, the makefile fragment mk/texinfo.mk should be
included in the package Makefile before the inclusion of mk/bsd.pkg.mk.
Newer versions of texinfo (version 4 and above) are, unfortunately,
incompatible from previous versions at the command line level and some
extensions were introduced in the TeXinfo macro set. So the package creator
should ensure that the correct binaries are selected, rather than relying
on the contents of the PATH variable in the shell.

The main info directory file needs to be updated to reflect the
installation of info files. Some packages' installation processes take care
of this for you. Otherwise the NetBSD Packages Collection has an INFO_FILES
definition which can be used to do this. Simply use the

	INFO_FILES=	ident.info

definition in the package Makefile, where "ident.info" is the name of the
info file which installs an info dir entry.

A package creator should also take care that the package build and install
process uses the correct version of the makeinfo and install-info commands.
Some Makefiles and configure scripts from recent software packages include
the pathnames to the makeinfo and install-info commands. Unfortunately,
older software packages tend not to do this, and, should this be the case,
further action is required of the package creator.

The mk/texinfo.mk makefile fragment will ensure that the proper makeinfo
and install-info commands are available on the system as well as help the
configure and build process of the package to use known binaries for these
commands.

If a minimum version of makeinfo and install-info commands are required,
define TEXINFO_REQD in the package's Makefile to this minimum version.

If a package is not well behaved (i.e., it does not pick MAKEINFO or
INSTALL_INFO in the environment at configure or build time) you should do
one of the following, whichever is more appropriate:
 a) patch the package files so MAKEINFO or INSTALL_INFO are picked from the
    environment at configure or build time and get used instead of
    relying on makeinfo or install-info being accessible in PATH;
 b) put TEXINFO_OVERRIDE=YES in the package Makefile to let some sed
    manipulation happen on some packages source files (see contents of
    mk/texinfo.mk).

a2652 1
	.include "../../mk/texinfo.mk"
a2669 1
	@@unexec install-info --delete %D/info/bison.info %D/info/dir
a2675 1
	@@exec install-info %D/info/bison.info %D/info/dir
@


1.293
log
@Update section on how to override libtool in packages with our own version.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.292 2003/05/08 13:31:06 zuntum Exp $
d655 3
a657 1
	${MASTER_SITE_XCONTRIB}
d659 2
d662 4
d667 2
a668 3
	${MASTER_SITE_SUNSITE}
	${MASTER_SITE_GNOME}
	${MASTER_SITE_SOURCEFORGE}
@


1.292
log
@Fix example - advise user to extract pkgsrc.tar.gz into /usr
instead of /usr/pkgsrc, because the tarball has "pkgsrc" directory in it
anyway
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.291 2003/05/06 17:40:18 jmmv Exp $
d1112 5
a1116 7
Add USE_LIBTOOL=yes and LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig to the package
Makefile as the quick way to bypass the pkg's own libtool. The pkg's own
libtool is made by ltconfig script at do-configure target. If USE_LIBTOOL
and LTCONFIG_OVERRIDE are defined, the specified ltconfig is overridden,
using the pkgsrc/devel/libtool instead of the pkg's own libtool.  For newer
versions of libtool (without ltconfig) it may be necessary to use
LIBTOOL_OVERRIDE=${WRKSRC}/libtool instead.
@


1.291
log
@Drop trailing whitespace.  Ok'ed by wiz.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.290 2003/05/06 00:15:52 zuntum Exp $
d198 1
a198 1
unpack it into /usr/pkgsrc.
@


1.290
log
@Add section "Packages containing perl scripts" that discusses REPLACE_PERL

From Soren Jacobsen in PR#21469, thanks!
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.289 2003/04/04 20:15:51 jschauma Exp $
d91 1
a91 1
   corresponding package. 
d194 1
a194 1
via CVS. All three ways are described here. 
d207 1
a207 1
your system, it can be found as precompiled binary on ftp.netbsd.org. 
d211 1
a211 1
	% setenv CVS_RSH ssh 
d276 1
a276 1
in your environment.  Please note that you should use a root which is 
d326 1
a326 1
into BIN_INSTALL_FLAGS. See pkgsrc/mk/bsd.pkg.defaults.mk for more details. 
d344 1
a344 1
 
d384 1
a384 1
pkgsrc/mk/bsd.pkg.defaults.mk for details of the default settings. 
d417 1
a417 1
It is possible to configure the bulk build to perform certain site 
d428 1
a428 1
    
d432 1
a432 1
As /usr/pkg will be completely deleted at the start of bulk builds, 
d457 1
a457 1
Be sure to remove all other things that might interfere with builds, like 
d495 1
a495 1
these broken package builds later. 
d516 1
a516 1
wasted by recompiling. 
d524 1
a524 1
bulk build inside a chroot environment. 
d556 1
a556 1
If you are a developer and want to upload the resulting binary packages 
d564 1
a564 1
some places outside the sandbox if you want to make the files public. 
d585 1
a585 1
other machines.  The package pkgsrc/pkgtools/cdpack provides a simple tool for 
d688 1
a688 1
       archivers  audio      benchmarks   biology       cad     
d724 1
a724 1
transfer or altered by a malign force to introduce a security hole. 
d795 1
a795 1
pkgsrc patches are applied. 
d836 1
a836 1
   
d840 1
a840 1
   
d855 1
a855 1
timestamp files. 
d863 1
a863 1
a ${CP} command in the pre-configure target to achieve this. 
d936 1
a936 1
   any new files since the package was extracted. See below for more 
d987 1
a987 1
in a number of ways: 
d1041 1
a1041 1
independent. 
d1065 1
a1065 1
   The "-release" option will produce different results for a.out and ELF 
d1136 1
a1136 1
   The function lt_dlinit() should be called and the macro 
d1324 1
a1324 1
   distribution site or network lossage. 
d1342 1
a1342 1
   
d1351 1
a1351 1
   system calls, and library routines which are available in NetBSD. 
d1382 1
a1382 1
   (plus "install.man", if USE_IMAKE is set). 
d1417 1
a1417 1
   ignore the "already installed" flag. 
d1423 1
a1423 1
   behaviour: 
d1427 1
a1427 1
      
d1531 1
a1531 1
 * readme-all: 
d1568 1
a1568 1
   After a package is installed, check all its binaries and (on ELF 
d1575 1
a1575 1
   An attempt is made to care for shared libs etc., but it is STRONGLY 
d1590 1
a1590 1
   preserving free disk space. 
d1658 1
a1658 1
 =============================== 
d1744 1
a1744 1
 * Look at Makefile, fix if necessary; see section 4.1. 
d1753 1
a1753 1
   You usually need to be root to do this. 
d1761 1
a1761 1
   
d1765 1
a1765 1
 
d1773 1
a1773 1
 
d1820 1
a1820 1
Please note that the old 
d1855 1
a1855 1
The answer here is to do a "make fetch-list" in /usr/pkgsrc, carry the 
d1878 1
a1878 1
If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can 
d1927 1
a1927 1
   
d2004 1
a2004 1
package and any package which matches the pattern will be used. 
d2015 1
a2015 1
	DEPENDS+=        teTeX-[0-9]*:../../print/teTeX 
d2083 1
a2083 1
package's version number. If a package is already in pkgsrc at that time, 
d2086 1
a2086 1
site (beware, any mirrors may not be up to date yet!), and to remove the 
d2134 1
a2134 1
comp.tgz is part of every NetBSD release, please get the one matching 
d2149 1
a2149 1
 
d2154 1
a2154 1
 
d2159 1
a2159 1
 
d2164 1
a2164 1
 
d2242 1
a2242 1
/pub/NetBSD/packages/distfiles/vulnerabilities on ftp.netbsd.org. 
d2362 1
a2362 1
bootstrap the necessary utilities (BSD make, pkg_*, ...). See 
d2520 1
a2520 1
   guarantee that the packages don't contain any trojan horses etc. 
d2523 1
a2523 1
   the world where to get them. 
d2640 1
a2640 1
	 
d2647 1
a2647 1
	 
d2650 1
a2650 1
	 
d2719 1
a2719 1
	 
d2723 1
a2723 1
	 
d2765 1
a2765 1
	cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c 
d2896 1
a2896 1
	# 
d2952 1
a2952 1
"OSVERSION_SPECIFIC=yes" to mark them in some way for binary package 
@


1.289
log
@Add a paragraph to point out that users should use CFLAGS+= rather than
CFLAGS= in /etc/mk.conf.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.288 2003/03/25 16:24:57 salo Exp $
d2503 6
@


1.288
log
@Update section 11.1 to advise attaching new packages as uuencoded tar
archives for better tracking and archiving:

 11.1 Submitting your packages
 =============================

 ...

 * packages:
   First, check that your package is complete, compiles and runs well; see
   section 9 and the rest of this document. Next, generate an uuencoded
   gzipped tar(1) archive, preferably with all files in a single directory.
   Finally, send-pr(1) with category "pkg", a synopsis which includes the
   package name and version number, a short description of your package
   (contents of the COMMENT variable or DESCR file are OK) and attach the
   archive to your PR.

   If you want to submit several packages, please send a separate PR for
   each one, it's easier for us to track things that way.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.287 2003/02/23 10:45:39 wiz Exp $
d1924 10
@


1.287
log
@Note how USE_NCURSES should be used.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.286 2003/02/03 15:33:01 wiz Exp $
d2511 6
a2516 10
   section 9 and the rest of this document. Next, generate a gzipped
   tar-file of all the files needed for the package, preferably with all
   files in a single directory. Place this tar-file to a place where the
   package maintainers can fetch it using FTP or HTTP (WWW). Finally,
   send-pr with category "pkg", a synopsis which includes the package name
   and version number, a short description of your package
   (contents of the COMMENT variable are OK) and the URL of your tar-file.

   You will be notified if your send-pr has been addressed so you can remove
   the tar-file. 
@


1.286
log
@Fix typo in last.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.285 2003/02/03 11:13:54 jmmv Exp $
d2174 3
a2176 1
required, then define USE_NCURSES in the package's Makefile.
@


1.285
log
@Fix some typos, based on PR pkg/20178 by <soren at blef.org>.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.284 2003/01/29 08:50:11 grant Exp $
d105 1
a105 1
much typography applied here. It's beeing moved to DocBook.
@


1.284
log
@- fix a typo.
- security/smtpd (not snmpd) wants /etc/localtime.

found while marking up :)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.283 2003/01/28 22:03:00 jlam Exp $
d44 1
a44 1
by building your own copy using the NetBSD package system.  The
d105 1
a105 2
much typography applied here. Future versions may move to something like
HTML or DocBook, which have better ways theres.
d576 1
a576 1
Created binary pkgs will be in /usr/sandbox/usr/pkgsrc/packages (whereever
d608 1
a608 1
	# echo "This is a README" > /tmp/commmon/README
d1568 2
a1569 2
   After a package is installed, check all it's binaries and (on ELF 
   platforms) shared libraries if they find the shared libs they need.
d1729 1
a1729 1
 * Add any dependancies glimpsed from the configure step to the package's
d2002 1
a2002 1
to be able to execute the latex binary from the teTex package when it runs,
d2005 1
a2005 1
	DEPENDS+=        teTex-[0-9]*:../../print/teTeX 
d2271 1
a2271 1
optimsation being enabled.  Common symptoms are gcc internal errors
d2315 1
a2315 1
define TEXINFO_REQD in the package's Makefile to this mininum version.
@


1.283
log
@Instead of including bsd.pkg.install.mk directly in a package Makefile,
have it be automatically included by bsd.pkg.mk if USE_PKGINSTALL is set
to "YES".  This enforces the requirement that bsd.pkg.install.mk be
included at the end of a package Makefile.  Idea suggested by Julio M.
Merino Vidal <jmmv at menta.net>.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.282 2003/01/22 19:22:05 jdolecek Exp $
d530 1
a530 1
items are present and properly configures:
d536 1
a536 1
 * /etc/resolv.conf (for security/snmpd and mail):
d540 1
a540 1
 * /etc/localtime (for security/snmpd):
@


1.282
log
@add missing dot
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.281 2003/01/19 17:38:40 jschauma Exp $
d2259 3
a2261 3
The package Makefile must also include "../../mk/bsd.pkg.install.mk" prior to
the inclusion of bsd.pkg.mk.  This will cause the users and groups to be
created at pre-install time, and the admin will be prompted to remove them at
d2408 4
a2411 5
created automatically.  The package Makefile must also include
"../../mk/bsd.pkg.install.mk" prior to the inclusion of bsd.pkg.mk to use
these automatically generated scripts.  The automatic copying of config
files can be toggled by setting the environment variable PKG_CONFIG prior
to package installation.
d2429 3
a2431 3
by this package. The package Makefile also must include
"../../mk/bsd.pkg.install.mk" prior to the inclusion of bsd.pkg.mk to use the
automatically generated INSTALL/DEINSTALL scripts.
d2435 1
a2436 1
	.include "../../mk/bsd.pkg.install.mk"
d2439 2
a2440 2
post-install target by the INSTALL script generated by bsd.pkg.install.mk and
removed in the deinstall target by the DEINSTALL script.
@


1.281
log
@Update some info for bootstrap-pkgsrc.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.280 2003/01/10 17:26:35 jschauma Exp $
d1857 1
a1857 1
resulting list to your machine at work/school and use it there If you don't
@


1.280
log
@Remove references to obsolete variables EXTRACT_BEFORE_ARGS and
EXTRACT_AFTER_ARGS.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.279 2003/01/10 11:58:02 agc Exp $
d2347 2
a2348 2
 10.26 Using pkgsrc on non-NetBSD (Linux, Solaris, Darwin, MacOS X)
 ==================================================================
d2352 4
a2355 1
http://www.zoularis.org/ for information on boostrapping.
@


1.279
log
@Document PKG_PRESERVE, the capability of a package to specify that it should
not be deleted.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.278 2003/01/04 16:04:06 wiz Exp $
d1333 1
a1333 2
   extracted by setting EXTRACT_CMD, EXTRACT_BEFORE_ARGS and/or
   EXTRACT_AFTER_ARGS. 
a1809 2
	EXTRACT_BEFORE_ARGS=
	EXTRACT_AFTER_ARGS=     |sh
@


1.278
log
@Reinstate duplicate word -- it is correct here.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.277 2003/01/04 14:31:57 grant Exp $
d2482 10
@


1.277
log
@remove a duplicate word.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.276 2003/01/02 06:18:48 grant Exp $
d413 1
a413 1
which user to su(8) to do a 'cvs update'.
@


1.276
log
@add to PLIST issues:
* LOWER_OPSYS.
* platform specific PLIST handling.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.275 2002/12/27 06:53:42 uebayasi Exp $
d413 1
a413 1
which user to su(8) to to do a 'cvs update'.
@


1.275
log
@* Garbage collect IGNORE -> SKIP migration.

* {NOT,ONLY}_FOR_PLATHOME mismatch is not an error.  Set
  PKG_SKIP_REASON for those cases.  This makes bulk builds happier.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.274 2002/12/10 15:02:24 schmonz Exp $
d898 1
a898 1
 * ${OPSYS}, ${OS_VERSION}:
d900 5
a904 3
   to do this, use these two variables in PLIST. ${OPSYS} will be replaced
   by output from "uname -s", ${OS_VERSION} will be set to what "uname -r"
   gives.
d920 14
@


1.274
log
@ 10.31 Packages that cannot or should not be built
 =================================================

There are several reasons why a package might be instructed to not
build under certain circumstances. If the package builds and runs
on most platforms, the exceptions should be noted with NOT_FOR_PLATFORM.
If the package builds and runs on a small handful of platforms,
set ONLY_FOR_PLATFORM instead. If the package should be skipped
(for example, because it provides functionality already provided
by the system), set PKG_SKIP_REASON to a descriptive message. If
the package should fail because some preconditions are not met,
set PKG_FAIL_REASON to a descriptive message.

IGNORE is deprecated because it didn't provide enough information
to determine whether the build should fail.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.273 2002/12/03 10:51:47 hubertf Exp $
d1869 1
a1869 1
	% make fetch NO_IGNORE=yes
@


1.273
log
@document how to use sudo with pkgsrc
(for just-in-time-su(1) password caching)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.272 2002/11/28 14:21:32 salo Exp $
d2449 17
@


1.272
log
@Introduce new framework for handling packages' locale directories.

The logic is:
 - if package defines USE_PKGLOCALEDIR and PKGLOCALEDIR is not 'share' as GNU
   autotools expects then
 - fix variables 'localedir', 'gnulocaledir' and define coorect 'LOCALEDIR' in
   the Makefile.in.* files

From Packages.txt:

 10.29 Packages providing locale catalogues
 ==========================================

If the package provides its own locale catalogues, the variable
USE_PKGLOCALEDIR should be defined.  It will ensure that the package's
Makefile template files are fixed and point to the correct locale directories
(which may vary, depending on OS), if necessary.  See also section 5.1 for
details about ${PKGLOCALEDIR}.  This functionality is buildlink2-only.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.271 2002/11/17 09:00:30 salo Exp $
d2436 13
@


1.271
log
@Document PKG_REGISTER_SHELLS framework.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.270 2002/11/08 09:29:14 wiz Exp $
d2426 10
@


1.270
log
@Fix typo reported by Julio Merino in PR 18967.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.269 2002/11/04 13:00:51 seb Exp $
d2407 19
@


1.269
log
@Mention pkgsrc/mk/auto{conf,make}.mk in section 6.4 and fix examples.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.268 2002/10/27 21:54:05 seb Exp $
d392 1
a392 1
    BSDXSRCDIR=             /usr/xsrc         # for x11/xervers
@


1.268
log
@Add a note about perl5/module.mk.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.267 2002/10/24 04:52:15 jlam Exp $
d1130 8
a1137 2
be executed in a pre-configure target.  For packages that need only
autoconf:
d1140 4
a1143 1
		cd ${WRKSRC}; ${LOCALBASE}/bin/autoconf
d1147 3
d1152 7
a1158 4
		${LOCALBASE}/bin/aclocal;				\
		${LOCALBASE}/bin/autoheader;				\
		${LOCALBASE}/bin/automake -a --foreign -i;		\
		${LOCALBASE}/bin/autoconf
@


1.267
log
@Refer readers to the text files in mk/buildlink2 for more information that
isn't appropriate for Packages.txt, and change the way the dotted list
appears to look more like the rest of Packages.txt.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.266 2002/10/23 19:21:18 jlam Exp $
d947 6
@


1.266
log
@Replace buildlink1 section with a buildlink2 section.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.265 2002/10/23 12:21:29 wiz Exp $
d1586 3
a1588 1
installed.
d1604 1
a1604 1
circumstances.
d1606 2
a1607 2
 (*) motif.buildlink2.mk checks for a system-provided Motif installation
     or adds a dependency on x11/lesstif or x11/openmotif;
d1609 2
a1610 2
 (*) ossaudio.buildlink2.mk defines several variables that may be used by
     packages that use the Open Sound System (OSS) API;
d1612 2
a1613 2
 (*) pthread.buildlink2.mk uses the value of PTHREAD_OPTS and checks for
     native pthreads or adds a dependency on devel/pth as needed;
d1615 2
a1616 2
 (*) xaw.buildlink2.mk uses the value of XAW_TYPE to choose a particular
     Athena widgets library.
@


1.265
log
@Remove USE_LIBINTL and _DO_LIBINTL_CHECKS, which have been replaced
by devel/gettext-lib/buildlink2.mk.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.264 2002/10/21 13:58:14 wiz Exp $
d1570 30
a1599 2
 8 buildlink.mk methodology
 ==========================
d1601 2
a1602 3
Many packages that install libraries and headers for use in other packages
now have buildlink.mk files in their pkgsrc subdirectory.  The purpose of
these files is two-fold:
d1604 2
a1605 3
 (1) Cause all headers and libraries used by a particular package to be
     found in a known location during the configure and build process.
     These packages are said to be "weakly-buildlinked".
d1607 2
a1608 3
 (2) Cause _only_ those headers and libraries used by a particular package
     to be found during the configure and build process.
     These packages are said to be "strongly-buildlinked".
d1610 2
d1613 2
a1614 2
 8.1 Using buildlink.mk files
 ============================
d1616 2
a1617 2
Goal (1) is accomplished by simply including the buildlink.mk file of a
dependency in the package's Makefile, which does the following:
a1618 1
 (1a) Adds a DEPENDS or BUILD_DEPENDS line for the package;
d1620 2
a1621 2
 (1b) Creates a directory ${BUILDLINK_DIR}, by default set to a
      subdirectory of ${WRKDIR};
d1623 2
a1624 30
 (1c) Links all the headers and libraries for that dependency into
      ${BUILDLINK_DIR}/include and ${BUILDLINK_DIR}/lib, respectively;

 (1d) Prepends -I${BUILDLINK_DIR}/include to CPPFLAGS, CFLAGS, CXXFLAGS,
      and -L${BUILDLINK_DIR}/lib to LDFLAGS;

 (1e) Creates a wrapper script for GTK+-style config scripts, often found
      in GNOME software, that translates -I${LOCALBASE}/include and
      -L${LOCALBASE}/lib into references into ${BUILDLINK_DIR}.

Some packages are for software libraries whose functionality is a part of
recent released versions of NetBSD, e.g. readline, OpenSSL, and ncurses.
For those packages, the buildlink.mk files link the appropriate system
headers and libraries into ${BUILDLINK_DIR} so that goal (1) is still met.
Where possible, the system headers and libraries are renamed when linked
into ${BUILDLINK_DIR} to match the names of their pkgsrc counterparts so
that the files may be referenced under a consistent name.

Goal (2) requires some work on the part of the package builder.  As all
headers and libraries used by a package may be found in ${BUILDLINK_DIR},
and -I${BUILDLINK_DIR}/include and -L${BUILDLINK_DIR}/lib are already passed
to the compiler, it is no longer necessary to pass -I${LOCALBASE}/include or
-L${LOCALBASE}/lib to the compiler.  Therefore, those lines should be removed
from package Makefiles, and where necessary, the package sources should be
patched to do the same.  Also, if a package uses X11, then by including
mk/x11.buildlink.mk, -I${BUILDLINK_X11_DIR}/include and
-L${BUILDLINK_X11_DIR}/lib are also passed to the compiler instead of the
corresponding directories in ${X11BASE}.  Also, if USE_BUILDLINK_ONLY is
defined, then -L${LOCALBASE}/lib is not automatically added to LDFLAGS in
bsd.pkg.mk.
d1626 4
d1631 5
a1635 2
 8.2 Writing buildlink.mk files
 ==============================
d1637 1
a1637 5
Most of the work done by buildlink.mk files is encapsulated and shared
through bsd.buildlink.mk, which is included by packages' buildlink.mk files.
Please see the comments at the top of bsd.buildlink.mk for complete
documentation on how to use the file.  A simple example of a buildlink.mk
for a mythical package foo follows:
a1638 16
	.include "../../mk/bsd.buildlink.mk"
	
	BUILDLINK_DEPENDS.foo?=	foo>=1.0
	DEPENDS+=			${BUILDLINK_DEPENDS.foo}:../../category/foo
	
	EVAL_PREFIX+=			BUILDLINK_PREFIX.foo=foo
	BUILDLINK_FILES.foo=		include/foo.h
	BUILDLINK_FILES.foo+=		include/bar.h
	BUILDLINK_FILES.foo+=		lib/libfoo.*
	
	# We need the libraries to be called "libbar.*".
	BUILDLINK_TRANSFORM.foo=	-e "s|libfoo|libbar|g"
	
	BUILDLINK_TARGETS+=		foo-buildlink
	
	pre-configure: foo-buildlink
d1641 8
d1650 19
a1668 2
 8.3 Converting packages to use buildlink.mk files
 =================================================
d1670 3
a1672 48
The process of converting existing packages to use the buildlink.mk
infrastructure is fairly straightforward.  If a dependency on a particular
package is required for its libraries and headers, then rather than
directly adding a dependency on that package, include that package's
buildlink.mk instead.  The following variables may also be replaced with
buildlink.mk files:

    USE_X11	-->	.include "../../mk/x11.buildlink.mk"

Packages that have an explicit dependency on ncurses should set USE_NCURSES
to the reason why the system curses is insufficient, and include
"../../devel/ncurses/buildlink.mk" afterwards.  This helps to identify
where the system curses differs from ncurses, and when the development of
the system curses catches up in functionality, the USE_NCURSES setting may
be removed.

Package that need a Motif-1.2-compatible installation should define
USE_MOTIF12, otherwise assume the need for a Motif-2.0-compatible
installation.  If MOTIFBASE or MOTIF12BASE is set, then it is assumed that
they point to valid 2.0-compatible or 1.2-compatible Motif, respectively.

Packages that use OpenSSL that require a specific version of OpenSSL should
define USE_OPENSSL_VERSION to the minimum version number required prior to
including "../../security/openssl/buildlink.mk".  The version number is the
hexadecimal number found in <openssl/opensslv.h>, or the variables
OPENSSL_VERSION_{095A,096,096A,096B} may be used.

The use of EVAL_PREFIX to find the installation prefix for packages may be
removed since references to package library and header files are found
through ${BUILDLINK_DIR}.  If the required dependency pattern for a package
differs from the default specified in the package's buildlink.mk file, then
it may be set by defining BUILDLINK_DEPENDS.<pkgname> in the Makefile to
the dependency pattern required.

Packages will still need LDFLAGS to be set to include the appropriate rpath
settings in order for built packages to find libraries.  LDFLAGS should
still contain -Wl,-R${LOCALBASE}/lib, and -Wl,-R${X11BASE}/lib if the
package requires the X11 libraries.  -Wl,-R should never refer to a
${BUILDLINK_DIR} library directory, and all such references should be
purged from the build.

A package that builds correctly with USE_BUILDLINK_ONLY set should have
that setting added to its Makefile to note that it doesn't use any
libraries or headers in ${LOCALBASE} directly, but rather references them
only through ${BUILDLINK_DIR}.  Note that you MUST check the build output
to verify that no references to ${LOCALBASE} directories occurred during
the configure or build process, or else the package cannot be marked as
USE_BUILDLINK_ONLY.
d1926 1
a1926 1
buildlink.mk (see section 8).
d2136 1
a2136 1
If ../../devel/ncurses/buildlink.mk is included in a package's Makefile,
d2138 2
a2139 5
into ${BUILDLINK_DIR} at pre-configure time.  If ncurses is needed, then a
dependency on ncurses is added to the package, otherwise, if the system
curses is sufficient, then the library and headers are linked into
${BUILDLINK_DIR} with ncurses names.  If ncurses is actually required, then
define USE_NCURSES in the package's Makefile.
@


1.264
log
@Purge unused USE_XPM (use graphics/xpm/buildlink2.mk instead).
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.263 2002/10/21 01:21:46 wiz Exp $
a1666 1
    USE_LIBINTL	-->	.include "../../devel/gettext-lib/buildlink.mk"
@


1.263
log
@Update description of how to use libltdl, and remove some USE_* mentions
for USE_* which do not exist any longer.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.262 2002/09/19 12:48:04 lukem Exp $
a1668 1
    USE_XPM	-->	.include "../../graphics/xpm/buildlink.mk"
@


1.262
log
@doc/pkg-CHANGES is now pkgsrc/doc/CHANGES
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.261 2002/08/26 05:17:39 jlam Exp $
d1101 1
a1101 1
add USE_LTDL= yes to the Makefile.
a1667 3
    USE_LTDL	-->	.include "../../devel/libtool/buildlink.mk"
    USE_MESA	-->	.include "../../graphics/Mesa/buildlink.mk"
    USE_MOTIF	-->	.include "../../mk/motif.buildlink.mk"
a1668 1
    USE_XAW	-->	.include "../../mk/xaw.buildlink.mk"
@


1.261
log
@PKG_SYSCONFDIR is not supposed to be settable, so change its setting from
?= to =.  Note in Packages.txt that the only variables that a user should
customize in /etc/mk.conf are PKG_SYSCONFBASE and PKG_SYSCONFDIR.<pkg>.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.260 2002/08/12 14:23:47 agc Exp $
d2485 1
a2485 1
Please note all package updates/additions in doc/pkg-CHANGES! It's very
@


1.260
log
@Remove the setting of BATCH=yes and DEPENDS_TARGET=bulk-install from
the example mk.conf for bulk builds, since these are now set by the
bulk build machinery itself.  This allows an /etc/mk.conf file to be
shared between ordinary builds and bulk builds.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.259 2002/07/29 21:10:18 wiz Exp $
d1161 1
a1161 1
  of ${PKG_SYSCONFBASE}.
d1163 10
a1172 7
* PKG_SYSCONFDIR.${PKGBASE} overrides the value of ${PKG_SYSCONFDIR} for a
  particular package.  This is not meant to be set by a package Makefile, but
  is reserved for users who wish to override the PKG_SYSCONFDIR setting for
  a particular package with a special location.

Users will typically want to set PKG_SYSCONFBASE to /etc, or to accept the
default location of ${PREFIX}/etc.
@


1.259
log
@Add a paragraph on how to move a package in the repository.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.258 2002/07/04 13:42:11 hubertf Exp $
a388 1
    DEPENDS_TARGET?=        bulk-install
a393 1
    BATCH=                  yes               # required for bulk builds 
d396 1
a396 1
    _ACCEPTABLE=            yes               # XXX
@


1.258
log
@fix typo
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.257 2002/07/02 15:25:49 wiz Exp $
d2519 23
@


1.257
log
@Deprecate USE_SSL.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.256 2002/07/02 11:26:05 agc Exp $
d398 1
a398 1
    _ACCEPTABLE_LICENSES=   yes               # XXX
@


1.256
log
@Deprecate IS_INTERACTIVE, and introduce a finer-grained INTERACTIVE_STAGE
definition.

INTERACTIVE_STAGE can take any of the values: fetch, configure, build and
install

Multiple values are allowed: e.g. INTERACTIVE_STAGE= configure install

Explain INTERACTIVE_STAGE and its use in documentation.

Patches provided by Chris Pinnock (cjep@@netbsd.org).
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.255 2002/06/30 03:52:32 rh Exp $
a1669 1
    USE_SSL	-->	.include "../../security/openssl/buildlink.mk"
@


1.255
log
@Give an example on how to ensure the tree is clean for packages and
prerequisites to be updated.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.254 2002/06/30 03:43:43 rh Exp $
d963 22
@


1.254
log
@Sync the description of DEPENDS_TARGET w/ reality and explain why
UPDATE_TARGET is the recommended way of modifying the target to be used for
'make update'.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.253 2002/06/27 09:50:42 hubertf Exp $
d1435 14
a1448 3
   (e.g., if you used NOCLEAN).  The following variables can be used
   either on the command line or in /etc/mk.conf to alter the behaviour
   of "make clean-update":
@


1.253
log
@Tweak:
 - cut and paste read instructions for setting (most of) chroot sandbox
 - add mk.conf frob for accepting all licenses (in bulk build code only! ;)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.252 2002/06/25 21:21:44 agc Exp $
d1383 1
a1383 1
   "make install" (or whatever DEPENDS_TARGET is set to) for these packages.
d1400 5
a1404 4
    - DEPENDS_TARGET:
      Install target to use for the updated package and the
      dependent packages.  Defaults to "install".  E.g.
      "make update DEPENDS_TARGET=package"
d1418 8
@


1.252
log
@It's OBJHOSTNAME, not OBJHOST.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.251 2002/06/20 20:15:46 jlam Exp $
d398 1
a398 10
    ACCEPTABLE_LICENSES=    shareware \
                            fee-based-commercial-use \
			    mosaic-license \
                            no-profit \
                            no-commercial-use \
                            non-commercial-use \
                            limited-redistribution \
			    kermit-license \
			    sun-swing-license \
			    sun-jsdk20-license
d534 16
a549 7
 * kernel (/netbsd)
 * /dev/* (cd /usr/sandbox/dev ; sh MAKEDEV all)
 * /etc/resolv.conf (for security/snmpd and mail)
 * working(!) mail config (hostname, sendmail.cf)
 * /etc/localtime (for security/snmpd)
 * /usr/src (system sources, for sysutils/aperture, net/ppp-mppe)
 * create /var/db/pkg (not part of default install)
d551 1
d553 1
@


1.251
log
@In order to solve the following problems:

    (1) Admins want to create users/groups on their own (pkg/17183).
    (2) Admins don't want packages to setup an initial configuration.

The bsd.pkg.install.mk-generated INSTALL/DEINSTALL scripts have been
modified to check certain PKG_* environment variables to tune their
behaviour.  This works whether installing from "make install" or from a
binary package.

PKG_CREATE_USERGROUP indicates whether the INSTALL script should
	automatically add any needed users/groups to the system using
	useradd/groupadd.  It is either YES or NO, and defaults to YES.

PKG_CONFIG indicates whether the INSTALL/DEINSTALL scripts should do
	automatic config file and directory handling, or if it should
	merely inform the admin of the list of required files and
	directories needed to use the package.  It is either YES or NO,
	and defaults to YES.

The make(1) variable INSTALL_RCD_SCRIPTS is removed.  The package rc.d
script is now handled like other config files for the package, and is
copied into place if PKG_CONFIG=YES.

The default values above reflect the current behaviour.  Setting
PKG_CREATE_USERGROUP=NO solves problem (1), and setting PKG_CONFIG=NO
solves problem (2).

To simply matters for users installing directly from pkgsrc, these
variables may also be defined in /etc/mk.conf, but behaviour at deinstall
time may be surprising.  It is *HIGHLY* recommended that these values be
set in the shell environment instead.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.250 2002/06/18 16:14:54 agc Exp $
d394 1
a394 1
    OBJHOST?=               yes               # use work.`hostname`
@


1.250
log
@Document "PKG_DEBUG_LEVEL" definition, and also mention "make show-var
VARNAME=..."
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.249 2002/06/17 21:46:04 skrll Exp $
d2226 3
a2228 1
post-deinstall time.
d2368 6
a2373 2
files in the right directory (using INSTALL/DEINSTALL scripts which are
created automatically).
@


1.249
log
@Improve the wording around GNU autoconf.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.248 2002/06/17 09:51:27 wiz Exp $
d298 21
@


1.248
log
@Add a paragraph: packages that are uploaded to ftp.netbsd.org should be
built against the default X version for that release and architecture,
which is currently 3.3.6 for all architectures. Addresses pkg/16492.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.247 2002/05/30 22:55:21 schmonz Exp $
d870 2
a871 2
   is embedded in PLIST somewhere - use this on packages that use GNU
   autoconfigure.
d1726 2
a1727 2
 10.1 Packages using GNU autoconfig
 ==================================
d1729 2
a1730 2
If your package uses GNU autoconf, add the following to your package's
Makefile:
@


1.247
log
@Explain why we prefer "cvs import" for new packages, paraphrased from agc.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.246 2002/05/22 23:30:21 hubertf Exp $
d536 3
@


1.246
log
@Document config file handling.

Contributed by Julio Merino <jmmv@@hispabsd.org> in PR 16971,
with minor editing by myself.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.245 2002/05/19 08:52:17 zuntum Exp $
d2415 4
@


1.245
log
@Add missing verb.

Fixes PR#16892 by Julio Merino <jmmv@@hispabsd.org>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.244 2002/04/27 02:42:22 enami Exp $
d2291 63
@


1.244
log
@Shorter command to generate a TOC.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.243 2002/04/13 12:59:52 wiz Exp $
d514 1
a514 1
for anything but pkg compiling), there the possibility of doing the pkg
@


1.244.2.1
log
@Merge from pkgsrc-current to buildlink2 branch.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.251 2002/06/20 20:15:46 jlam Exp $
a298 21
Occasionally, people want to "look under the covers" to see what is
going on when a package is building or being installed. This may be
for debugging purposes, or out of simple curiosity. A number of utility
values have been added to help with this.

(1) If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a
huge amount of information will be displayed.  As a worked example,

	make patch PKG_DEBUG_LEVEL=2

will show all the commands that are invoked, up to and including the
"patch stage".

(2) If you want to know the value of a certain make(1) definition, then
the VARNAME definition should be used, in conjunction with the show-var
target. e.g.

	make show-var VARNAME=DISTFILES

will show the expansion of the make(1) variable "DISTFILES".

d514 1
a514 1
for anything but pkg compiling), there is the possibility of doing the pkg
a535 3
If you are a developer and want to upload the resulting binary packages 
to ftp.netbsd.org, make sure you are using the default X version for your
architecture and release (up to 1.6, that is 3.3.6 for all architectures).
d867 2
a868 2
   is embedded in PLIST somewhere - use this on packages that have GNU
   autoconf created configure scripts.
d1723 2
a1724 2
 10.1 Packages using GNU autoconf
 ================================
d1726 2
a1727 2
If your package uses GNU autoconf created configure scripts, add the following
to your package's Makefile:
d2202 1
a2202 3
post-deinstall time.  Automatic creation of the users and groups can be
toggled on and off by setting the environment variable PKG_CREATE_USERGROUP
prior to package installation.
a2292 67
 10.27 Configuration files handling and placement
 ================================================

The global variable PKG_SYSCONFBASE (and some others) can be set by the
system administrator in /etc/mk.conf to define the place where
configuration files get installed. Therefore, packages must be adapted to
support this feature. Keep in mind that you should only install files that
are strictly necessary in the configuration directory, files that can
go to $PREFIX/share should go there.

We will take a look at available variables first (bsd.pkg.mk contains more
information). PKG_SYSCONFDIR is where the configuration files for a package
may be found (that is, the full path, e.g. /etc or /usr/pkg/etc). This
value may be customized in various ways:

 1) PKG_SYSCONFBASE is the main config directory under which all package
    configuration files are to be found. Users will typically want to set
    it to /etc, or accept the default location of $PREFIX/etc.

 2) PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which
    the configuration files for a particular package may be found. Defaults
    to $SYSCONFBASE

 3) PKG_SYSCONFVAR is the special suffix used to distinguish any overriding
    values for a particular package (see next item). It defaults to
    ${PKGBASE}, but for a collection of related packages that should all
    have the same PKG_SYSCONFDIR value, it can be set in each of the
    package Makefiles to a common value.

 4) PKG_SYSCONFDIR.${PKG_SYSCONFVAR} overrides the value of
    ${PKG_SYSCONFDIR} for packages with the same value for PKG_SYSCONFVAR.

    As an example, all the various KDE packages may want to set
    PKG_SYSCONFVAR to "kde" so admins can set ${PKG_SYSCONFDIR.kde} in
    /etc/mk.conf to define where to install KDE config files.

Programs' configuration directory should be defined during the configure
stage. Packages that use GNU autoconf can usually do this by using the
--sysconfdir parameter, but this brings some problems as we will see now.
When you change this pathname in packages, you should not allow them to
install files in that directory directly. Instead they need to install
those files under share/examples/${PKGNAME} so PLIST can register them.

Once you have the required configuration files in place (under the
share/examples directory) the variable CONF_FILES should be set to copy
them into PKG_SYSCONFDIR. The contents of this variable is formed by pairs
of filenames; the first element of the pair specifies the file inside the
examples directory (registered by PLIST) and the second element specifies
the target file. This is done this way to allow binary packages to place
files in the right directory using INSTALL/DEINSTALL scripts which are
created automatically.  The package Makefile must also include
"../../mk/bsd.pkg.install.mk" prior to the inclusion of bsd.pkg.mk to use
these automatically generated scripts.  The automatic copying of config
files can be toggled by setting the environment variable PKG_CONFIG prior
to package installation.

Here is an example, taken from mail/mutt/Makefile:

	EGDIR=	${PREFIX}/share/doc/mutt/samples
	CONF_FILES=	${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc

As you can see, this package installs configuration files inside EGDIR,
which are registered by PLIST. After that, the variable CONF_FILES lists
the installed file first and then the target file. Users will also get an
automatic message when files are installed using this method.


a2351 4

For new packages, "cvs import" is preferred to "cvs add" because
the former gets everything with a single command, and provides a
consistent tag.
@


1.243
log
@Fix reference to section 8 to point to section 9 instead.
By Julio Merino from pkg/16333.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.242 2002/04/02 21:04:31 seb Exp $
d16 1
a16 1
 grep -B1 '^.====' Packages.txt | egrep -v '^.[-=]'
@


1.242
log
@If it is `respectively' then I guess that `2.0-compatible' and
`1.2-compatible' should be inverted.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.241 2002/03/27 20:50:33 rh Exp $
d2310 1
a2310 1
   section 8 and the rest of this document. Next, generate a gzipped
@


1.241
log
@Make it explicit that the warning about mixing LOCALBASE with the rest of
the system applies both ways, i.e., don't set LOCALBASE to where you have
your system files, *and vice versa*, as this repeatetly has lead to
problems (see PRs 15999 and 16029 for the latest examples).
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.240 2002/03/23 22:52:32 hubertf Exp $
d1617 1
a1617 1
they point to valid 1.2-compatible or 2.0-compatible Motif, respectively.
@


1.240
log
@remove some stuff accidentally committed in rev. 1.237
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.239 2002/03/23 22:47:45 hubertf Exp $
d279 9
a287 6
and use LOCALBASE=/usr).  This is to prevent possible conflicts between
programs and other files installed by the package system and whatever else
may have been installed there.  There is, of course, one exception to 
this - X11 packages are traditionally installed in the X11 tree. The
definition used to identify the root of the X11 tree is the X11BASE
definition.
@


1.239
log
@ * bulk build setup: document a few variables
 * sort order of things to do to setup bulk build sandbox
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.238 2002/03/23 15:33:15 hubertf Exp $
a249 5

If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES
and a 'make fetch' will call files/getsite.sh with the name of each file
to download as an argument, expecting it to output the URL of the directory
from which to download it. graphics/ns-cult3d is an example of this usage.
@


1.238
log
@Add:
10.26 Using pkgsrc on non-NetBSD (Linux, Solaris, Darwin, MacOS X)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.237 2002/03/13 06:30:12 hubertf Exp $
a369 1
    BATCH=                  yes          # required for bulk builds 
d372 3
d376 1
a376 1
    WRKOBJDIR?=             /usr/tmp/pkgsrc   # build here instead of in pkgsrc
d526 1
a528 1
 * /etc/resolv.conf (for security/snmpd)
d531 1
d534 1
@


1.237
log
@Move documentation where it belongs.
Add paragraph "Setting up a sandbox for chroot'ed build" to
Packages.txt and xref it from do-sandbox-build script
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.236 2002/03/11 19:19:18 fredb Exp $
d2281 8
@


1.236
log
@Give the new section a *unique* number, and be consistent about use of
blank lines.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.235 2002/03/11 19:12:07 fredb Exp $
d251 5
d508 45
@


1.235
log
@Move the DYNAMIC_MASTER_SITES explanation into it's own subsection of
Section 10, and also explain there about _FETCH_MESSAGE. There are a few
things in Section 10 which would probably be better in Section 2, but that
would entail some major churning, which I'm not prepared to do.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.234 2002/02/18 17:07:20 wiz Exp $
d2166 1
d2214 2
a2215 1
 10.24 Packages whose distfiles aren't available for plain downloading
a2318 1

@


1.234
log
@Grammar improvements.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.233 2002/02/18 16:40:34 seb Exp $
a250 5
If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES
and a 'make fetch' will call files/getsite.sh with the name of each file
to download as an argument, expecting it to output the URL of the directory
from which to download it. graphics/ns-cult3d is an example of this usage.

d2212 18
@


1.233
log
@Document handling of info files, makeinfo and install-info commands with
mk/texinfo.mk.
(Something went wrong, this should have been in my last commit about TeXinfo
and all.)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.232 2002/02/15 09:33:43 skrll Exp $
d2175 2
a2176 2
commands. In such cases, the makefile fragment mk/texinfo.mk should be included
in the package Makefile before the inclusion of mk/bsd.pkg.mk.
d2178 1
a2178 1
incompatible, at the command line level, from previous versions and some
d2180 2
a2181 2
should ensure that the correct binaries are selected, rather than relying on
the contents of the PATH variable in the shell.
d2183 3
a2185 3
The main info directory file needs to be updated to reflect the installation
of the info files. Some package's installation process take care of this
for you. Otherwise the NetBSD Packages Collection has an INFO_FILES 
d2190 2
a2191 2
definition in the package Makefile, where "ident.info" is the name of the info
file which installs an info dir entry.
d2193 6
a2198 6
A package creator should also take care that the package build and
install process uses correct version of the makeinfo and install-info commands.
Some Makefiles and configure scripts from recent software packages include the
pathnames to the makeinfo and install-info commands. Unfortunately, older
software packages tend not to do this, and, should this be the case, further
action is required of the package creator.
d2200 2
a2201 2
The mk/texinfo.mk makefile fragment will ensure that proper makeinfo and
install-info commands are available on the system as well as help to the
d2205 1
a2205 1
If a minimum version of makeinfo and install-info commands are required
d2208 3
a2210 3
If a package is not well behaved (i.e. it does not pick MAKEINFO or
INSTALL_INFO in the environment at configure or build time) you should
- whatever is more appropriate:
d2214 3
a2216 2
 b) put TEXINFO_OVERRIDE=YES in the package Makefile to let some
    sed manipulation on some packages source files (see mk/texinfo.mk content).
@


1.232
log
@s/NetBSD/Pkgsrc/ in the libtool section. The use of libtool is not limited
to NetBSD only.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.231 2002/02/13 23:29:37 hubertf Exp $
d635 2
a636 11
 - If the package installs any info files, the main info directory file
   needs to be updated to reflect this fact. NetBSD has an INFO_FILES
   definition, which is used to do this. For example, to install the
   indent.info entry into the info directory file, simply use the

	INFO_FILES=	indent.info

   definition in the package Makefile. If the package does this insertion
   for you, you should specify USE_GTEXINFO in the package Makefile, to
   ensure that the pre-requisite GNU texinfo package is installed on your
   system.
d2171 45
d2336 1
@


1.231
log
@s/sysctl/uname/, pointed out by Klaus Klein
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.230 2002/02/13 20:05:02 abs Exp $
d928 1
a928 1
NetBSD supports many different machines, with different object formats
@


1.230
log
@Implement DYNAMIC_MASTER_SITES
If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES
and a 'make fetch' will call files/getsite.sh with the name of each file
to download as an argument, expecting it to output the URL of the directory
from which to download it. graphics/ns-cult3d is an example of this usage.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.229 2002/02/13 12:30:52 mjl Exp $
d130 5
a134 5
subdirectory there as indicated by "sysctl hw.machine_arch". In that
directory, there is a subdirectory for each category plus a subdirectory
"All" which includes the actual binaries in .tgz-files. The category
subdirectories use symbolic links to those files. (This is the same
directory layout as in /usr/pkgsrc/packages).
d155 2
a156 2
If there is any doubt, the sysctl utility can be used to determine the
<OS Ver>, and <arch> by running "sysctl kern.osrelease hw.machine_arch".
d828 3
a830 3
   what "sysctl -n hw.machine_arch" gives. The same is done if the string
   ${MACHINE_GNU_ARCH} is embedded in PLIST somewhere - use this on
   packages that use GNU autoconfigure.
d2588 2
a2589 2
    `uname -r | sed 's@@\.\([0-9]*\)[\._].*@@\.\1@@'`/`sysctl -n hw.machine_arch`
 - if necessary ln -s `sysctl -n hw.machine` `sysctl -n hw.machine_arch`
@


1.229
log
@Typo fix
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.228 2002/02/12 09:36:00 skrll Exp $
d250 5
@


1.228
log
@Update the AUTOMAKE_OVERRIDE part (its on by default now) with a word of
warning that it may cause problems.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.227 2002/02/12 09:29:56 skrll Exp $
d930 1
a930 1
libraries from a set our source files, thus being platform
@


1.227
log
@Clarify the automake/conf description slightly.

autoreconf will call aclocal if necessary and as this is part of automake
so its wrong to describe it as the autoconf only option. Change autoreconf
to autoconf.

Also explictly mark the automake example as "automake and autoconf".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.226 2002/01/11 14:41:41 agc Exp $
d1052 3
a1054 2
the automake sequence.  This may be overridden by setting AUTOMAKE_OVERRIDE
to YES in the package Makefile.
@


1.226
log
@Add and document a new OBJHOSTNAME definition.

If set, the first component of the hostname (up to the first '.', if any),
will be appended to "work." to form the WRKDIR_BASENAME.

OBJHOSTNAME takes precedence over OBJMACHINE.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.225 2002/01/06 21:48:40 fredb Exp $
d1039 1
a1039 1
		cd ${WRKSRC}; ${LOCALBASE}/bin/autoreconf --force
d1041 1
a1041 1
and for packages that need automake:
@


1.225
log
@Document recent changes to the fetch targets, especially ${SITES_foo}.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.224 2001/12/31 14:58:46 lukem Exp $
d368 1
a368 1
    OBJMACHINE?=            1                 # use work.${MACHINE_ARCH}
@


1.224
log
@no point in having two 10.22's
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.223 2001/12/31 14:09:15 abs Exp $
d598 11
a608 3
If the package has multiple DISTFILES from different MASTER_SITES, set
	MASTER_SITE_name_of_file-0.1.2.tar.gz=	ftp://some.url/path/
for all except the first distribution file, to speed up fetching the files.
d1177 11
a1187 5
   local system in /usr/pkgsrc/distfiles. If they are not present, they
   will be fetched using ftp(1) from the site(s) given in the variable
   PATCH_SITES. The location(s) in PATCH_SITES are in the form of URLs
   and can be ftp://- and http://-URLs, as ftp(1) understands both of
   them.
@


1.223
log
@add 10.22 How to handle compiler bugs
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.222 2001/12/26 15:06:35 mason Exp $
d2147 1
a2147 1
 10.22 How to handle compiler bugs
@


1.222
log
@scripts/ no longer exists
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.221 2001/12/15 20:25:34 agc Exp $
d2145 14
@


1.221
log
@Modify all references to PKGSRCDIR to _PKGSRCDIR, except in the external
references of the pkglint package.

_PKGSRCDIR is an internal definition in bsd.pkg.mk, and a few packages
which would like to refer to other packages in the build tree. It should
not be set by users, but neither should it stop a user from building a
package if it is defined, so make it obvious that this is the case.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.220 2001/12/12 16:30:04 wiz Exp $
d1263 1
a1263 4
   or install target omitted.  For any of these auxiliary targets,
   scripts of the same name can be placed in the package's
   scripts-subdirectory that will be executed at the given time, see
   section 4.5.
@


1.220
log
@Retire USE_CURSES, which was superseded by devel/ncurses/buildlink.mk, and
has now been purged from pkgsrc.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.219 2001/12/08 02:14:38 hubertf Exp $
d367 1
a367 1
    PACKAGES?=              ${PKGSRCDIR}/packages/${MACHINE_ARCH}
d1898 2
a1899 2
	if [ ! -e ${PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
		cd ${PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract;              \
d1907 1
a1907 1
		cd ${PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean
@


1.219
log
@Clarify things on PKGREVISION a bit, and mention that it should be removed
if the pkg is upgraded to a new release of the software. (Setting
PKGREVISION=0 should do ok too, but I don't think we want to document that)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.218 2001/12/02 21:29:20 wiz Exp $
a1542 1
    USE_CURSES	-->	.include "../../devel/ncurses/buildlink.mk"
@


1.218
log
@Add support for distfile-specific master sites, as requested in pkg/7471.
Syntax:
MASTER_SITES_completefilename=	http://specific.master/site
and similarly for PATCH_SITES.
Convert print/ghostscript-nox11 and x11/kterm to take advantage of this.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.217 2001/11/30 01:26:32 wiz Exp $
d1984 3
a1986 4
by the original author, a 'nb1' ('nb2', ...) suffix is used on package
versions. The "nb" is treated like a "." by the pkg tools.

To set the package's revision, set the PKGREVISION variable, e.g.
d1991 7
a1997 1
This will result in a PKGNAME of foo-17.42nb9.
@


1.217
log
@Remove REPLACE_CURSES from bsd.pkg.mk (not needed anymore), and don't
document it and USE_CURSES in Packages.txt anymore (packages should
really use devel/ncurses/buildlink.mk instead).
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.216 2001/11/29 01:12:24 hubertf Exp $
d597 4
@


1.216
log
@Get rid of manually adding "nbX" to PKGNAME when a pkg was changed in
pkgsrc. Instead, a new variable PKGREVISION is invented that can get
bumped independent of DISTNAME and PKGNAME.

Example #1:
        DISTNAME=       foo-X.Y
        PKGREVISION=    Z
     => PKGNAME=        foo-X.YnbZ

Example #2:
        DISTNAME=       barthing-X.Y
        PKGNAME=        bar-X.Y
        PKGREVISION=    Z
     => PKGNAME=        bar=X.YnbZ (!)

On subsequent changes, only PKGREVISION needs to be bumped, no more risk
of getting DISTNAME changed accidentally.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.215 2001/11/27 03:03:11 hubertf Exp $
d2044 1
a2044 35
curses prior to 1.4Y. For packages using such functionality there are two
options, setting USE_CURSES or including ../../devel/ncurses/buildlink.mk
in the package's Makefile.


 10.20.1 USE_CURSES
 ===================

If USE_CURSES is set in a package's Makefile, NEED_NCURSES is set
automatically to YES or NO, depending on whether a dependency on ncurses is
needed on this system. You can use this variable to e.g. add arguments to
configure to tell the package whether to use ncurses.

Additionally, you can set REPLACE_NCURSES to some filenames; in each of
these files, each occurrence of 'ncurses' is replaced by 'curses' if the
package doesn't need ncurses. You may need this in some cases if ncurses
are installed, and the package's configure script prefers ncurses.

For example, in pkgsrc/mail/mutt, the relevant lines are:

	USE_CURSES=		YES
	REPLACE_NCURSES=	configure configure.in
	...
	.include "../../mk/bsd.prefs.mk"

	.if defined(NEED_NCURSES) && ${NEED_NCURSES} == "YES"
	CONFIGURE_ARGS+=	--with-curses=${LOCALBASE}
	.endif

Please note that the check for NEED_NCURSES has to be below the
inclusion of bsd.prefs.mk, since the variable is set there.


 10.20.2 devel/ncurses/buildlink.mk
 ==================================
@


1.215
log
@add a few quotes to make things a bit clearer in one place
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.214 2001/11/26 22:06:58 jlam Exp $
d1980 9
a1988 2
by the original author, use a 'nb1' suffix (later versions should
increment this to give 'nb2' and so on).
@


1.214
log
@Update description of how to create a user/group account for a package
to use PKG_{USERS,GROUPS}.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.213 2001/11/25 19:10:27 jlam Exp $
d678 1
a678 1
The patch-?? files should be in diff -bu format, and apply without
@


1.213
log
@Add description of PKG_SYSCONFDIR and related variables, and note that
pkgsrc policy now is to make packages look for their config files in
${PKG_SYSCONFDIR}.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.212 2001/11/19 16:28:03 jlam Exp $
d2141 26
a2166 6
Define PKG_USER and PKG_GROUP to the user and group, and optionally
PKG_USERID and PKG_GROUPID to the userid and groupid, that need to be created
for the package, and include "../../mk/bsd.pkg.install.mk" in the package
Makefile prior to the inclusion of bsd.pkg.mk.  This will cause the user
and group to be created at pre-install time, and the admin will be prompted
to remove them at post-deinstall time.
@


1.212
log
@Note that to handle creating new users/groups for a package, you should use
bsd.pkg.install.mk and set PKG_USER/PKG_GROUP appropriately.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.211 2001/11/08 08:54:04 jlam Exp $
d1044 27
a1070 1
 6.5 Feedback to the author
@


1.211
log
@Fix typo noted by Masao Uebayashi <uebayasi@@soum.co.jp>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.210 2001/11/03 21:02:46 wiz Exp $
d2115 6
a2120 1
Look at what e.g. pkgsrc/sysutils/amanda-common/{Makefile,INSTALL} do.
@


1.210
log
@Update for "pkg/"-removal.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.209 2001/11/03 20:43:53 hubertf Exp $
d1465 1
a1465 1
-L${LOCABASE}/lib to the compiler.  Therefore, those lines should be removed
@


1.209
log
@Ding dong, the scripts are dead!
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.208 2001/10/31 04:24:16 jlam Exp $
d720 2
a721 8
 4.4 pkg/*
 =========

This directory contains several files used to manage the creation of binary
packages. Files from this directory are used in the binary package itself,
and will thus be installed on other machines, so you should be aware that
there is a wider audience than you might think for your comments and
witticisms.
d723 1
a723 5

 4.4.1 Mandatory files
 =====================

 * pkg/DESCR:
d729 1
a729 1
 * pkg/PLIST:
d736 2
a737 2
 4.4.2 Optional files
 ====================
d739 1
a739 1
 * pkg/INSTALL:
d746 1
a746 1
 * pkg/DEINSTALL:
d753 1
a753 1
 * pkg/MESSAGE:
d765 1
a765 1
   in pkg/MESSAGE with "somevalue" before displaying the message.
d768 1
a768 1
 4.5 work/*
d780 1
a780 1
 4.6 files/*
d838 1
a838 1
   not pkg/PLIST itself.
d1387 1
a1387 1
   recommended to review the result before putting it into pkg/PLIST. On
d1389 1
a1389 1
   existing pkg/PLIST file.
d1392 1
a1392 1
   file access times, be sure to add these files manually to your pkg/PLIST,
d1579 1
a1579 1
 * Fill in pkg/DESCR
d1600 1
a1600 1
	# make print-PLIST > pkg/PLIST
d1610 1
a1610 1
   If this brings up any files that are missing in pkg/PLIST*, add them.
d2115 1
a2115 1
Look at what e.g. pkgsrc/sysutils/amanda-common/{Makefile,pkg/INSTALL} do.
d2170 1
a2170 1
pkg/DESCR file, so people reading the mailing lists know what the package
d2240 1
a2240 1
 12.1.2 pkg/DESCR
d2248 1
a2248 1
 12.1.3 pkg/PLIST
d2275 1
a2275 1
	OK: checking pkg/DESCR.
d2296 1
a2296 1
Create Makefile, pkg/DESCR and pkg/PLIST as in section 11.1,
@


1.208
log
@Missing semicolons between commands in automake example.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.207 2001/10/30 17:09:43 drochner Exp $
d778 1
a778 25
 4.5 scripts/*
 =============

This directory contains any files that are necessary for configuration of
your software, etc. If a script with any of the following names is present,
it will be executed at the appropriate time during the build process:

  pre-fetch          post-fetch
  pre-extract        post-extract
  pre-patch          post-patch
  pre-configure      post-configure     configure
  pre-build          post-build
  pre-install        post-install
  pre-package        post-package

Note that you should NOT define a pre-* or post-* target in the Makefile
which executes the matching scripts/[pre|post]-* script. bsd.pkg.mk runs
any existing Makefile target first, then searches for scripts/* and runs
it using sh(1). Running the script from the Makefile would cause it to
be run twice.

See section 7 for a description of the build process.


 4.6 work/*
a1193 4

   If the program doesn't come with its own configure script, one can be
   placed in the package's scripts directory, called "configure". If so, it
   is executed using sh(1).
@


1.207
log
@correct LIBTOOL_OVERRIDE usage
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.206 2001/10/26 17:15:57 jlam Exp $
d1067 4
a1070 4
		${LOCALBASE}/bin/aclocal				\
		${LOCALBASE}/bin/autoheader				\
		${LOCALBASE}/bin/automake -a --foreign -i		\
		${LOCALBASE}/bin/autoconf				\
@


1.206
log
@Document how to deal with packages that need autoconf/automake and
AUTOMAKE_OVERRIDE.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.205 2001/10/24 22:10:43 jlam Exp $
d1030 1
a1030 1
USE_LIBTOOL_OVERRIDE=${WRKSRC}/libtool instead.
@


1.205
log
@I am a triple idiot.  The only relevant variable that x11.buildlink.mk
redefines about which buildlink.mk files would care is BUILDLINK_X11_DIR,
which points to the location of the X11R6 hierarchy used during building.
If x11.buildlink.mk isn't included, then BUILDLINK_X11_DIR defaults to
${X11BASE} (set in bsd.pkg.mk), so its value is always safe to use.  Remove
the ifdefs surrounding the use of BUILDLINK_X11_DIR in tk/buildlink.mk and
revert changes to move x11.buildlink.mk before the other buildlink.mk files.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.204 2001/10/24 20:06:19 jlam Exp $
d1052 27
a1078 1
 6.4 Feedback to the author
@


1.204
log
@Note that x11.buildlink.mk should be included first.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.203 2001/10/17 18:35:42 hubertf Exp $
a1533 4

x11.buildlink.mk must be included before other buildlink.mk files that test
for whether X11_BUILDLINK_MK is defined.  In general, x11.buildlink.mk
should be included before all other buildlink.mk files.
@


1.203
log
@ * Replace BUILD_ROOT with PKGSRCDIR in one example
 * Note how to clean-up after unpacking/building another package
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.202 2001/10/15 11:34:20 agc Exp $
d1534 4
@


1.202
log
@Add a section, for developers' benefit mainly, related to updating
packages in pkgsrc.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.201 2001/10/13 05:27:49 abs Exp $
d1881 2
a1882 2
	if [ ! -e ${BUILD_ROOT}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
		cd ../../graphics/jpeg && ${MAKE} extract;              \
d1884 7
@


1.201
log
@Add mosaic-license to bulk-build licences
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.200 2001/10/11 13:21:08 wiz Exp $
d2182 28
@


1.200
log
@Remove references on how to import FreeBSD ports, since this hasn't been
our main source for packages for a long time, and was confusing people.
Also some cleanups, rewrite of section 9, and some updates to a more
current pkgsrc situation.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.199 2001/10/11 11:11:15 martti Exp $
d374 1
@


1.199
log
@Note that on import, one should include part of the pkg/DESCR file
in the commit message.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.198 2001/10/02 11:15:29 abs Exp $
d318 1
d503 1
d514 1
d546 1
d554 2
a555 4
Whenever you're preparing a package from the FreeBSD ports collection or
doing it from scratch, there are a number of files involved which are
described in the following sections. Special directions are given for what
differs from FreeBSD ports for each file.
d612 1
a612 2
Please pay attention to the following gotchas, especially when preparing a
package from the FreeBSD ports collection:
a613 3
 - Remove all MANx and CATx definitions from the package Makefile -
   NetBSD has implemented automatic manual page handling, and these
   definitions are now obsolete.
a616 14
 - Delete any ldconfig commands - this will be done automatically for you
   if the NetBSD platform supports ldconfig, and other measures will be
   taken on platforms which do not support ldconfig (e.g. NetBSD/Alpha)
 - If modifying a package from the FreeBSD ports collection, preserve
   their RCS ID: remove the '$'s around the FreeBSD RCS Id, and insert the
   word FreeBSD, then add a <$>NetBSD<$> (Without the <>s, please remember
   the Terminology section), i.e.:

   before:
	# <$>Id: Makefile,v 1.17 1997/06/16 06:39:51 max Exp <$>

   after:
	# <$>NetBSD<$>
	# FreeBSD Id: Makefile,v 1.17 1997/06/16 06:39:51 max Exp
d618 1
a618 1
   needs to be updated to reflect this fact. NetBSD now has an INFO_FILES
d630 1
a630 2
   packages@@netbsd.org, as it is unlikely that the FreeBSD people will
   care about NetBSD packages.
a636 3
 port2pkg (pkgsrc/pkgtools/port2pkg) does many of the mentioned steps
 for you -- operator discretion is advised, though.

d700 3
a702 16
filename.orig". If you upgrade a package this way, you can easily compare
the new set of patches with the previously existing one with patchdiff.

When preparing a FreeBSD port for the NetBSD packages system, it's likely
that the FreeBSD port will work on NetBSD. However, check that the person
who ported the software to FreeBSD has not played fast and loose with the
__FreeBSD__ cpp definition without good cause - a simple way to do this is
to do

	% grep -i freebsd patches/patch-??

in the package directory.

Besides taking care of any FreeBSDisms, be sure to provide patches to
replace any occurrence of /usr/local in any "Makefile"s in the original
package with ${PREFIX}.
d728 1
a743 12
If you're updating a FreeBSD package to work for NetBSD, please pay special
attention to the following things in pkg/PLIST:

 - If there are any "@@exec ldconfig ..." statements, or any "@@unexec
   ldconfig ...", delete them. NetBSD works out automatically whether to
   call ldconfig, since some NetBSD architectures do not have ldconfig.
 - Add any missing @@dirrm statements
 - Remove any MANx= definitions in the package Makefile

You could also investigate the port2pkg package (pkgsrc/pkgtools/port2pkg),
which does a lot of the donkey work for you.

a838 17
 * ranlib:
   Don't put any ranlib commands into your PLIST files, as they will cause
   troubles when the package is removed. Just make sure the build-process
   does run ranlib - it usually does - and you can leave this out. This is
   usually only a problem when using ports from FreeBSD.

 * ldconfig:
   Don't put any ldconfig commands into your PLIST files, as they will
   cause problems.  All shared object caching is done automatically in
   NetBSD (this takes place when you see the "Automatic shared object
   handling" message), and so you can leave this out.  If any shared
   objects are found in the package, they will be dealt with
   automatically, running ldconfig on platforms which need it, and not
   otherwise.  This is usually only a problem when using ports from
   FreeBSD.  To prevent this automatic handling from taking place,
   set SHLIB_HANDLING to NO in the package Makefile.

a925 6
The really impatient should just note that a number of the FreeBSD ports
(which are called packages in the NetBSD world) rely on the CPP definition
__FreeBSD__. This should be used sparingly, for FreeBSD-specific features,
but unfortunately this is not always the case. A number also rely on the
fact that the CPU type is an Intel-based little-endian CPU.

a940 4
You should also avoid defining __FreeBSD__=1 and then simply using the
FreeBSD port, if only from an aesthetic viewpoint.


d983 2
a984 2
   PLIST should include all of the .a, .la and so, .so.major and .so.major.minor
   entries.
d1023 7
a1029 5
Add USE_LIBTOOL=yes and LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig to the
package Makefile as the quick way to bypass the pkg's own libtool.
The pkg's own libtool is made by ltconfig script at do-configure target.
If USE_LIBTOOL and LTCONFIG_OVERRIDE are defined, the specified ltconfig is
overridden, using the pkgsrc/devel/libtool instead of the pkg's own libtool.
a1049 41
 6.4 Gotchas of FreeBSD ports
 ============================

See section 4.1 for Makefile issues (MANx, CATx, MANCOMPRESSED, ldconfig,
RCS IDs) and section 4.3 for gotchas on using patches from FreeBSD ports.

One of the biggest problems with FreeBSD ports is that too many of
them assume they will install into /usr/local, instead of honouring
any ${PREFIX} setting properly.  To change this, add something like the
following into your package Makefile:

	pre-configure:
	        for f in `find ${WRKDIR} -type f -print|xargs grep -l '/usr/local'`; do \
	                ${SED} -e 's:/usr/local:'${PREFIX}':g' < $$f > $$f.pdone && ${MV} $$f.pdone $$f; \
	        done

This is taken from the pkgsrc/sysutils/rtty package; be sure this works for
your package - it may actually make sense to look for some things in
/usr/local, for example. So don't blindly replace all occurrences of
/usr/local!

FreeBSD has decided to list manual pages in the package Makefile, with
no corresponding entry in the PLIST.  You will thus need to add any
MAN[1-8ln] files to the PLIST, before deleting the MAN[1-8ln]
definition.  Similarly with MLINKS and CAT[1-8ln] entries.

Side note on manpages in PLIST:  we don't take any notice of any .gz
suffix there, as many FreeBSD ports seem to have .gz pages in PLIST
even when they install manpages without compressing them; rather, we
add our own .gz suffix there according to MANZ.  In short, it does not
matter whether the manual page name in the PLIST has a .gz suffix or
not - if it needs one which is not already there, it will be appended
automatically, and if there is a .gz suffix which is not needed, it
will be deleted automatically.

Some packages use bsd-style .mk files when building, and so any manual
pages that are installed will be gzip-compressed, if MANZ is set, or
not if MANZ is not set.  If the package uses bsd-style .mk files, the
variable MANCOMPRESSED_IF_MANZ should be set to a value of "yes" in
the package Makefile.

d1051 1
a1051 1
 6.5 Feedback to the author
d1578 3
a1580 4
To check out all the gotchas when building a package (either from
a FreeBSD port, or from scratch), here are the steps that I do in
order to get a package working. Please note this is basically the
same as what was explained in the previous sections, only with some
d1584 20
a1603 17
 * Retrieve port from FreeBSD collection
 * Fix RCS-ID in the package's Makefile, see section 4.1. 
 * Import unchanged FreeBSD source (ONLY if you have cvs access, not needed
   otherwise):
   
	% (cd .../pkgsrc/category/pkgname ; cvs import pkgsrc/category/pkgname \
		FREEBSD FreeBSD-current-yyyy-mm-dd)
	
 * If you did a CVS import, check it out to apply the following fixes
   (not needed if you don't have CVS access!)
 * Look at Makefile, fix if necessary; see section 4.1. 
 * Look at patches, remember if not appropriate
 * Have a look at pkg/PLIST, add a "@@comment <$>NetBSD<$>" line at the
   beginning of any PLIST file (see section 5). 
 * Build the package:
 
	% make
d1607 6
a1612 6
 * If something is not ok, fix; for patches: fix the file, then re-generate
   the diff: 'diff -bu foo.orig foo >../../patches/patch-xx' (mv patch-xx
   patch-xx.orig before); If there's no foo.orig from a previous patch, be
   sure to have an old version of the file somewhere; re-iterate :)
 * If all builds OK: touch /tmp/bla
 * Install the package:
d1614 2
a1616 11
 * Find all files installed by the package:
 
	# find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla >/tmp/x
	
   If you have set LOCALBASE and X11BASE in /etc/mk.conf, use the values
   from there instead. As an alternative to this find command, you can run
   "make print-PLIST". 
 * Deinstall the package:
 
	# pkg_delete blub
	
a1617 2
 
	# find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla
d1619 3
a1621 6
   If this brings up any files, that are missing in pkg/PLIST*, add them.
 * Compare pkg/PLIST* against /tmp/x, fix the former one. You can use some
   magic like:
   
	% ( sort /tmp/x >/tmp/x2 ; sort pkg/PLIST >/tmp/P ; sdiff /tmp/x2 /tmp/P )
	
d1633 1
a1633 1
	# find /usr/pkg/ /usr/X11R6/ -type f -newer /tmp/bla
d1637 1
a1637 1
	# pkg_add .../blub.tgz
d1639 6
a1644 9
 * Play with it. Make sure everything works. 
 * Deinstall the package again using pkg_delete(8). Still no file should be
   left. Re-run the above find(1) command to make sure. 
 * make clean && touch /tmp/bla && make install && make clean && make deinstall
   then run the find again. Yes, some software authors write Makefiles that
   install files during the build target. Sigh. Re-run the find, and fix the
   PLIST. Repeat until certain the software does not install any files that
   aren't in PLIST.
 * submit (or commit, if you have cvs access); see section 10.
d1766 1
a1766 1
See section 4.3 on how to remove RCS IDs from patch files. 
d1825 2
a1826 4
BUILD_DEPENDS and DEPENDS definitions (beware: the DEPENDS definition is
not the same as FreeBSD's deprecated one, and NetBSD does not use the
FreeBSD LIB_DEPENDS definition any more - it proved problematic on ELF
NetBSD platforms).
d1828 1
a1828 1
The basic difference between the two definitions is as follows:  the
d2128 1
a2128 1
You have to separate between binary and "normale" (source) packages here:
a2172 12
Packages derived from a FreeBSD port should be imported with a vendor tag
of "FREEBSD" and a release tag of "FreeBSD-current-YYYY-MM-DD" (YYYY-MM-DD
being the date when the snapshot of the port were taken form the FreeBSD
tree), and then doing the necessary modifications by normal CVS operations.
E.g:

	% cd .../pkgsrc/<category>/<pkgname>
	% cvs import pkgsrc/<category>/<pkgname> FREEBSD FreeBSD-current-1998-04-01
	% cvs rm patches/patch-a
	% cvs add patches/patch-aa
	% cvs ci

d2174 2
a2175 2
pkg/DESCR file, so people reading the mailing lists know what the
package is/does.
d2186 1
a2186 1
I checked to find a piece of software that isn't in the FreeBSD ports
d2206 1
a2206 1
	> MAINTAINER=     thorpej@@netbsd.org
d2270 1
a2270 1
	# mkdir files patches pkg
@


1.198
log
@Clarify and shorten the '-[0-9]* should be used instead of -*' section
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.197 2001/09/30 22:10:33 abs Exp $
d2311 4
@


1.197
log
@Add 'show-installed-depends' - neat implementation thanks to Hubert.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.196 2001/09/29 23:15:45 hubertf Exp $
d1989 2
a1990 10
For example, if a package needs any version of Tk installed, but does
not require an explicit version of Tk:

	DEPENDS+=	tk-*:../../x11/tk80

would also match e.g. tk-postgresql-6.5.3, which is not what was
needed. ALWAYS ensure that the wildcard doesn't match more than it should,
and perhaps use version numbers to make certain:

	BUILD_DEPENDS+=	perl-5.*:../../lang/perl
@


1.196
log
@another typo
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.195 2001/09/29 23:14:38 hubertf Exp $
d1494 4
@


1.195
log
@Fix typo pointed out by marius@@alchemy.franken.de in private mail.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.194 2001/09/27 23:17:41 jlam Exp $
d1684 1
a1684 1
To check out all the gotchas when building a package (wither from
@


1.194
log
@Mechanical changes to 375 files to change dependency patterns of the form
foo-* to foo-[0-9]*.  This is to cause the dependencies to match only the
packages whose base package name is "foo", and not those named "foo-bar".
A concrete example is p5-Net-* matching p5-Net-DNS as well as p5-Net.  Also
change dependency examples in Packages.txt to reflect this.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.193 2001/09/26 04:47:39 jmc Exp $
d520 1
a520 1
        # mkdir /u2/image
@


1.193
log
@Change tabs to spaces in example output for audit-package install in 10.21.
 This makes the TOC generation clean again.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.192 2001/09/24 08:59:09 agc Exp $
d1978 1
a1978 1
	DEPENDS+=	xpm-*:../../graphics/xpm
d2001 1
a2001 1
	DEPENDS+=        teTex-*:../../print/teTeX 
d2036 1
a2036 1
	CONFLICTS=      Xaw-Xpm-*
d2040 1
a2040 1
	CONFLICTS=      Xaw3d-*
@


1.192
log
@Adapt the documentation for bsd.pkg.defaults.mk
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.191 2001/09/21 09:04:22 skrll Exp $
d2221 1
a2221 1
	======================================================================
d2238 1
a2238 1
	======================================================================
@


1.191
log
@More tpyos, speelling and gramer
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.190 2001/09/21 08:36:50 skrll Exp $
d216 4
a219 3
This will create the "pkgsrc" directory in your /usr, and all the package
source will be stored under /usr/pkgsrc. To update pkgsrc after the initial
checkout, make sure you have CVS_RSH set as above, then do:
d224 4
d238 8
a245 5
that are close to your own. Have a look at /usr/pkgsrc/mk/mk.conf.example
to find some examples. This may save some of your bandwidth and time.

When you have selected your settings, install your configuration into
/etc/mk.conf
d291 4
a294 4
at build time.  Have a look at /usr/pkgsrc/mk/mk.conf.example to get
an overview of what you can set there.  Environment variables such as
LOCALBASE, and X11BASE can also be set in /etc/mk.conf to save having
to remember to set them each time you want to use pkgsrc.
d303 1
a303 1
into BIN_INSTALL_FLAGS. See pkgsrc/mk/mk.conf.example for more details. 
d359 4
a362 3
You may want to set things in /etc/mk.conf.  Look at pkgsrc/mk/mk.conf.example
for details.  You will want to make sure that ACCEPTABLE_LICENSES meet your
local policy:
d1184 1
a1184 1
a central Makefile, /usr/pkgsrc/mk/bsd.pkg.mk.
@


1.190
log
@typo
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.189 2001/09/19 10:45:32 wiz Exp $
d25 1
a25 1
software run on NetBSD, and makes the installation (and reinstallation) of
d108 1
a108 1
When giving examples for comands, shell prompts are used to show if the
d288 1
a288 1
If you want to deinstall and re-install a binary package that you've
d385 1
a385 1
file that determines where logfiles are generated after the build,
d432 1
a432 1
Be sure to remove all other things that might interfer with builds, like 
d456 1
a456 1
2. the bulk build: This is basically 'make bulk-package' with an optimized
d487 1
a487 1
Note that all pkgs will be deinstalled as soon as they are turned into a
d947 1
a947 1
which replaces all occurances of ${SOMEVAR} in the PLIST with "somevalue".
d1091 1
a1091 1
If your package makes use of the platform independant library for loading
d1380 1
a1380 1
   version.  The package and all depending packages first get deinstalled,
d1423 1
a1423 1
   packages) have already been deinstalled (e.g., after calling "make
d1543 2
a1544 2
Goal (1) is accomplished by simply including a package dependency's
buildlink.mk file in a package's Makefile, which does the following:
d1974 1
a1974 1
Wildard dependencies should be used with care.
d2116 1
a2116 1
   not be made available on the internet.
d2126 1
a2126 1
   distfile(s) via the internet is not allowed.
@


1.189
log
@Note that on import, one should also add the package to the category's
Makefile.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.188 2001/09/14 01:52:40 jlam Exp $
d407 1
a407 1
As /usr/pkg wil be completely deleted at the start of bulk builds, 
@


1.188
log
@Document the new Motif-related variables.  Deprecate USE_MOTIF in favor of
including motif.buildlink.mk, which contains more sophisticated and
complete logic for detecting the various Motif options that may be
installed.  Though deprecated, USE_MOTIF is still recognized, though it
does no more than include motif.buildlink.mk.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.187 2001/09/09 20:36:08 agc Exp $
a2289 1

d2292 2
a2293 1
source tree.
@


1.187
log
@Deprecate NO_WRKSUBDIR, replacing it with an explicit assignment of:

WRKSRC= ${WRKDIR}

This is much cleaner, much more indicative of what happens, and removes
another of the negative definitions (NO_.* = value).
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.186 2001/09/08 20:09:46 jlam Exp $
d1188 3
a1190 4
that of $X11BASE if USE_IMAKE, USE_MOTIF, or USE_X11BASE is set.  The value
${PREFIX} needs to be put into the various places in the program's source
where paths to these files are encoded; see sections 4.3 and 6.2 for
details on this.
d1209 2
a1210 2
   USE_IMAKE, USE_MOTIF, or USE_X11BASE in its pkg Makefile, you need to use
   _both_ ${X11BASE} and ${LOCALBASE}.
a1625 1
    USE_MOTIF12	-->	.include "../../x11/lesstif12/buildlink.mk"
d1637 5
@


1.186
log
@Note USE_MOTIF --> .include "../../mk/motif.buildlink.mk" when converting
packages to use buildlink.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.185 2001/09/04 13:50:02 hubertf Exp $
d1792 4
d1797 2
@


1.185
log
@Add a note on typography  - for now, only some info on shell prompts.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.184 2001/09/04 13:33:56 hubertf Exp $
d1626 1
a1626 1
    USE_MOTIF	-->	.include "../../x11/lesstif/buildlink.mk"
@


1.184
log
@Markup changes:
 * indent consistently
 * make shell prompts consistent

XXX It would be really nice to have that in a different format, and generate
    this file... (Didn't I do a DocBook version of this some time ago?)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.183 2001/09/04 13:00:44 hubertf Exp $
d99 13
@


1.183
log
@Fix some typos, logical errors, and use pkgsrc/foo/bar consistently.
Mostly from Dawid Szymaqski <dawszy@@netbsd.lubin.pl>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.182 2001/08/29 22:55:36 jlam Exp $
d134 1
a134 1
	pkg_add /path/to/package.tgz
d140 1
a140 1
	pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.tgz
d237 1
a237 1
	make
d241 1
a241 1
	make install
d307 1
a307 1
	make package
d385 1
a385 1
	echo "I do not have enough disk space to build this pig." \
d404 4
a407 4
    ( cd /usr/pkgsrc/security/ssh ; make bulk-install )
    if [ -f /usr/pkg/etc/rc.d/sshd ]; then
            /usr/pkg/etc/rc.d/sshd
    fi
d498 3
a500 4
  mkdir /u2/images
  pkg_add /usr/pkgsrc/packages/All/cdpack
  rehash
  cdpack /usr/pkgsrc/packages/All /u2/images
d506 7
a512 7
  mkdir /tmp/common
  echo "This is a README" > /tmp/commmon/README
  echo "Another file" > /tmp/common/COPYING
  mkdir /tmp/common/bin
  echo "#!/bin/sh" > /tmp/common/bin/myscript
  echo "echo Hello world" >> /tmp/common/bin/myscript
  chmod 755 /tmp/common/bin/myscript
d516 1
a516 1
  cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
d707 1
a707 1
	grep -i freebsd patches/patch-??
d789 1
d791 1
d793 1
d795 1
d829 1
a829 1
	make clean
d834 1
d1108 4
a1111 6
pre-configure:
        for f in `find ${WRKDIR} -type f -print|xargs grep -l '/usr/local'`; do
\
                ${SED} -e 's:/usr/local:'${PREFIX}':g' < $$f > $$f.pdone && ${MV} $
$f.pdone $$f; \
        done
d1519 7
a1525 7
  (1) Cause all headers and libraries used by a particular package to be
      found in a known location during the configure and build process.
      These packages are said to be "weakly-buildlinked".

  (2) Cause _only_ those headers and libraries used by a particular package
      to be found during the configure and build process.
      These packages are said to be "strongly-buildlinked".
d1534 1
a1534 1
  (1a) Adds a DEPENDS or BUILD_DEPENDS line for the package;
d1536 2
a1537 2
  (1b) Creates a directory ${BUILDLINK_DIR}, by default set to a
       subdirectory of ${WRKDIR};
d1539 2
a1540 2
  (1c) Links all the headers and libraries for that dependency into
       ${BUILDLINK_DIR}/include and ${BUILDLINK_DIR}/lib, respectively;
d1542 2
a1543 2
  (1d) Prepends -I${BUILDLINK_DIR}/include to CPPFLAGS, CFLAGS, CXXFLAGS,
       and -L${BUILDLINK_DIR}/lib to LDFLAGS;
d1545 3
a1547 3
  (1e) Creates a wrapper script for GTK+-style config scripts, often found
       in GNOME software, that translates -I${LOCALBASE}/include and
       -L${LOCALBASE}/lib into references into ${BUILDLINK_DIR}.
d1580 17
a1596 17
> .include "../../mk/bsd.buildlink.mk"
> 
> BUILDLINK_DEPENDS.foo?=	foo>=1.0
> DEPENDS+=			${BUILDLINK_DEPENDS.foo}:../../category/foo
> 
> EVAL_PREFIX+=			BUILDLINK_PREFIX.foo=foo
> BUILDLINK_FILES.foo=		include/foo.h
> BUILDLINK_FILES.foo+=		include/bar.h
> BUILDLINK_FILES.foo+=		lib/libfoo.*
> 
> # We need the libraries to be called "libbar.*".
> BUILDLINK_TRANSFORM.foo=	-e "s|libfoo|libbar|g"
> 
> BUILDLINK_TARGETS+=		foo-buildlink
> 
> pre-configure: foo-buildlink
> foo-buildlink: _BUILDLINK_USE
d1665 4
a1668 4
 - Make sure PKG_DEVELOPER=1 is in /etc/mk.conf
 - Retrieve port from FreeBSD collection
 - Fix RCS-ID in the package's Makefile, see section 4.1. 
 - Import unchanged FreeBSD source (ONLY if you have cvs access, not needed
d1670 5
a1674 3
   (cd .../pkgsrc/category/pkgname ; cvs import pkgsrc/category/pkgname \
	FREEBSD FreeBSD-current-yyyy-mm-dd)
 - If you did a CVS import, check it out to apply the following fixes
d1676 3
a1678 3
 - Look at Makefile, fix if necessary; see section 4.1. 
 - Look at patches, remember if not appropriate
 - Have a look at pkg/PLIST, add a "@@comment <$>NetBSD<$>" line at the
d1680 7
a1686 2
 - make
 - If something is not ok, fix; for patches: fix the file, then re-generate
d1690 46
a1735 18
 - If all builds OK: touch /tmp/bla
 - make install
 - find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla >/tmp/x
   (or whatever you set LOCALBASE and X11BASE to)
 - pkg_delete blub
 - find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla (or diff against output of
   'make print-PLIST'): if this brings up any files, that are missing in
   pkg/PLIST*; add them.
 - Compare pkg/PLIST* against /tmp/x, fix the former one
   ( sort /tmp/x >/tmp/x2 ; sort pkg/PLIST >/tmp/P ; sdiff /tmp/x2 /tmp/P )
 - make reinstall && make package
 - pkg_delete blub
 - "find /usr/pkg/ /usr/X11R6/ -type f -newer /tmp/bla" shouldn't find anything
   now
 - pkg_add .../blub.tgz
 - Play with it :)
 - pkg_delete - still no file should be left (re-run above find)
 - make clean && touch /tmp/bla && make install && make clean && make deinstall
d1740 1
a1740 1
 - submit (or commit, if you have cvs access); see section 10.
d1752 1
a1752 1
> GNU_CONFIGURE= yes
d1766 4
a1769 4
> EXTRACT_SUFX=   .msg.gz
> EXTRACT_CMD=            zcat
> EXTRACT_BEFORE_ARGS=
> EXTRACT_AFTER_ARGS=     |sh
d1779 1
a1779 1
> NO_WRKSUBDIR=   yes
d1788 3
a1790 3
> HAS_CONFIGURE=          yes
> CONFIGURE_SCRIPT=       Configure
> CONFIGURE_ARGS+=        netbsd13
d1799 1
a1799 1
> WRKSRC=         ${WRKDIR}/${DISTNAME}/unix
d1816 4
a1819 3
	cd /usr/pkgsrc
	make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
	scp /tmp/fetch.sh work:/tmp
d1822 3
a1824 2
	sh /tmp/fetch.sh
	tar up /tmp/distfiles and take it home
d1831 1
a1831 1
	make mirror-distfiles
d1836 1
a1836 1
	make fetch NO_IGNORE=yes
d1887 1
a1887 1
    echo subscribe tech-pkg | mail majordomo@@netbsd.org
d1897 3
a1899 3
/usr/bin/fetch
${LOCALBASE}/bsd/bin/ftp
/usr/bin/ftp
d2005 1
a2005 1
CONFLICTS=      Xaw-Xpm-*
d2009 1
a2009 1
CONFLICTS=      Xaw3d-*
d2068 1
a2068 1
	tar --unlink -pvxf .../comp.tgz
d2081 24
a2104 24
    - RESTRICTED:
      This variable should be set whenever a restriction exists
      (regardless of its kind).  Set this variable to a string
      containing the reason for the restriction.

    - NO_BIN_ON_CDROM:
      Binaries may not be placed on CD-ROM.  Set this variable to
      ${RESTRICTED} whenever a binary package may not be included
      on a CD-ROM.

    - NO_BIN_ON_FTP:
      Binaries may not be placed on an ftp server.  Set this
      variable to ${RESTRICTED} whenever a binary package may not
      not be made available on the internet.

    - NO_SRC_ON_CDROM:
      Distfiles may not be placed on CD-ROM.  Set this variable to
      ${RESTRICTED} if re-distribution of the source code or other
      distfile(s) is not allowed on CD-ROMs.

    - NO_SRC_ON_FTP:
      Distfiles may not be placed on FTP.  Set this variable to
      ${RESTRICTED} if re-distribution of the source code or other
      distfile(s) via the internet is not allowed.
d2110 1
d2134 9
a2142 8
USE_CURSES=		YES
REPLACE_NCURSES=	configure configure.in
[...]
.include "../../mk/bsd.prefs.mk"

.if defined(NEED_NCURSES) && ${NEED_NCURSES} == "YES"
CONFIGURE_ARGS+=	--with-curses=${LOCALBASE}
.endif
d2172 4
a2175 4
(1) download-vulnerability-list, an easy way to download a list of the
security vulnerabilities information.  This list is kept up to date by
the NetBSD security officer and the NetBSD packages team, and is
distributed from the NetBSD ftp server:
d2179 5
a2183 4
(2) audit-packages, an easy way to audit the current machine, checking
each vulnerability which is known.  If a vulnerable package is
installed, it will be shown by output to stdout, including a description
of the type of vulnerability, and a URL containing more information.
d2190 18
a2207 18
  ======================================================================
  You may wish to have the vulnerabilities file downloaded daily so that
  it remains current.  This may be done by adding an appropriate entry
  to the root users crontab(5) entry.  For example the entry
  
  # download vulnerabilities file
  0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1
  
  will update the vulnerability list every day at 3AM.
  
  In addition, you may wish to run the package audit from the daily
  security script.  This may be accomplished by adding the following
  lines to /etc/security.local
  
  if [ -x ${PREFIX}/sbin/audit-packages ]; then
          ${PREFIX}/sbin/audit-packages
  fi
  ======================================================================
d2265 2
a2266 2
	cd .../pkgsrc/<category>/<pkgname>
	cvs import pkgsrc/<category>/<pkgname> TNF pkgsrc-base
d2279 5
a2283 5
	cd .../pkgsrc/<category>/<pkgname>
	cvs import pkgsrc/<category>/<pkgname> FREEBSD FreeBSD-current-1998-04-01
	cvs rm patches/patch-a
	cvs add patches/patch-aa
	cvs ci
d2309 13
a2321 14
> # <$>NetBSD<$>
>  
> DISTNAME=       bison-1.25
> CATEGORIES=     devel
> MASTER_SITES=   ${MASTER_SITE_GNU}
>
> MAINTAINER=     thorpej@@netbsd.org
> HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
> COMMENT=        GNU yacc clone
>  
> GNU_CONFIGURE=  yes
> INFO_FILES=     bison.info
>  
> .include "../../mk/bsd.pkg.mk"
d2327 3
a2329 3
> GNU version of yacc.  Can make re-entrant parsers, and numerous other
> improvements.  Why you would want this when Berkeley yacc(1) is part
> of the NetBSD source tree is beyond me.
d2335 13
a2347 13
> @@comment <$>NetBSD<$>
> bin/bison
> man/man1/bison.1.gz
> @@unexec install-info --delete %D/info/bison.info %D/info/dir
> info/bison.info
> info/bison.info-1
> info/bison.info-2
> info/bison.info-3
> info/bison.info-4
> info/bison.info-5
> @@exec install-info %D/info/bison.info %D/info/dir
> share/bison.simple
> share/bison.hairy
d2358 6
a2363 6
> tron@@lyssa:/usr/pkgsrc/devel/bison>pkglint
> OK: checking pkg/DESCR.
> OK: checking Makefile.
> OK: checking distinfo.
> OK: checking patches/patch-aa.
> looks fine.
d2375 4
a2378 4
> root@@pumpy:/u/pkgsrc/lang(1765)# cd /usr/pkgsrc/lang
> root@@pumpy:/u/pkgsrc/lang(1765)# mkdir bison
> root@@pumpy:/u/pkgsrc/lang(1766)# cd bison
> root@@pumpy:/u/pkgsrc/lang/bison(1768)# mkdir files patches pkg
d2383 13
a2395 13
> root@@pumpy:/u/pkgsrc/lang/bison(1769)# make fetch
> >> bison-1.25.tar.gz doesn't seem to exist on this system.
> >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
> Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
> ftp: Error retrieving file: 500 Internal error
>  
> >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
> Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
> ftp: Error retrieving file: 500 Internal error
>  
> >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
> Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
> Successfully retrieved file.
d2399 1
a2399 1
> root@@pumpy:/u/pkgsrc/lang/bison(1770)# make makesum
d2403 51
a2453 51
> root@@pumpy:/u/pkgsrc/lang/bison(1777)# make
> >> Checksum OK for bison-1.25.tar.gz.
> ===>  Extracting for bison-1.25
> ===>  Patching for bison-1.25
> ===>   Ignoring empty patch directory
> ===>  Configuring for bison-1.25
> creating cache ./config.cache
> checking for gcc... cc
> checking whether we are using GNU C... yes
> checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
> checking how to run the C preprocessor... cc -E
> checking for minix/config.h... no
> checking for POSIXized ISC... no
> checking whether cross-compiling... no
> checking for ANSI C header files... yes
> checking for string.h... yes
> checking for stdlib.h... yes
> checking for memory.h... yes
> checking for working const... yes
> checking for working alloca.h... no
> checking for alloca... yes
> checking for strerror... yes
> updating cache ./config.cache
> creating ./config.status
> creating Makefile
> ===>  Building for bison-1.25
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g LR0.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g allocate.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g closure.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g conflicts.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g derives.c
> cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c 
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getargs.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g gram.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
> cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o getopt.o getopt1.o
> ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
> rm -f bison.s1
> sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
d2457 13
a2469 13
> root@@pumpy:/u/pkgsrc/lang/bison(1785)# make install
> >> Checksum OK for bison-1.25.tar.gz.
> ===>  Installing for bison-1.25
> sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
> rm -f /usr/pkg/bin/bison
> cd /usr/pkg/share; rm -f bison.simple bison.hairy
> rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
> install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
> /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
> /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
> cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
> /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
> ===>  Registering installation for bison-1.25
d2475 6
a2480 6
> root@@pumpy:/u/pkgsrc/lang/bison(1786)# make package
> >> Checksum OK for bison-1.25.tar.gz.
> ===>  Building package for bison-1.25
> Creating package bison-1.25.tgz
> Registering depends:.
> Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
d2484 2
a2485 2
> root@@pumpy:/u/pkgsrc/lang/bison(1787)# make clean
> ===>  Cleaning for bison-1.25
d2495 71
a2565 68
> Script started on Fri Oct  3 13:22:31 1997
> root@@pumpy:/u/pkgsrc/sysutils/top(1342)# make
> >> top-3.5beta5.tar.gz doesn't seem to exist on this system.
> >> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
> Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
> Successfully retrieved file.
> >> Checksum OK for top-3.5beta5.tar.gz.
> ===>  Extracting for top-3.5beta5
> ===>  Patching for top-3.5beta5
> ===>  Applying NetBSD patches for top-3.5beta5
> ===>  Configuring for top-3.5beta5
> /bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
> chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
> 
> Reading configuration from last time...
> 
> Using these settings:
>         Bourne Shell   /bin/sh
>           C compiler   cc
>     Compiler options   -DHAVE_GETOPT -O
>          Awk command   awk
>      Install command   /usr/bin/install
> 
>               Module   netbsd13
>              LoadMax   5.0
>         Default TOPN   -1
>         Nominal TOPN   18
>        Default Delay   2
> Random passwd access   yes
>           Table Size   47
>                Owner   root
>          Group Owner   kmem
>                 Mode   2755
>        bin directory   $(PREFIX)/bin
>        man directory   $(PREFIX)/man/man1
>        man extension   1
>        man style       man
> 
> Building Makefile...
> Building top.local.h...
> Building top.1...
> Doing a "make clean".
> rm -f *.o top core core.* sigdesc.h
> To create the executable, type "make".
> To install the executable, type "make install".
> ===>  Building for top-3.5beta5
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c top.c
> awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c commands.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c display.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c screen.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c username.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c utils.c
> utils.c: In function `errmsg':
> utils.c:348: warning: return discards `const' from pointer target type
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c version.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c getopt.c
> cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
> rm -f top
> cc -o top top.o commands.o display.o screen.o username.o  utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
> root@@pumpy:/u/pkgsrc/sysutils/top(1343)# make install
> >> Checksum OK for top-3.5beta5.tar.gz.
> ===>  Installing for top-3.5beta5
> /usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
> /usr/bin/install top.1 /usr/pkg/man/man1/top.1
> strip /usr/pkg/bin/top
> ===>  Registering installation for top-3.5beta5
> root@@pumpy:/u/pkgsrc/sysutils/top(1344)# 
d2571 6
a2576 7
> root@@pumpy:/u/pkgsrc/sysutils/top(1344)# make package
 > >> Checksum OK for top-3.5beta5.tar.gz.
> ===>  Building package for top-3.5beta5
> Creating package top-3.5beta5.tgz
> Registering depends:.
> Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'
> root@@pumpy:/u/pkgsrc/sysutils/top(1345)#
@


1.182
log
@Update slightly to document x11.buildlink.mk.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.181 2001/08/25 02:17:02 jlam Exp $
d149 2
a150 2
After you've installed packages, be sure to have /usr/pkg in your $PATH so
you can actually start the just installed program.
d181 2
a182 2
There are three ways to get pkgsrc. Either as tar file, via SUP, or via
CVS. All three ways are described here. 
d234 2
a235 2
Assuming that has been done, become root and change into the relevant
directory. Then you can type
d386 1
a386 1
		> games/crafty-book-enormous/$BROKENF
d394 9
a402 4
Drop your favourite login shell in /usr/local, or install it from
/etc/rc.local. Also, if you use a OS version below 1.5 or you still want
to use the pkgsrc version of ssh for some reason, be sure to install 
ssh before starting it from rc.local:
d419 2
a420 2
Be sure to remove all other things (from /usr/local, ...).  Become
root and type:
d485 1
a485 1
other machines.  The package pkgtools/cdpack provides a simple tool for 
d656 1
a656 1
basis. (A good example is www/navigator). These are kept in the
d682 1
a682 1
Similar, a file should be patches at most once, not several times by
d686 5
a690 4
One important thing to mention is to pay attention that no RCS IDs get
stored in the patch files, as these will cause problems when later checked
into the NetBSD CVS tree. To avoid this, use either the "-U 2" or "-U 1"
option to diff, or let the 'pkgdiff' command from pkgsrc/pkgdiff help you.
d693 2
a694 2
yourself, use pkgdiff from the pkgtools/pkgdiff package, which takes care
of any RCS Ids by itself.
d1072 1
a1072 1
overridden, using the devel/libtool instead of the pkg's own libtool.
d1111 4
a1114 3
This is taken from the sysutils/rtty package; be sure this works for your
package - it may actually make sense to look for some things in /usr/local,
for example. So don't blindly replace all occurrences of /usr/local!
d1361 2
a1362 2
      done in x11/kde, this is likely to remove whole KDE. Works by adding
      a "-R" to the pkg_delete command line.
d1725 1
a1725 1
look at the package for editors/sam, which uses a gzipped shell archive
d1740 1
a1740 1
editors/sam again, but the quick answer is:
d1900 3
a1902 3
(b) If your package needs a library with which to link, this is
specified using the DEPENDS definition.  An example of this is the
print/lyx package, which uses the xpm library, version 3.4j to build.
d1927 2
a1928 2
is specified using the DEPENDS definition. The print/lyx package needs to
be able to execute the latex binary from the teTex package when it runs,
d1937 2
a1938 2
first part of the "do-configure" target print/ghostscript5 package (it
relies on the jpeg sources being present in source form during the
d1948 1
a1948 1
devel/gettext package.  The latter adds a build dependency on either an
d1950 1
a1950 1
devel/gettext-m4 package.
d2093 1
a2093 1
For example, in mail/mutt, the relevant lines are:
d2177 1
a2177 1
Look at what e.g. sysutils/amanda-common/{Makefile,pkg/INSTALL} do.
@


1.181
log
@Note that when buildlinking a package, USE_XAW may be converted to
.include "../../mk/xaw.buildlink.mk".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.180 2001/08/24 00:54:48 hubertf Exp $
d1548 12
a1559 12
Goal (2) requires some work on the part of the package builder and can
still only be incompletely met.  As all headers and libraries used by a
package may be found in ${BUILDLINK_DIR}, and -I${BUILDLINK_DIR}/include
and -L${BUILDLINK_DIR}/lib are already passed to the compiler, it is no
longer necessary to pass -I${LOCALBASE}/include or -L${LOCABASE}/lib to the
compiler.  Therefore, those lines should be removed from package Makefiles,
and where necessary, the package sources should be patched to do the same.
If USE_BUILDLINK_ONLY is defined, then -L${LOCALBASE}/lib is not
automatically added to LDFLAGS in bsd.pkg.mk.  However, this process
provides isolated builds only for platforms that use xpkgwedge as we
can't currently isolate the X11R6 files from package files installed under
${X11BASE}.
d1607 1
@


1.180
log
@ * When applying patches, also look in $LOCALPATCHES/$PKGPATH for
   any local patches that the user wants to maintain outside of
   pkgsrc.
 * print-PLIST: ignore Linux procfs entries
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.179 2001/08/22 17:59:11 jlam Exp $
d1607 1
@


1.179
log
@Minor clarifications for buildlink section.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.178 2001/08/22 17:53:30 jlam Exp $
d714 10
d1250 7
a1256 6
   After extraction, all the patches named by the PATCHFILES and those
   present in the patches subdirectory of the package are applied. 
   Patchfiles ending in .Z or .gz are uncompressed before they are
   applied, files ending in .orig or .rej are ignored.  Any special
   options to patch(1) can be handed in PATCH_DIST_ARGS.  See section
   4.3 for more details.
@


1.178
log
@Define the terms "weakly-buildlinked" and "strongly-buildlinked"
(my math background shows...).
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.177 2001/08/13 18:09:06 hubertf Exp $
d1519 1
a1519 1
  (1c) Links all the headers and libraries for that package into
d1555 1
a1555 1
through bsd.buildlink.mk, which is included by package buildlink.mk files.
@


1.177
log
@ * Add 10.22: What's the proper way to create an account from a package?
 * Re-format things so they don't get into the TOC

XXX I don't think 10.19 and 10.20 really belong into the FAQ section...
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.176 2001/07/30 17:17:20 jlam Exp $
d1501 1
d1505 1
@


1.176
log
@Typo: ${X11BASE}} -> ${X11BASE}.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.175 2001/07/26 15:14:05 jlam Exp $
d2126 18
a2143 18
======================================================================
You may wish to have the vulnerabilities file downloaded daily so that
it remains current.  This may be done by adding an appropriate entry
to the root users crontab(5) entry.  For example the entry

# download vulnerabilities file
0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1

will update the vulnerability list every day at 3AM.

In addition, you may wish to run the package audit from the daily
security script.  This may be accomplished by adding the following
lines to /etc/security.local

if [ -x ${PREFIX}/sbin/audit-packages ]; then
        ${PREFIX}/sbin/audit-packages
fi
======================================================================
d2150 6
@


1.175
log
@Document USE_OPENSSL_VERSION when using openssl/buildlink.mk.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.174 2001/07/20 02:00:47 jlam Exp $
d1546 1
a1546 1
${X11BASE}}
@


1.174
log
@Make the example buildlink.mk file more complete by showing how
dependencies on the package are added through buildlink.  Also show how
to use EVAL_PREFIX to set BUILDLINK_PREFIX.foo.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.173 2001/07/17 21:19:37 jlam Exp $
d1596 12
a1607 6
In addition, packages that have an explicit dependency on ncurses should
set USE_NCURSES to the reason why the system curses is insufficient, and
include "../../devel/ncurses/buildlink.mk" afterwards.  This helps to
identify where the system curses differs from ncurses, and when the
development of the system curses catches up in functionality, the
USE_NCURSES setting may be removed.
@


1.173
log
@Add note on -Wl,-R settings for buildlink packages based on question put
to me by Thomas Klausner <wiz@@danbala.ifoer.tuwien.ac.at> in private email.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.172 2001/07/16 11:06:48 jlam Exp $
d1560 4
a1563 1
> BUILDLINK_PREFIX.foo=		${LOCALBASE}
@


1.172
log
@Note special handling of ncurses/buildlink.mk and USE_NCURSES.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.171 2001/07/16 11:00:32 jlam Exp $
d1606 7
@


1.171
log
@Add note that the build output should be checked in the USE_BUILDLINK_ONLY
case to verify that the tag is true.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.170 2001/07/01 23:03:17 jlam Exp $
d1592 7
@


1.170
log
@In example buildlink.mk file, move inclusion of bsd.buildlink.mk to start
of file.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.169 2001/06/30 21:10:43 jlam Exp $
d1603 4
a1606 1
only through ${BUILDLINK_DIR}.
@


1.169
log
@Note that USE_MOTIF and USE_MOTIF12 may be replaced with
lesstif/buildlink.k and lesstif12/buildlink.mk, respectively.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.168 2001/06/29 14:07:28 jlam Exp $
d1558 2
a1571 2
> 
> .include "../../mk/bsd.buildlink.mk"
@


1.168
log
@Note that EVAL_PREFIX may often be removed in converting packages to use
buildlink.mk files.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.167 2001/06/29 05:07:36 jlam Exp $
d1588 2
@


1.167
log
@Add new section: Converting packages to use buildlink.mk files.  It needs
to be expanded, but what's there should help others to start using
buildlink.mk files.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.166 2001/06/23 14:29:29 jlam Exp $
d1591 6
a1596 4
If the required dependency pattern for a package differs from the default
specified in the package's buildlink.mk file, then it may be set by
defining BUILDLINK_DEPENDS.<pkgname> in the Makefile to the dependency
pattern required.
@


1.166
log
@Note caveat about how buildlink.mk doesn't currently meet goal #2 on
systems that install packages directly under ${X11BASE} (systems not using
xpkgwedge).
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.165 2001/06/23 14:19:09 jlam Exp $
d1572 28
@


1.165
log
@Fix grammar a bit in buildlink.mk section.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.164 2001/06/21 11:57:03 hubertf Exp $
d1535 12
a1546 9
Goal (2) requires some work on the part of the package builder.  As all
headers and libraries used by a package may be found in ${BUILDLINK_DIR},
and -I${BUILDLINK_DIR}/include and -L${BUILDLINK_DIR}/lib are already
passed to the compiler, it is no longer necessary to pass
-I${LOCALBASE}/include or -L${LOCABASE}/lib to the compiler.  Therefore,
those lines should be removed from package Makefiles, and where necessary,
the package sources should be patched to do the same.  If
USE_BUILDLINK_ONLY is defined, then -L${LOCALBASE}/lib is not automatically
added to LDFLAGS in bsd.pkg.mk.
@


1.164
log
@- remove empty directories (-P) after the initial checkout

- show only changes (-q), checkout added directories (-d) and
  remove empty directories (-P) in the following updates

Sent in by Martti Kuparinen <martti.kuparinen@@iki.fi> in PR 13253.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.163 2001/06/19 20:55:01 jlam Exp $
d1512 1
a1512 1
  (1a) Adding a DEPENDS or BUILD_DEPENDS line for the package.
d1514 2
a1515 2
  (1b) Creating a directory ${BUILDLINK_DIR}, by default set to a
       subdirectory of ${WRKDIR}.
d1517 2
a1518 2
  (1c) Linking all the headers and libraries for that package into
       ${BUILDLINK_DIR}/include and ${BUILDLINK_DIR}/lib, respectively.
d1520 2
a1521 2
  (1d) Prepending -I${BUILDLINK_DIR}/include to CPPFLAGS, CFLAGS, CXXFLAGS,
       and -L${BUILDLINK_DIR}/lib to LDFLAGS.
d1523 1
a1523 1
  (1e) Creating a wrapper script for GTK+-style config scripts, often found
@


1.163
log
@Document buildlink.mk methodology.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.162 2001/06/19 16:23:33 jlam Exp $
d201 1
a201 1
	% cvs checkout pkgsrc
d208 1
a208 1
	% cvs update
@


1.162
log
@Document PKGLOCALEDIR in PLIST issues.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.161 2001/06/16 04:15:08 jlam Exp $
d20 1
a20 1
 ========
d39 1
a39 1
 =============
d486 1
a486 1
 =============================
d1491 81
a1571 1
 8 Debugging
d1623 2
a1624 2
 9 FAQs & features of the package system
 =======================================
d1626 2
a1627 2
 9.1 Packages using GNU autoconfig
 =================================
d1638 2
a1639 2
 9.2 Other distrib methods than .tar.gz
 ======================================
d1652 2
a1653 2
 9.3 Packages not creating their own subdirectory
 ================================================
d1662 2
a1663 2
 9.4 Custom configuration process
 ================================
d1673 1
a1673 1
 9.5 Packages not building in their DISTNAME directory
d1682 2
a1683 2
 9.6 How to fetch all distfiles at once
 ======================================
d1717 2
a1718 2
 9.7 How to fetch files from behind a firewall
 =============================================
d1731 2
a1732 2
 9.8 If your patch contains an RCS ID
 ====================================
d1737 2
a1738 2
 9.9 How to pull in variables from /etc/mk.conf
 ==============================================
d1759 2
a1760 2
 9.10 Is there a mailing list for pkg-related discussion?
 ========================================================
d1768 2
a1769 2
 9.11 How do i tell "make fetch" to do passive FTP?
 ==================================================
d1788 2
a1789 2
 9.12 Dependencies on other packages
 ===================================
d1870 2
a1871 2
 9.13 Conflicts with other packages
 ==================================
d1894 2
a1895 2
 9.14 Software which has a WWW Home Page
 =======================================
d1904 2
a1905 2
 9.15 How to handle modified distfiles with the 'old' name
 =========================================================
d1919 2
a1920 2
 9.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
 ========================================================================
d1931 2
a1932 2
 9.17 How to handle incrementing versions when fixing an existing package
 ========================================================================
d1940 2
a1941 2
 9.18 "Could not find bsd.own.mk" - what's wrong?
 ================================================
d1952 2
a1953 2
 9.19 Restricted packages
 ========================
d1988 2
a1989 2
 9.20 Packages using (n)curses
 =============================
d1992 12
a2003 5
curses prior to 1.4Y. For packages using such functionality there are some
variables: If USE_CURSES is set in a package's Makefile, NEED_NCURSES is
set automatically to YES or NO, depending on whether a dependency on
ncurses is needed on this system. You can use this variable to e.g. add
arguments to configure to tell the package whether to use ncurses.
d2024 14
a2037 2
 9.21 Automated security check
 =============================
d2091 1
a2091 1
 10 Submitting & Committing
d2094 1
a2094 1
 10.1 Submitting your packages
d2123 1
a2123 1
 10.2 Committing: Importing the package into CVS
d2160 1
a2160 1
 11 A simple example of a package: bison
d2169 1
a2169 1
 11.1 files
d2175 1
a2175 1
 11.1.1 Makefile
d2194 1
a2194 1
 11.1.2 pkg/DESCR
d2202 1
a2202 1
 11.1.3 pkg/PLIST
d2220 1
a2220 1
 11.1.4 Checking a package "pkglint"
d2240 1
a2240 1
 11.2 Steps for building, installing, packaging
@


1.161
log
@Document BUILD_USES_GETTEXT_M4.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.160 2001/05/20 01:58:19 hubertf Exp $
d876 7
@


1.160
log
@make the bin-install target look at some FTP servers (stored in
BINPKG_SITES). As discussed on tech-pkg.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.159 2001/05/09 17:43:22 skrll Exp $
d1775 2
a1776 2
Please also note the BUILD_USES_MSGFMT definition, which is provided
as a convenience definition.  This definition works out whether
d1778 3
a1780 1
devel/gettext package.
@


1.159
log
@Improve the libtool description text. Remove an example that relies on
libtool internals.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.158 2001/05/08 14:59:26 abs Exp $
d276 7
a282 4
created (see next section) or that you put into pkgsrc/packages
manually, you can use the the "bin-install" target, which will
install a binary package - if available - via pkg_add, and do a "make
package" else.
@


1.158
log
@Note that:
Some packages have different sets of distfiles on a per architecture
basis. (A good example is www/navigator). These are kept in the
same distinfo file and care should be taken when upgrading such a
package to ensure distfile information is not lost.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.157 2001/05/04 15:09:59 agc Exp $
d1015 2
a1016 2
   (such as -L../somelib), because it is trying to force you to change
   that argument to be the .la file.  For example:
d1020 1
a1020 1
   won't work; it needs to be changed to:
d1024 1
a1024 6
   and it will DTRT with the libraries.  If you *must* use a relative path 
   with -L, and you are not going to run this program before installing
   it, you can omit the use of libtool during link and install of this
   program if you add the subdirectory ".libs" in your -L command:

	${CC} -o someprog -L../somelib/.libs -lsomelib
d1048 3
a1050 3
If your package makes use of the platform independant method of loading
dynamic shared objects libltdl then you should add USE_LTDL= yes to the
Makefile.
d1052 2
a1053 2
Some packages use libtool incorrectly so that the package may work or build
on NetBSD. Some common errors are
@


1.157
log
@Minor refinements to the section on audit-packages, with many thanks
to Hubert for the original.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.156 2001/05/03 21:38:29 hubertf Exp $
d646 5
@


1.156
log
@Add entry on automated security checking
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.155 2001/05/01 16:06:27 dmcmahill Exp $
d1928 13
a1940 9
Third party software as provided by pkgsrc unfortunately has it's bugs just
as all other software has, and some of the bugs are security related. To
aid in an automated check, users can install the
pkgsrc/security/audit-packages package, which will provide two scripts:

(1) download-vulnerability-list, an easy way to download a list of
security vulnerabilities which have been published.  This list is kept
up to date by the NetBSD security officer.  It is held at the
well-known URL:
d1942 1
a1942 1
ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/vulnerabilities
d1945 28
a1972 2
each vulnerability listed by the security officer.  If a vulnerable
package is installed, it will be shown by output to stdout.
@


1.155
log
@provide 2 examples of cdpack usage in the bulk->cdpack section.  Suggested
by Hubert.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.154 2001/04/28 14:28:26 dmcmahill Exp $
d1923 25
@


1.154
log
@add a short section about creating multi-cd binary package sets at the
end of the bulk build section.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.153 2001/04/27 15:40:47 hubertf Exp $
d481 32
@


1.153
log
@Add description how to get pkgsrc via CVS, contributed by
Mipam <mipam@@ibb.net>, with some editing from me.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.152 2001/04/25 07:27:44 skrll Exp $
d462 4
d472 9
@


1.152
log
@Replace cc with ${CC} in libtool example.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.151 2001/04/17 12:50:04 agc Exp $
d181 3
d193 16
@


1.151
log
@Update for the distinfo changes.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.150 2001/04/17 08:18:30 hubertf Exp $
d917 1
a917 1
	${LIBTOOL} --mode=link cc -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor
@


1.150
log
@Note that pkg_install can be installed w/o the text set installed if
NOMAN=YES is set in the environment.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.149 2001/04/14 19:20:47 dmcmahill Exp $
d565 2
a566 2
 4.2 files/*
 ===========
d568 20
a587 19
 * files/md5:
   Most important, the mandatory md5 checksum of all the distfiles needed for
   the package to compile, confirming they match the original file any patches
   were generated against. This ensures that the distfile retrieved from the
   Internet has not been corrupted during transfer or altered by a malign force
   to introduce a security hole. It can be generated by hand using the md5(1)
   command or by invoking "make makesum".

 * files/patch-sum:
   The checksum file for all the official patches for the package, found in the
   patches/ directory (see section 4.3). This checksum file includes an MD5
   checksum of all lines in the patch file except the NetBSD RCS Id. This file
   is generated by invoking "make makepatchsum".

Besides that, if you have any files that you wish to be placed in the
package prior to configuration or building, you could place these files
here and use a ${CP} command in the pre-configure target to achieve this.
Alternatively, you could simply diff the file against /dev/null and use the
patch mechanism to manage the creation of this file.
d743 9
d1149 2
a1150 2
   After the distfile(s) are fetched, their MD5 checksum is generated and
   compared with the checksums stored in the files/md5 file. If the
d2001 1
a2001 1
> OK: checking files/md5.
d2037 1
a2037 1
Generate the checksum of the distfile into files/md5:
@


1.149
log
@document the possibility of a pre-build.local file for bulk builds
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.148 2001/03/29 11:20:57 agc Exp $
d604 4
d610 2
a611 2
into the NetBSD CVS tree. To avoid this, use the "-U 2" or "-U 1" option to
diff.
d1759 4
a1762 1
(nroff, ...). Please do that.
@


1.148
log
@Document the EVAL_PREFIX (and the related <dirname>_DEFAULT) definitions.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.147 2001/03/27 03:19:43 hubertf Exp $
d354 14
@


1.147
log
@Change BUILD_DEPENDS semantics:
first component is now a package name+version/pattern, no more
executable/patchname/whatnot.

While there, introduce BUILD_USES_MSGFMT as shorthand to pull in
devel/gettext unless /usr/bin/msgfmt exists (i.e. on post-1.5 -current).

Patch by Alistair Crooks <agc@@netbsd.org>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.146 2001/03/23 17:11:17 skrll Exp $
d1083 22
@


1.146
log
@Handle the symlinks created by libtool on a.out for certain invocations
of libtool involving the -release option.

print-PLIST on an a.out machine probably doesn't handle these, i.e. it
doesn't remove them from the PLIST.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.145 2001/03/19 17:36:52 wiz Exp $
d1594 3
a1596 23
[In the following examples, the BUILD_DEPENDS dependencies have the format:
<file>:<directory containing package to build>[:<stage>] If the <stage>
isn't specified, it defaults to ``install''. If the file contains a '/', it
is interpreted as a regular file - otherwise, the name is taken to be an
executable file, and the PATH is searched for <file>. If the regular file
is not found, or the executable file is not in the path, then the
pre-requisite package will be built from the sources in <directory
containing the package to build>. The DEPENDS definition specifies a
package name (which contains its version number), and the directory
containing the package to build if this version of the package is not
installed.]

(a) If your package needs files from another package to build, see the
print/ghostscript5 package (it relies on the jpeg sources being
present in source form during the build):

BUILD_DEPENDS+=  ../../graphics/jpeg/${WRKDIR:T}/jpeg-6a:../../graphics/jpeg:extract

(b) If your package needs to use another package to build itself, this
is specified using the BUILD_DEPENDS definition, but without
specifying the stage ``:extract'' in (a) above.  An example is the
print/lyx package, which uses the latex binary during its build
process:
d1598 2
a1599 1
BUILD_DEPENDS+=  latex:../../print/teTeX
d1601 13
a1613 1
(c) If your package needs a library with which to link, this is
d1617 1
a1617 1
DEPENDS+=       xpm-3.4j:../../graphics/xpm
d1621 6
a1626 1
DEPENDS+=	xpm-*:../../graphics/xpm
d1628 2
a1629 6
Note that such wildcard dependencies are retained when creating
binary package. The dependency is checked when installing the binary
package and any package which matches the pattern would be used.
Beware that wildard dependencies should be used with a bit of care.
Simple example for package which needs some version of Tk installed,
but doesn't care which exactly - dependency
d1631 1
a1631 1
DEPENDS+=	tk-*:../../x11/tk80
d1634 2
a1635 1
needed. ALWAYS ensure that the wildcard doesn't match more than it should.
d1637 3
a1639 1
(d) If your package needs some executable to be able to run correctly, this
d1644 1
a1644 1
DEPENDS+=        teTex-*:../../print/teTeX 
d1648 14
@


1.145
log
@Document PLIST_SUBST.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.144 2001/03/19 11:28:47 dmcmahill Exp $
d901 1
a901 1
   platform. This will be handled automatically soon.
@


1.144
log
@document BULK_PREREQ.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.143 2001/03/12 11:23:01 skrll Exp $
d791 1
a791 1
 5.2 $PLIST_SRC
d799 11
d811 1
a811 1
 5.3 Perl5 modules
@


1.143
log
@Re-enable the -release option of libtool. ELF is fully supported with a.out
support to follow. Note this in documentation.

Bump revision of libtool to nb3 and update dependencies.

Update (sort) known affected PLISTs.

Fixes pkg/12368 by Kimmo Suominen <kim@@tac.nyc.ny.us>
Fixes problems with cross/* noted on tech-pkg and packages by
	Chuck Cranor <chuck@@research.att.com>, and
	Thomas Klausner <wiz@@danbala.ifoer.tuwien.ac.at>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.142 2001/02/27 08:20:23 skrll Exp $
d337 7
@


1.142
log
@Update libtool to be based on a CVS snapshot of the multi-language branch
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.141 2001/02/17 15:09:51 skrll Exp $
d880 4
a883 2
   The "-release" option has been disabled in the pkgsrc version of libtool
   as it creates unnecessary differences between ELF and a.out platforms.
@


1.141
log
@Minor changes from Yuji Yamano <yyamano@@kt.rim.or.jp> in pkg/12227
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.140 2001/02/16 13:06:17 wiz Exp $
d877 2
a878 3
   the -version-info esp. when major and minor are zero, as libtool will
   strip off the shared library version else. Also, any "-release" should
   be removed, as it removes the version info as well.
d880 6
a885 1
   PLIST gets all of the .a, .la and so, .so.major and .so.major.minor
d936 18
@


1.140
log
@Change COMMENT handling:
COMMENTs are now a variable in the Makefile instead of a pkg/COMMENT
file. The COMMENT var should be in the maintainer block after the
homepage.
Modify bsd.pkg.mk, pkglint, url2pkg, and port2pkg (last one untested)
for the new behaviour. Document new state in Packages.txt.
This should save lots of inodes, and lots of time when untarring/updating.
Idea by Alistair Crooks.
For the time being, accept pkg/COMMENT instead of a COMMENT var to avoid
a flag day.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.139 2001/02/09 14:48:39 agc Exp $
d671 1
a671 1
 * pkg/MESSAGE
d858 1
a858 1
Here's how to use libtool in a pkg in six simple steps:
d1186 1
a1186 2
   and "make install" (or whatever DEPENDS_TARGET is set to) for these
   packages.
@


1.139
log
@Add more text for developers explaining importing packages.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.138 2001/02/09 14:32:27 agc Exp $
d352 1
a352 1
/etc/rc.local. Also, if you use a OS version below 1.5 or stil want
d405 1
a405 1
.usr/pkgsrc/.broken  (or .../.broken.${MACHINE} if OBJMACHINE is set),
d455 5
a459 3
package and the MAINTAINER name. This is so that anyone who quibbles with
the (always completely correct) decisions taken by the guy who maintains
the port can complain vigorously.
d484 9
a492 12
        archivers      devel          math           shells
        audio          editors        mbone          sysutils
        benchmarks     emulators      meta-pkgs      templates
        biology        finance        misc           textproc
        cad            fonts          net            time
        chat           games          news           wm
        comms          graphics       parallel       www
        converters     ham            pkgtools       x11
        corba          japanese       plan9
        cross          lang           print
        databases      mail           security
  
d537 6
a628 5
 * pkg/COMMENT:
   A one-line description of the piece of software. There is no need to
   mention the package's name - this will automatically be added by the
   pkg_* tools when they are invoked.

d673 7
a679 2
   Useful for things like legal notices on almost-free software,
   etc.
d1779 1
a1779 1
   (contents of pkg/COMMENT are OK) and the URL of your tar-file.
d1851 1
d1859 1
a1859 7
 11.1.2 pkg/COMMENT
 ==================

> GNU yacc clone.


 11.1.3 pkg/DESCR
d1867 1
a1867 1
 11.1.4 pkg/PLIST
d1885 1
a1885 1
 11.1.5 Checking a package "pkglint"
d1891 1
a1891 1
directory of the package you which to examine and execute "pkglint":
a1893 1
> OK: checking pkg/COMMENT.
d1901 2
a1902 2
intensive checks will be performed. Use e.g. "pkglint -a -v" for a very
detailed and verbose check.
d1915 1
a1915 1
Create Makefile, pkg/COMMENT, pkg/DESCR and pkg/PLIST as in section 11.1,
d1985 1
a1985 4
> cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o                        


                    getopt.o getopt1.o  
d2122 1
a2122 1
                1.3/
@


1.138
log
@+ correct a spelling mistake.
+ remind developers about one of the more common (and far-reaching)
problems of "cvs import", namely that files relative to the $cwd are
imported, and the given pathname is so that cvs knows where to store
these files in the repository.
+ clean up example names so that they're a bit less "amateur"
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.137 2001/02/02 03:42:42 hubertf Exp $
d1796 5
@


1.137
log
@Update list of available categories to new categories (chat, ...).
Fixes PR 12100 by Nigel Reed <nigel@@nelgin.nu>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.136 2001/01/28 03:17:41 itojun Exp $
d43 5
a47 5
Collection, either by installing a precompiled binary package, or by
building your own copy using the NetBSD package system.  The second
part, "Package Constructor's Guide", explains how to prepare a package so
it can be easily built by other NetBSD users without knowing about the
package's building details.
d1786 7
a1792 3
This section is only of interrest for NetBSD developers with write access
to the NetBSD pkgsrc repository. Newly created packages should be imported
with a vendor tag of "TNF" and a release tag of "pkgsrc-base", e.g:
d1794 2
a1795 1
	cvs import pkgsrc/<category>/frobnitz TNF pkgsrc-base
d1803 2
a1804 1
	cvs import pkgsrc/<category>/mumbler FREEBSD FreeBSD-current-1998-04-01
@


1.136
log
@refer MASTER_SITE_{GNOME,SOURCEFORGE}.  warn about use of ACCEPTABLE_LICENSES
in sample mk.conf fragment
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.135 2001/01/26 09:17:55 skrll Exp $
d482 12
a493 9
	archivers   databases   ham         net         security
	audio       devel       japanese    news        shells
	benchmarks  distfiles   lang        packages    sysutils
	biology     editors     mail        parallel    templates
	cad         emulators   math        pkglocate   textproc
	comms       fonts       mbone       pkgtools    www
	converters  games       meta-pkgs   plan9       x11
	cross       graphics    misc        print

@


1.135
log
@Remove reference to LIBTOOL_OVERRIDE. It no longer exists.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.134 2001/01/24 09:53:52 garbled Exp $
d316 3
a318 1
You may want to set things in /etc/mk.conf:
d466 2
@


1.134
log
@Add a sed string that mangles the uname -r output correctly for the new
binary packages layout on the FTP server..

Pointed out by Hubert F.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.133 2001/01/06 03:10:02 hubertf Exp $
a918 3
If the pkg already has an original "libtool" which we can replace with
devel/libtool you may have to specify LIBTOOL_OVERRIDE to the package
Makefile.
@


1.133
log
@Make it clear that it's a bad idea to try having multiple (different)
settings for LOCALBASE etc., noted by Paul Hoffman <phoffman@@proper.com>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.132 2001/01/04 15:10:17 agc Exp $
d1973 1
d2130 2
a2131 1
   ftp://ftp.netbsd.org/pub/NetBSD/packages/`uname -r`/`sysctl -n hw.machine_arch`
d2142 3
a2144 1
therein. 
@


1.132
log
@
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was
out of date - it was based on a.out OBJECT_FMT, and added entries in the
generated PLISTs to reflect the symlinks that ELF packages uses. It also
tried to be clever, and removed and recreated any symbolic links that were
created, which has resulted in some fun, especially with packages which
use dlopen(3) to load modules. Some recent changes to our ld.so to bring
it more into line with other Operating Systems also exposed some cracks.

+ Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain
the ELF symlinks.
+ Don't mess about with file system entries when handling shared objects in
bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will
have got it right, and have a much better idea than we do.
+ Modify PLISTs to contain "ELF symlinks"
+ On a.out platforms, delete any "ELF symlinks" from the generated PLISTs
+ On ELF platforms, no extra processing needs to be done in bsd.pkg.mk
+ Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on
a.out platforms
+ Update the documentation in Packages.txt

With many thanks to Thomas Klausner for keeping me honest with this.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.131 2000/12/30 11:24:31 hubertf Exp $
d261 9
@


1.131
log
@Remove paragraph about PLIST-mi/md.shared/md.static
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.130 2000/12/17 23:32:39 hubertf Exp $
d860 2
a861 1
   PLIST only gets the .a, .la and .so.major.minor entries.
d898 2
a899 3
7. In your PLIST, include the .a, .la, and .so.major.minor files.  Don't
   include the ELF symlink files (.so.major, .so); those are added
   automatic.  
@


1.130
log
@Note that ssh doesn't need to be installed in /etc/rc.conf on 1.5 systems.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.129 2000/12/15 14:03:31 abs Exp $
d763 1
a763 10
 5.2 MD/MI vs. general PLIST
 ===========================

Sometimes the packaging list in pkg/PLIST differs between platforms, e.g.
if one of them supports shared libs and the other does not. To address
this, a hook has been introduced into the NetBSD packages system to provide
a PLIST file defined on conditions set freely in the package's Makefile.


 5.2.1 $PLIST_SRC
d768 2
a769 6
The files are later concatenated using cat(1), and order of things is an
important issue, see below.


 5.2.2 PLIST-mi, PLIST-md.shared, PLIST-md.static
 ================================================
a770 40
If PLIST_SRC is not set (the usual case), and if there is no pkg/PLIST, the
packages system looks for pkg/PLIST-mi, and pkg/PLIST-md.shared or
pkg/PLIST-md.static to handle differences due to the platform being able to
handle shared libs or not. PLIST-mi contains machine independent files,
PLIST-md.* contain machine dependent files, which may differ between
architectures that don't support dynamic libs/shared loading. Currently,
this is only used in the perl-packages, and as perl5 on alpha doesn't
support dynamic loading of extensions like perl/Tk yet, PLIST.mi-static is
also used on the alpha (besides pmax and powerpc). Alpha will hopefully be
removed soon when perl's fixed for dynamic loading.

(This handling of MI/MD PLIST files is implemented by setting PLIST_SRC to
either "PLIST-mi PLIST-md.static" or "PLIST-mi PLIST-md.shared", see
/usr/pkgsrc/mk/bsd.pkg.mk).


 5.2.3 Order in the PLIST* file(s)
 =================================

There is one gotcha regarding the ordering of @@dirrm statements: any MI
@@dirrm directives that follow any MD @@dirrm's *must* go into the PLIST.md-*
files, as the files PLIST-mi and PLIST.md-{shared/static} are concatenated
in exactly this order. If the MI directory would be listed in PLIST-mi, it
would be removed before the MD directory, which wouldn't work.

E.g. if you have the following dirs:
        foo/mi
        foo/mi/md

then PLIST-mi contains:
        <nothing>

and PLIST-md.* contain:
        @@dirrm foo/mi/md
        @@dirrm foo/mi

This will lead to some @@dirrm statements being duplicated, but it's the
only way to ensure everything is properly removed. The same care must be
taken when PLIST_SRC is set to some package-specific settings.
  
@


1.129
log
@Update for fact that PATCH_FUZZ_FACTOR is on by default
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.128 2000/12/08 10:18:19 wiz Exp $
d341 3
a343 2
/etc/rc.local. Also, be sure to install ssh before starting it from
rc.local:
d346 2
a347 2
    if [ -f /usr/pkg/etc/rc.d/sshd.sh ]; then
            /usr/pkg/etc/rc.d/sshd.sh
d351 2
a352 1
after the bulk build is finished. You have been warned! :)
@


1.128
log
@REQ is no more, its place is taken by INSTALL & friends.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.127 2000/12/07 01:23:48 hubertf Exp $
d555 2
a556 3
a fuzz to avoid problems. (The latter condition is ensured by
setting PKG_DEVELOPER in /etc/mk.conf - the build will fail if a
patch applies with fuzz only).  Furthermore, do not put changes
d1114 5
a1118 5
   If PKG_DEVELOPER is set in /etc/mk.conf, patch is given special args
   to make it fail if the patches with some lines of fuzz. Please fix
   (regen) the patches so that they apply cleanly. The rationale behind
   this is that patches that apply cleanly may end up being applied in the
   wrong place, and cause severe harm there.
@


1.127
log
@Note that -release should not be used in libtool - says Rene :)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.126 2000/12/06 17:15:58 hubertf Exp $
a652 5

 * pkg/REQ:
   Require-script that is invoked before installation and de-installation
   to ensure things like certain accounts being available, user/sysadmin
   agreeing with usage policy, etc.
@


1.126
log
@For libtool section, make clear what gets into PLIST
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.125 2000/12/06 17:12:32 hubertf Exp $
d914 2
a915 1
   strip off the shared library version else.
@


1.125
log
@Add some information to lighten up the recent libtool confusion:

 * When compiling a shared lib, always include -version-info x:y (even if
   x, y are 0). PLIST gets .la and libfoo.so.x.y entries.
 * ONLY when compiling a shared object (that's later opened with dlopen(3),
   NOT a shared lib, use -module -avoid-version. PLIST only gets the foo.so
   entry.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.124 2000/11/02 03:03:39 wiz Exp $
d916 2
d921 2
@


1.124
log
@USE_CURSES logic moved to bsd.prefs.mk
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.123 2000/11/01 12:05:15 hubertf Exp $
d912 7
a918 1
   symlinks (if necessary) in the build directory.
d920 1
a920 1
4. When linking programs that depend on these libraries _before_ they are
d940 1
a940 1
5. When installing libraries, preface the install or cp command with
d949 1
a949 1
6. In your PLIST, include the .a, .la, and .so.major.minor files.  Don't
@


1.123
log
@One package per pr, please!
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.122 2000/10/22 21:25:14 hubertf Exp $
d1774 1
a1774 1
.include "../../mk/bsd.pkg.mk"
d1781 1
a1781 1
inclusion of bsd.pkg.mk, since the variable is set there.
@


1.122
log
@Expand section on fetching all distfiles (9.6) a bit, after discussion
with Robert Elz <kre@@munnari.OZ.AU> in PR 11286.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.121 2000/10/18 03:53:41 garbled Exp $
d1790 1
a1790 1
You have to seperate between binary and "normale" (source) packages here:
d1801 1
a1801 1
   section 8 and the rest of this document. Then, generate a gzipped
d1811 3
@


1.121
log
@Add a note to appendix B noting the changes to how binary packages are to be
uploaded to ftp.netbsd.org.  If you are building binary packages for 1.5,
you should read this change.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.120 2000/10/17 15:51:34 hubertf Exp $
d1473 25
a1497 2
The answer here is to do a "make fetch-list" in /usr/pkgsrc and use the
resulting list.
@


1.120
log
@ * Move section 4.7 (Importing to CVS), and merge with section 10 (Submitting)
 * Remove stray TOC for FAQs
 * Some polishing up
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.119 2000/10/17 15:29:47 hubertf Exp $
d1983 1
d2144 8
@


1.119
log
@Remove some clutter (obviously some vi user wanted to save... :-)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.118 2000/10/17 15:12:00 hubertf Exp $
a700 25
 4.7 Importing the package into CVS
 ==================================

Newly created packages should be imported with a vendor tag of "TNF" and
a release tag of "pkgsrc-base", e.g::

	cvs import pkgsrc/<category>/frobnitz TNF pkgsrc-base

Packages derived from a FreeBSD port should be imported with a vendor tag
of "FREEBSD" and a release tag of "FreeBSD-current-YYYY-MM-DD" (YYYY-MM-DD
being the date when the snapshot of the port were taken form the FreeBSD
tree), and then doing the necessary modifications by normal CVS operations.
E.g:

	cvs import pkgsrc/<category>/mumbler FREEBSD FreeBSD-current-1998-04-01
	cvs rm patches/patch-a
	cvs add patches/patch-aa
	cvs ci

Please note all package updates/additions in doc/pkg-CHANGES! It's very
important to keep this file up to date and conforming to the existing
format, because it will be used by scripts to automatically update pages on
www.netbsd.org.


a1408 22
 9.1  Packages using GNU autoconfig
 9.2  Other distrib methods than .tar.gz
 9.3  Packages not creating their own subdirectory
 9.4  Custom configuration process
 9.5  Packages not building in their DISTNAME directory
 9.6  How to fetch all distfiles at once
 9.7  How to fetch files from behind a firewall
 9.8  If your patch contains an RCS ID
 9.9  How to pull in variables from /etc/mk.conf
 9.10 Is there a mailing list for pkg-related discussion?
 9.11 How do i tell "make fetch" to do passive FTP?
 9.12 Dependencies on other packages
 9.13 Conflicts with other packages
 9.14 Software which has a WWW Home Page
 9.15 How to handle modified distfiles with the 'old' name
 9.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
 9.17 How to handle incrementing versions when fixing an existing package
 9.18 "Could not find bsd.own.mk" - what's wrong?
 9.19 Restricted packages
 9.20 Packages using (n)curses


d1761 7
a1767 2
 10 Submitting
 =============
d1788 26
@


1.118
log
@Put documentation on print-PLIST in one place.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.117 2000/10/17 15:00:18 hubertf Exp $
d15 1
a15 1
Run this command to produce a table of contents:`:w
@


1.117
log
@Make description of X11BASE line up with the rest of the described
variables.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.116 2000/10/17 14:52:31 hubertf Exp $
d788 2
a789 3
   any new files since the package was extracted. If the package installs
   files via tar(1) or other methods that don't update file access times, be
   sure to add these files manually to your pkg/PLIST!
d1346 12
@


1.116
log
@capitalize properly
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.115 2000/10/13 23:21:53 jlam Exp $
d1080 3
a1082 2
 * ${X11BASE} is where the actual X11 distribution is installed.  When looking
   for _standard_ X11 includes (not those installed by a pkg), use ${X11BASE}.
d1091 3
a1093 4
 * ${X11BASE} points to the root of the installed X11 tree. To refer to the
   installed location of an X11 package, use the ${X11PREFIX} definition (this
   will be ${X11BASE} if xpkgwedge is not installed, and ${LOCALBASE} if
   xpkgwedge is installed).
@


1.115
log
@Document SHLIB_HANDLING in misc section where it talks about ldconfig.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.114 2000/10/11 14:02:27 hubertf Exp $
d701 1
a701 1
 4.7 importing the package into CVS
@


1.114
log
@Flesh out description of 'readme' target a bit, text submitted by
Jeremy C. Reed <reed@@rainier.reedmedia.net> in PR 11156
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.113 2000/09/18 10:24:59 abs Exp $
d756 2
a757 1
   FreeBSD.
@


1.113
log
@sam has moved from plan9 to editors - refer to it under its new location
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.112 2000/09/15 22:05:46 hubertf Exp $
d1300 5
a1304 5
   browser such as netscape (pkgsrc/www/mozilla) or lynx (pkgsrc/www/lynx).
   The generated files contain references to any packages which are in the
   ${PACKAGES} directory on the local host.  The generated files can
   be made to refer to URLs based on FTP_PKG_URL_HOST and
   FTP_PKG_URL_DIR.  (For example, if I wanted to generate README.html
d1308 1
a1308 1
   subdirectories will be searched for all the binary packages.)
@


1.112
log
@Bulk build framework
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.111 2000/09/08 12:55:12 hubertf Exp $
d1460 1
a1460 1
look at the package for plan9/sam, which uses a gzipped shell archive
d1475 1
a1475 1
plan9/sam again, but the quick answer is:
@


1.111
log
@Mention some more variables needed for bulk builds, most
important DEPENDS_TARGET.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.110 2000/09/07 09:53:13 hubertf Exp $
d301 5
a305 2
 3.2.1 /etc/mk.conf and other configuration
 ==========================================
d321 4
a324 1
                            limited-redistribution
d327 8
d356 4
a359 3
Update your pkgsrc, make sure you don't need any of the packages still
installed. Be sure to remove all other things (from /usr/local, ...).
Become root and type:
a360 1
	$ su
d362 28
a389 3
	# pkg_delete -rR \*
	# rm */*/.broken*
        # make bulk-package
d396 1
a396 1
these borken package builds later. 
d399 1
a399 1
 3.2.4 Disk space requirements
d403 1
a403 1
1.4.2/i386:
d406 1
a406 1
 * Full set of all binaries:           800MB (NFS ok)
d413 1
a413 1
wasted. 
@


1.110
log
@When prepare a machien for bulk builds, take into account that the
ssh pkg could be deleted by some amok running script, and install ssh
via "make bulk-install".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.109 2000/08/27 10:59:53 jlam Exp $
a305 3
    PACKAGES?=       ${PKGSRCDIR}/packages/${MACHINE_ARCH}
    OBJMACHINE?=    1                    # use work.${MACHINE_ARCH}
    WRKOBJDIR?=     /usr/tmp/pkgsrc      # build here instead of in pkgsrc
d307 14
a320 1
    FAILOVER_FETCH=         yes          # insist on the correct checksum
@


1.109
log
@Add new section 5.3 which describes PLISTs for perl5 modules.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.108 2000/08/25 20:30:20 tron Exp $
d316 2
a317 2
Drop your favourite login shell in /usr/local, or pkg_add it from
/etc/rc.local. Also, be sure to pkg_add ssh before starting it from
d320 1
a320 1
    /usr/sbin/pkg_add /usr/pkgsrc/packages/i386/All/ssh-1.2.27.tgz
@


1.108
log
@Add a "Requirements" sections to chapter 2 (Installing by Building)
which lists the NetBSD distribution sets required to build packages.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.107 2000/08/17 15:53:58 wiz Exp $
d804 17
@


1.107
log
@remove paragraph about pkglibtool
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.106 2000/08/16 19:08:20 dmcmahill Exp $
d170 9
a178 1
 2.1 Where to get pkgsrc
d192 1
a192 1
 2.2 Fetching distfiles
d212 1
a212 1
 2.3 How to build and install
@


1.106
log
@add a note suggesting that LOCALBASE should only be for pkgsrc and not
shared with other programs to prevent conflicts.  Hopefully this will help
avoid people trying to do things like LOCALBASE=/usr as in PR pkg/10783.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.105 2000/08/03 14:56:51 hubertf Exp $
a897 6
Do not use pkglibtool!  Previously, the package system used its
own version of libtool from pkgtools.  However, over time, this
version became outdated and is now deprecated.  You may see some
definitions of USE_PKGLIBTOOL in existing packages that still use
this outdated version of libtool.  Please do not use this definition
in new packages!
d910 1
@


1.105
log
@Clarify the idea behind the "Table of contents" a bit
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.104 2000/07/30 08:57:54 tron Exp $
d229 8
a236 3
in your environment.  There is, of course, one exception to this - X11
packages are traditionally installed in the X11 tree. The definition
used to identify the root of the X11 tree is the X11BASE definition.
@


1.104
log
@Document "info" target.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.103 2000/07/29 10:10:43 wiz Exp $
d15 1
@


1.103
log
@Add section about how to use USE_CURSES, NEED_NCURSES, and
REPLACE_NCURSES.
Unrelated whitespace fix.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.102 2000/07/28 01:40:05 hubertf Exp $
d1219 4
a1290 1

@


1.102
log
@One more preparational step for people who want to try the bulk
targets (cut&paste-ready)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.101 2000/07/28 01:19:43 hubertf Exp $
d1344 1
a1344 1
 9.1 Packages using GNU autoconfig
d1363 1
d1688 28
@


1.101
log
@Document bulk bilding (process for portmasters etc., and the targets,
in case someone cares for what they do ;-)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.100 2000/07/21 06:56:35 rh Exp $
d324 1
@


1.100
log
@Sync description of REINSTALL with reality.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.99 2000/07/20 12:58:11 rh Exp $
d249 4
a252 1
 3 Making a precompiled package
d254 1
a254 1

d275 77
d1266 20
@


1.99
log
@Add NO_CDROM to the list of deprecated variables for package restriction.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.98 2000/07/20 12:56:13 rh Exp $
d1093 1
a1093 1
   Resuming an interrupted 'make update' will only work as long as the
d1095 1
a1095 1
   packages to be updated has been changed, resuming 'make update' will
d1115 3
a1117 3
      Use "reinstall" instead of ${DEPENDS_TARGET} for every package
      that gets updated.  Be sure you know the implications of using
      the "reinstall" target when using this variable.
@


1.98
log
@Add an FAQ entry about restricted packages noting usage of the new
NO_{SRC,BIN}_ON_{FTP,CDROM} variables.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.97 2000/07/19 02:27:16 hubertf Exp $
d1583 2
a1584 2
Please note that the use of NO_PACKAGE, IGNORE, or other generic make
variables to denote restrictions is deprecated, because they
@


1.97
log
@fix missing ", pointed out by Federico Lupi in private mail
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.96 2000/07/16 17:20:20 hubertf Exp $
d1258 4
d1495 1
d1505 1
d1520 1
d1529 1
d1538 1
d1551 37
d1592 1
a1592 1
   Our policy is that we accept binaries from only NetBSD developers to
@


1.96
log
@clarify auto-handling of ELF shlib-links a bit
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.95 2000/07/06 16:52:12 hubertf Exp $
d419 1
a419 1
into the NetBSD CVS tree. To avoid this, use the "-U 2" or -U 1" option to
@


1.95
log
@Add note on 'make bin-install'
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.94 2000/07/06 15:08:30 hubertf Exp $
d808 2
a809 1
   include the ELF symlink files; those are automatic. 
@


1.94
log
@Add some bits for PKG_DEVELOPER
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.93 2000/07/01 20:12:03 hubertf Exp $
d241 6
@


1.93
log
@Add FAQ entry: "Could not find bsd.own.mk" - what's wrong?
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.92 2000/06/30 11:09:53 wiz Exp $
d404 6
a409 4
The patch-?? files should be in diff -bu format, and apply without a fuzz
to avoid problems. Furthermore, do not put changes for more than one file
into a single patch-file, as this will make future modifications more
difficult.
d970 6
d1175 5
d1190 1
@


1.92
log
@Update list of categories (no more corba).
Add two paragraphs recommending use of the pkgdiff package.
Improve wording of paragraph about pkg-CHANGES.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.91 2000/06/30 10:23:28 agc Exp $
d1508 12
@


1.91
log
@Update Packages.txt to reflect reality - there has been a way of
installing X11 packages in ${LOCALBASE} for a while now.
Document the new X11PREFIX definition, which points to X11BASE by
default, or LOCALBASE if xpkgwedge is installed.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.90 2000/06/16 09:18:34 hubertf Exp $
d317 8
a324 7
	archivers   corba      graphics  meta-pkgs  print      
	audio       cross      ham	 misc       security
	benchmarks  databases  japanese  net        shells
	biology     devel      lang      news       sysutils 
	cad         editors    mail      parallel   textproc
	comms       emulators  math      pkgtools   www
	converters  games      mbone     plan9      x11
d414 10
d568 4
a571 3
Please note all package updates/additions in doc/pkg-CHANGES! Its very important
to keep this file up to date, because it will be used by scripts to
automatically update some pages on www.netbsd.org.
@


1.90
log
@Document print-PLIST target
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.89 2000/06/02 06:08:41 rh Exp $
d229 6
a234 13
packages are traditionally installed in the X11 tree.  The environment
variable which governs an X11 package's location is X11BASE.  So to
install an X11 package into /usr/local/X11R6, set

	X11BASE=/usr/local/X11R6

in your environment.

However, beware that strange things may happen if you install X11
packages outside the X11 tree, in that libraries and header files may
not be found by other software, and Application Defaults may not be
found.  For that reason, you are advised to leave X11 packages in the
X11 tree.  We are looking at ways to change this. 
d237 2
a238 2
at build time. Have a look at /usr/pkgsrc/mk/mk.conf.example to get an
overview of what you can set there. Environment variables such as
d906 2
a907 1
   X11BASE or LOCALBASE depending on a configuration option in /etc/mk.conf.  
d912 5
d978 1
a978 1
   package installed in $X11BASE but xmkmf not being run, set USE_X11BASE
@


1.89
log
@Actually, we describe how to use libtool in six simple steps, not seven :-)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.88 2000/06/02 01:52:10 hubertf Exp $
d628 6
d1188 3
a1190 2
 - find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla: if this brings up any files,
   they are missing in pkg/PLIST*; add them.
@


1.88
log
@ * Remove an obsolete paragraph which tried to describe how to use libtool
 * Put description on how to use the libtool pkg on GNU pkgs that come with
   their own libtool
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.87 2000/06/01 11:28:08 rh Exp $
d739 1
a739 1
Here's how to use libtool in a pkg in seven simple steps:
@


1.87
log
@Add note about obsolete pkglibtool.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.86 2000/05/11 14:55:56 agc Exp $
a738 4
To use "libtool", add a build-dependency on the libtool-pkg, then modify
the pkg's sources to use libtool for building it's libraries and add the
resulting patches to your pkg's patches-directory. 

d791 9
a799 5
Please do not use pkglibtool!  Previously, the package system used its
own version of libtool from pkgtools.  However, over time, this version
became outdated and is now deprecated.  You may see some definitions of
USE_PKGLIBTOOL in existing packages that still use this outdated version
of libtool.  Please do not use this definition in new packages!
a800 1
FOR GNU PKGS THAT ALREADY SUPPORT LIBTOOL: 
d810 1
a810 1
 6.3 Gotchas of FreeBSD ports
d853 1
a853 1
 6.4 Feedback to the author
@


1.86
log
@Fix typo, pointed out by Hubert Feyrer
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.85 2000/05/11 11:23:20 agc Exp $
d795 6
d806 1
a806 1
overridden, using the pkgtools/pkglibtool instead of the pkg's own libtool.
d808 1
a808 1
pkgtools/pkglibtool you may have to specify LIBTOOL_OVERRIDE to the package
a809 1

@


1.85
log
@Define a new target, "show-pkgsrc-dir", which prints the directory
from which an installed package can be re-installed.  This can be used
to build up a list of host specific packages, which is useful, for
example, in re-building all packages on a machine for a.out to ELF
transition.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.84 2000/04/20 16:06:23 jdolecek Exp $
d1144 1
a1144 1
   target "show-specific-pkgs"
@


1.84
log
@Warn about too-generous wildcard dependencies, which may prove bogus (using
tk-* as example). Also fix no more accurate info regarding wildcard deps -
they are now retained even for binary packages.

Suggested by David Brownlee.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.83 2000/03/10 17:57:11 hubertf Exp $
d1137 8
@


1.83
log
@Stop phantasizing about merging pkgs back into FreeBSD, instead tell people
to submit patches that apply without fuzz. (Maybe someone could explain the
exact issues with this).
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.82 2000/02/10 22:39:34 abs Exp $
d1394 11
a1404 3
Note that these wildcards will be expanded while creating binary packages.
Thus binary package will depend on exactly the version which was installed
when they were created.
d1413 2
@


1.82
log
@A raft of changes from David Maxwell
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.81 2000/02/10 02:09:17 abs Exp $
d410 4
a413 7
The patch-?? files should be in diff -bu format. This is because (not only)
the FreeBSD ports tsar finds this format easier to read than context diffs,
and so you have more chance of getting your NetBSD package accepted as part
of the FreeBSD ports system if you format your diffs in a unified fashion.

Furthermore, do not put changes for more than one file into a single
patch-file, as this will make future modifications more difficult.
d1453 1
a1453 1
 9.16 What does "Don't know how to make /usr/share/tmap/tmac.andoc" mean?
d1457 1
a1457 1
from make that it doesn't know how to make /usr/share/tmap/tmac.andoc? This
@


1.81
log
@Add a brief section explaining the 'nb<N>' suffix.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.80 2000/01/14 10:32:35 abs Exp $
d92 1
a92 1
 * RCS IDs:
d281 1
a281 1
doing it from scratch, there is a number of files involved which are
d324 7
a330 6
	archivers   corba      games     meta-pkgs  security
	audio       cross      graphics  misc       shells
	benchmarks  databases  lang      net        sysutils
	cad         devel      mail      news       textproc
	comms       editors    math      plan9      www
	converters  emulators  mbone     print      x11
d380 13
a392 14
Most important, this directory contains the (mandatory) md5 checksum of all
the distfiles needed for the package to compile. This file - files/md5 -
contains an md5 checksum of the distribution file(s) to ensure that the
distfile retrieved from the Internet has not been altered by a malign force
to introduce a security hole or was corrupted during transfer. The file
contains the md5 checksum of the original distribution file used to create
the NetBSD package, from which any patches were generated etc. It can be
generated by hand using the md5(1) command or by invoking "make makesum".

The files directory also includes a checksum file for all the official
patches for the package, found in the patches/ directory (see section
4.3). This checksum file is called patch-sum, and includes an MD5 checksum
of all lines in the patch file except the NetBSD RCS Id. This file is
generated using the "make makepatchsum" command.
d396 1
a396 1
here and use a cp command in the pre-configure target to achieve this.
d410 1
a410 1
The patch-?? files should be in diff -u format. This is because (not only)
d478 1
a478 1
 - Any MAN definitions in the package Makefile
d527 6
d556 1
a556 1
Packages derived from a FreeBSD port could be imported with a vendor tag
d568 2
a569 2
to keep this file uptodate, cause it will be used from scripts to automatically
update some pages on www.netbsd.org.
d575 2
a576 2
This section addresses some special issues that one needs to take attention
of when dealing with the PLIST file (or files, see below!).
d582 2
a583 2
 * RCS Id:
   Be sure to add a RCS ID line as the first thing in any PLIST file your
d800 1
a800 1
package Makefile for the quick way to bypass the pkg's own libtool.
d802 5
a806 4
If USE_LIBTOOL and LTCONFIG_OVERRIDE defined, specified ltconfig is
overrided for using libtool-pkg instead of the pkg's own libtool.
If pkg has already original "libtool" which we can substitute by libtool-pkg,
you may possibly have to specify LIBTOOL_OVERRIDE to the package Makefile.
d856 5
a860 5
do special steps to make it run under NetBSD or if you enhanced the
software in various other ways, be sure to report these changes back to the
original author of that program! Only with that kind of support, the next
release of the program can incorporate these fixes, and also people not
using the NetBSD packages system can win from your efforts.
d1132 1
a1132 1
   the package.
a1141 1

d1184 5
d1196 17
d1283 3
a1285 3
If you are sitting behind a firewall, you must specify the relevant proxy
hosts to enable you to talk to other machines on the Internet which are not
behind your firewall. This is an environment variable in the form of a URL
d1334 15
a1348 1
Add the following to your /etc/mk.conf file: PASSIVE_FETCH=1
d1476 1
a1476 1
   Our policy is that we accept only binaries from NetBSD developers to
@


1.80
log
@some corrections by David Maxwell
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.79 2000/01/14 09:20:47 rh Exp $
d1422 7
@


1.79
log
@Clarify that resuming 'make update' on an unclean source tree will most
certainly fail if the package to be updated changes between the initial
and subsequent 'make update's.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.78 2000/01/13 23:39:18 hubertf Exp $
d62 1
a62 1
   (compiling), installing and removing of packages.
d127 2
a128 2
 1.2 How to do
 =============
d139 4
a142 1
	pkg_add ftp://ftp.netbsd.org/pub/packages/`sysctl -n hw.machine_arch`/All/package.tgz
d144 3
a146 4
Please note that sysctl is used here to automatically determine the right
set of binary files. Also note that any packages needed to run the package
in question will be installed, too, assuming they are present where you
install from.
d188 1
a188 1
If it's not, then ftp(1) is used to fetch the distribution files
d193 4
a196 1
to find some examples. This may save some of your bandwith and time.
d219 1
a219 1
system by building as shown in A.1.
d245 3
a247 1
overview of what you can set there.
d434 1
a434 1
replace any occurance of /usr/local in any "Makefile"s in the original
d462 1
a462 1
   share your sense of humour (or spelling idiosyncracies), and that others
d728 1
a728 1
dynamic loading at all. To accompany this, verying commands and options
d810 1
a810 1
any ${PREFX} setting properly.  To change this, add something like the
d949 1
a949 1
   and its invokcation results in generation of header files,
d1324 1
a1324 1
is not found, or the exectable file is not in the path, then the
d1375 1
a1375 1
In this case you can set CONFLICTS to a space seperated list of packages
d1408 2
a1409 2
site (beware, any mirrors may not be upto date yet!), and to remove the 
old distfile from ftp.netbsdorg's /pub/NetBSD/packages/distfiles directory.
@


1.78
log
@Add:
 9.16 What does "Don't know how to make /usr/share/tmap/tmac.andoc" mean?

I've seen this the second time now, which sure makes it a FAQ :)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.77 2000/01/05 21:59:16 hubertf Exp $
d1035 3
a1037 2
   currently installed, then performing a series of "make deinstall",
   "make clean", and "make install" for these packages.
d1040 10
a1049 5
   previous "make update" was interrupted for some reason.  However, make
   sure you don't call "make clean" or otherwise remove the list of
   dependent packages in ${WRKDIR}.  Otherwise you lose the ability to
   automatically update the current package along with the dependent
   packages you have installed.
@


1.77
log
@Note that the debugging procedure not only applies to packages that
come from FreeBSD.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.76 2000/01/05 19:40:21 hubertf Exp $
d1400 9
@


1.76
log
@Use += consistently for assigning any DEPENDS
Noted by Thomas Klausner <wiz@@danbala.ifoer.tuwien.ac.at>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.75 1999/12/07 08:58:59 sakamoto Exp $
d1126 5
a1130 4
To check out all the gotchas when building a package from a FreeBSD port,
here are the steps that I do in order to get a package working. Please note
this is basically the same as what was explained in the previous sections,
only with some debugging aids.
@


1.75
log
@Add notes for LTCONFIG_OVERRIDE and LIBTOOL_OVERRIDE definition
to "FOR GNU PKGS THAT ALREADY SUPPORT LIBTOOL" subsection.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.74 1999/12/04 18:00:08 hubertf Exp $
d1321 1
a1321 1
BUILD_DEPENDS=  ../../graphics/jpeg/${WRKDIR:T}/jpeg-6a:../../graphics/jpeg:extract
d1329 1
a1329 1
BUILD_DEPENDS=  latex:../../print/teTeX
d1350 1
a1350 1
DEPENDS=        teTex-*:../../print/teTeX 
@


1.74
log
@s/troja/trojan/k, noted by Thomas Klausner.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.73 1999/11/26 18:06:21 hubertf Exp $
d786 7
a792 4
Add USE_LIBTOOL=yes to the package Makefile.  You may possibly have to
modify the "configure" script not to check for or configure its own
libtool.  See the libwww pkg, patch-ab, for the quick way to bypass
the pkg's own libtool.
@


1.73
log
@Add #9.15: How to handle modified distfiles with the 'old' name
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.72 1999/11/23 16:38:22 dmcmahill Exp $
d1394 1
a1394 1
the distfile was really updated on purpose, and that no troja horse or so
@


1.72
log
@Update the DEPENDS section to remove the depricated RUN_DEPENDS variable.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.71 1999/11/17 15:57:45 agc Exp $
d914 2
a915 1
   e.g. by some malign force or network lossage. 
d1383 13
@


1.71
log
@Fix a typo. Noted by Yuji Yamano, in PR 8818.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.70 1999/10/31 19:45:15 rh Exp $
d1294 13
a1306 14
Your package may depend on some other package being present - and
there are various ways of expressing this dependency.  NetBSD supports
the BUILD_DEPENDS, RUN_DEPENDS and DEPENDS definitions (beware:  the
DEPENDS definition is not the same as FreeBSD's deprecated one, and
NetBSD does not use the FreeBSD LIB_DEPENDS definition any more - it
proved problematic on ELF NetBSD platforms).

[In the following examples, the BUILD_DEPENDS and RUN_DEPENDS
dependencies have the format:  <file>:<directory containing package to
build>[:<stage>] If the <stage> isn't specified, it defaults to
``install''.  If the file contains a '/', it is interpreted as a
regular file - otherwise, the name is taken to be an executable file,
and the PATH is searched for <file>.  If the regular file is not
found, or the exectable file is not in the path, then the
d1308 1
a1308 1
containing the package to build>.  The DEPENDS definition specifies a
d1341 6
a1346 4
(d) If your package needs some executable to be able to run correctly,
this is specified using the RUN_DEPENDS definition.  The print/lyx
package needs to be able to execute the latex and ispell binaries when
it runs, and that is specified:
a1347 2
RUN_DEPENDS=    latex:../../print/teTeX \
                ispell:../../textproc/ispell
@


1.70
log
@Document new behaviour of "update" target.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.69 1999/09/29 15:23:54 agc Exp $
d1003 1
a1003 1
   called anymore, etc.) You will not usually ned to do this.
@


1.69
log
@Mention the port2pkg package in the section about converting a FreeBSD
port to a NetBSD package.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.68 1999/09/12 01:40:02 hubertf Exp $
d1032 1
a1032 3
   "make clean", and "make install" for these packages.  The following
   variables can be used either on the command line or in /etc/mk.conf to
   alter the behaviour of "make update":
d1034 9
a1042 6
    - REINSTALL:
      Do not recreate the list of depending packages, and do not
      "make clean" for every package that gets updated.  This is
      useful if you want to resume the updating process after an
      error or pressing Control-C, e.g. through
      "make update REINSTALL=1".
d1048 32
@


1.68
log
@Add note about our policy of handling user-supplied binary packages.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.67 1999/09/09 22:10:56 tron Exp $
d471 4
@


1.67
log
@Suggest that package submission include package name and version
number in the synopsis line of the PR.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.66 1999/09/08 20:57:22 hubertf Exp $
d1351 5
a1355 4
   Please contact us for directions on how to provide your precompiled
   binary packages.
   [XXX - need more info here - do we have a incoming-dir for such things
          on ftp.netbsd.org? - hubertf]
@


1.66
log
@pkg/DEINSTALL is called before and after the files are removed.
Noted by Jim Wise.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.65 1999/08/31 08:38:57 rh Exp $
d1362 3
a1364 2
   send-pr with category "pkg", a short description of your package
   (contents of pkg/COMMENT are OK), plus the URL of your tar-file.
@


1.65
log
@Remove bogus information about ${INSTALL_TARGET}.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.64 1999/08/30 22:54:26 tron Exp $
d484 3
a486 3
   This script is executed before any files are removed.  It is this
   script's responsibility to clean up any additional messy details around
   the package's installation, since all pkg_delete knows how to do is
@


1.64
log
@Mention that wildcard dependences now work at source level.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.63 1999/08/30 22:48:05 tron Exp $
a1038 4
    - INSTALL_TARGET:
      Install target to use for the package to update.  Defaults
      to "install".  E.g. "make update INSTALL_TARGET=package"

d1040 3
a1042 2
      Install target to use for the depending packages.  Defaults
      to "install".  E.g. "make update DEPENDS_TARGET=package"
@


1.63
log
@Update section 9.13 to mention auto conflicts between package with the
same name and a different version string. Fixes PR pkg/8293 by
Geoff C. Wing.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.62 1999/08/29 22:27:11 rh Exp $
d1299 8
@


1.62
log
@Describe 'update' target.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.61 1999/08/28 11:36:22 dmcmahill Exp $
d1319 2
a1320 2
For example pkgsrc/devel/cvs and pkgsrc/devel/cvs-current install both
the same files, thus you set in pkgsrc/devel/cvs/Makefile:
d1322 1
a1322 1
CONFLICTS=      cvs-1.9.26 cvs-1.9.27 cvs-1.9.28
d1324 1
a1324 1
and in pkgsrc/devel/cvs-current/Makefile:
d1326 1
a1326 4
CONFLICTS=      cvs-1.9 cvs-1.9.26 cvs-1.9.27

assuming that cvs is version 1.9 and cvs-current is cvs-1.9.28, and we had
already cvs-1.9.26 and cvs-1.9.27 in our pkgsrc tree.
d1328 3
@


1.61
log
@replaced an old reference to 'portlint' with 'pkglint'
fixed a typo
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.60 1999/08/22 01:31:16 hubertf Exp $
d1009 1
a1009 1
   be used either on the command line of in /etc/mk.conf to tune the
d1021 25
@


1.60
log
@Document readme-all target
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.59 1999/08/21 02:15:23 hubertf Exp $
d888 1
a888 1
   _both_ of ${X11BASE} and ${LOCALBASE}.
d1421 1
a1421 1
intensive checks will be performed. Use e.g. "portlint -a -v" for a very
@


1.59
log
@Document PKG_VERBOSE and DEINSTALLDEPENDS in conjunction with
"make deinstall".

Thanks to Ross for reminding me to commit these :-PPP
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.58 1999/08/16 14:12:40 bad Exp $
d1033 7
@


1.58
log
@PATCHFILES are fetched from PATCH_SITES.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.57 1999/07/09 15:29:43 agc Exp $
d1008 13
a1020 1
   effectively de-installing the package.
@


1.57
log
@Document the show-downlevel target.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.56 1999/07/09 15:26:42 agc Exp $
d901 1
a901 1
   MASTER_SITES. The location(s) in MASTER_SITES are in the form of URLs
@


1.56
log
@Add a very short paragraph explaining what the "show-distfiles" target
does.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.55 1999/07/09 14:53:11 agc Exp $
d1031 7
@


1.55
log
@Add documentation on the patch-sum file, and how to generate it using
the "makepatchsum" target
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.54 1999/07/02 08:37:20 agc Exp $
d1027 4
@


1.54
log
@Some packages use bsd-style .mk files when building, and so any manual
pages that are installed will be gzip-compressed, if MANZ is set, or
not if MANZ is not set.  If the package uses bsd-style .mk files, the
variable MANCOMPRESSED_IF_MANZ should be set to a value of "yes" in
the package Makefile.  This replaces the previous method of specific
inclusion of bsd.prefs.mk, followed by a check for MANZ and
conditional assignment of MANCOMPRESSED.

Add appropriate documentation, and change all necessary ocurrences in
package Makefiles.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.53 1999/04/15 20:39:38 tron Exp $
d381 6
d429 4
@


1.53
log
@Completely replace "MASTER_SITE_SUBDIR" and "PATCH_SITE_SUBDIR" with
variable substituition of "MASTER_SITES" and "PATCH_SITES".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.52 1999/02/24 10:40:58 agc Exp $
a684 2
Unfortunately, it may not always be appropriate to include that header file
without checking whether it's available:
a685 6
  [ Note that this will no longer work with NetBSD 1.3I (current)
    and later since we no longer define "unix" or "__unix__" by
    default with the compiler! Someone with knowledge how to solve
    this cleanly should correct this note.                         ]

        #if (defined(__unix__) || defined(unix)) && !defined(USG)
a686 1
        #endif
d813 6
@


1.52
log
@Correct the wrong information about ldconfig in PLIST files.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.51 1999/02/19 01:44:41 tv Exp $
d309 1
a309 1
	${MASTER_SITE_GNU:=/subdirectory/name/}
d311 2
a312 2
(Note the leading and trailing slashes after the := characters.)  Use of
the deprecated MASTER_SITE_SUBDIR will not work.
@


1.51
log
@Document ${MASTER_SITE_BLAH:=/subdir/name/}.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.50 1999/02/18 12:36:16 frueauf Exp $
d457 3
a459 5
 - If there's a "@@exec ldconfig ...", add an "@@unexec ldconfig ...", so the
   hints-file for ld.so doesn't grow without end.
 - For @@exec and @@unexec rewrite any ldconfig-command as "ldconfig ||
   /usr/bin/true", as there's no ldconfig command on some of the platforms
   NetBSD runs on (e.g. alpha).
@


1.50
log
@Remove full path for install-info from examples, we no longer enforce that.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.49 1999/02/10 14:55:00 frueauf Exp $
d295 18
@


1.49
log
@- mention pkgsrc/mk/mk.conf.example at some points I found reasonable
- description of all available options and variables is in packages(7)
- add note that part of the import/update process for a package is also noting it in doc/pkg-CHANGES
- add some warning comment in the "CPP defines" section - current no longer defines "unix" or "__unix__", so the proposed method is no longer reasonable. Someone who knows how to solve this cleanly should redo this section.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.48 1999/01/30 23:21:26 agc Exp $
d1339 1
a1339 1
> @@unexec %D/bin/install-info --delete %D/info/bison.info %D/info/dir
d1346 1
a1346 1
> @@exec %D/bin/install-info %D/info/bison.info %D/info/dir
@


1.48
log
@Change all occurrences of USE_X11 to USE_X11BASE.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.47 1999/01/26 20:03:12 abs Exp $
d189 4
d238 4
d306 2
a307 2
See /usr/pkgsrc/mk/bsd.pkg.mk for a description of all available options
and variables.
d470 1
a470 1
   Display this file (using more(1))  after installing the package.
d504 1
d524 4
d672 5
d1178 1
d1230 1
d1253 1
d1262 1
@


1.47
log
@pkglint is in pkgtools, not devel.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.46 1998/12/19 20:35:47 bad Exp $
d826 1
a826 1
that of $X11BASE if USE_IMAKE, USE_MOTIF, or USE_X11 is set.  The value
d846 1
a846 1
   USE_IMAKE, USE_MOTIF, or USE_X11 in its pkg Makefile, you need to use
d909 1
a909 1
   package installed in $X11BASE but xmkmf not being run, set USE_X11
@


1.46
log
@Document how to import new packages.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.45 1998/11/26 06:37:22 hubertf Exp $
d1333 1
a1333 1
directory "pkgsrc/devel/pkglint") which helps to check the contents of these
@


1.45
log
@Document ${OPSYS}, ${OS_VERSION} in PLIST
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.44 1998/09/23 13:09:33 agc Exp $
d495 19
@


1.44
log
@Add a cdrom-readme target, a clone of the readme target, for ease of use.
The URLs in the generated README.html files can be specified by overriding
the CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR definitions.
Document the targets, and clean up some English, in Packages.txt
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.43 1998/08/24 10:31:00 agc Exp $
d541 6
@


1.43
log
@Modify ldconfig part of PLIST, and libtool explanation, to match reality.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.42 1998/08/21 16:37:57 tsarna Exp $
d84 2
a85 2
   Sometimes, this is referred to by the term "package" too, esp. in the
   context of precompiled packages.
d310 3
a312 2
 - Rewrite any ldconfig commands as "ldconfig || ${TRUE}", as there isn't a
   ldconfig command on all platforms NetBSD runs on (e.g. alpha).
d659 5
a663 4
which can be pretty annoying esp. if you don't have all the machines at
your hand to test things. The "libtool" pkg can help here, as it just
"knows" how to build both static and dynamic libraries from a set our
source files, thus being platform independent. 
d734 4
a737 4
One of the biggest problems with FreeBSD ports is that too many of them
assume they will install into /usr/local, instead of regarding ${PREFX}
properly. To change this, add something like the following into your
package Makefile:
d750 13
a762 4
Side note on manpages in PLIST: we don't regard any .gz suffix there, as
many FreeBSD ports seem to have .gz pages in PLIST even when they install
manpages without compressing them; rather, we add our own .gz suffix there
according to MANZ.
d785 1
a785 1
compiling), and finally the produced binaries etc.  can be put into
d940 23
d1029 1
a1029 1
DIST_NAME field, and add the following to your package's Makefile:
d1055 1
a1055 1
> CONFIGURE_ARGS=         netbsd13
d1058 1
a1058 1
 9.5 Packages not building in their DIST_NAME directory
d1061 1
a1061 1
Your package builds in a different directory from its base DIST_NAME - see
a1298 1
> @@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir
@


1.42
log
@Note HOMEPAGE. Also, change portlint->pkglint (forgot before),
update categories list to match recent additions, and update example
bison packeg to match more closely what's in pkgsrc.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.41 1998/08/12 02:52:35 tv Exp $
d519 8
a526 8
   Two issues here. First, if there's a @@exec command calling ldconfig,
   also add a @@unexec command, so the ld.so cache doesn't grow into
   eternity with libs no longer available (this also makes debugging the
   package itself easier).

   The second issue is that there's no ldconfig command on some of the
   platforms NetBSD runs on, e.g. alpha. For this, change the ldconfig call
   to "ldconfig || /usr/bin/true".
d538 2
a539 2
   the output of "uname -m", but that's no longer supported and will be
   removed soon.
d669 1
a669 4
1. Define LIBTOOL=${PREFIX}/bin/libtool in MAKE_ENV, or define it in a
   patch to the native Makefile.  Make the pkg depend on libtool with:

	BUILD_DEPENDS= ${PREFIX}/bin/libtool:../../devel/libtool
d720 4
a723 3
Put LIBTOOL=${PREFIX}/bin/libtool in CONFIGURE_ENV, and possibly modify the
"configure" script not to check for or configure its own libtool.  See the
libwww pkg, patch-ab, for the quick way to bypass the pkg's own libtool.
@


1.41
log
@Shortly document CROSSBASE.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.40 1998/07/31 15:24:13 tv Exp $
d291 6
a296 4
  archivers  converters emulators  mail       news       shells     www
  audio      databases  games      mbone      plan9      sysutils   x11
  benchmarks devel      graphics   misc       print      templates
  comms      editors    lang       net        security   textproc
d338 3
a340 1

d1176 8
a1225 1
> #
d1228 1
a1228 1
> CATEGORIES=     lang
d1231 2
a1232 1
> BUILD_DEPENDS=  ${PREFIX}/bin/install-info:${PORTSDIR}/devel/gtexinfo
d1235 1
a1235 3
>
> post-install:
>                 @@install-info ${PREFIX}/info/bison.info ${PREFIX}/info/dir
a1251 2
>  
> Alistair Crooks (agc@@netbsd.org)
d1273 2
a1274 2
 11.1.5 Checking a package "portlint"
 ====================================
d1276 2
a1277 2
The NetBSD package system comes with a tool called "portlint" (located in the
directory "pkgsrc/devel/portlint") which helps to check the contents of these
d1279 1
a1279 1
directory of the package you which to examine and execute "portlint":
d1281 1
a1281 1
> tron@@lyssa:/usr/pkgsrc/devel/bison>portlint
d1289 1
a1289 1
Depending on the supplied command line arguments (see "man portlint") more
@


1.40
log
@Document the actual differences between uses of ${PREFIX}, ${LOCALBASE},
and ${X11BASE}.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.39 1998/07/16 06:50:46 hubertf Exp $
d787 5
a791 4
though its value becomes that of $X11BASE if USE_IMAKE, USE_MOTIF, or
USE_X11 is set.  The value ${PREFIX} needs to be put into the various
places in the program's source where paths to these files are encoded; see
sections 4.3 and 6.2 for details on this.
@


1.39
log
@Add notes on libtool, by Todd Vierling <tv@@netbsd.org>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.38 1998/07/13 15:37:12 hubertf Exp $
d785 24
a808 5
The variable PREFIX indicates where all files of the final program shall be
installed. It is usually set to $LOCALBASE (/usr/pkg), its value becomes
that of $X11BASE if either USE_IMAKE or USE_X11 is set. The value ${PREFIX}
needs to be put into the various places in the program's source where paths
to these files are encoded; see sections 4.3 and 6.2 for details on this.
@


1.38
log
@Note tech-pkg@@netbsd.org
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.37 1998/07/03 06:51:37 hubertf Exp $
d647 78
a724 1
 6.2 Gotchas of FreeBSD ports
d752 1
a752 1
 6.3 Feedback to the author
d1346 2
a1347 1
> cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o                                            getopt.o getopt1.o  
@


1.37
log
@Try to mention MACHINE_GNU_ARCH in PLIST
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.36 1998/06/18 15:12:22 agc Exp $
d991 2
a992 2
We've agreed on using tech-userlevel@@netbsd.org for discussing 
package related issues. To subscribe do:
d994 1
a994 1
    echo subscribe tech-userlevel | mail majordomo@@netbsd.org
@


1.36
log
@Update the documentation to reflect the automatic manual page handling
changes.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.35 1998/06/10 09:01:12 agc Exp $
d524 1
a524 1
 * ${MACHINE_ARCH}:
d529 3
a531 1
   what "sysctl -n hw.machine_arch" gives. 
@


1.35
log
@Rework some of the English in this document.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.34 1998/06/05 12:21:36 frueauf Exp $
d302 3
a304 3
 - Update MANx (where x is 1-9, N or L); important for manpages being
   compressed correctly if MANZ is set
 - Do the same for CATx, if the package installs any formatted manpages.
a1123 1
> MAN1=           bison.1
@


1.34
log
@Add chapter 9.13 which explains the new CONFLICTS feature.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.33 1998/06/03 15:06:06 agc Exp $
d31 1
a31 1
retrieval of one-line comments or more verbose descriptions are simple.
d40 7
a46 6
This document is divided into two parts. The first, "User's Guide",
describes how one can get a prepared package going, either by installing a
precompiled binary package, or by building with the NetBSD package system.
The second part, "Package Porter's Guide", explains how to prepare a
package so it can be easily built by other NetBSD users without knowing
about the package's building details.
d58 1
a58 1
   system. Packages are stored under /usr/pkgsrc.
d164 1
a164 1
"Package Porter's Guide".
d213 1
a213 1
/usr/pkg. Should this not conform to your tastes, simply set the PREFIX
d217 8
a224 1
	PREFIX=/usr/local
d228 6
d258 3
a260 3
===============================
Part II: Package Porter's Guide
===============================
d602 1
a602 1
only way to ensure everything is propperly removed. The same care must be
d689 1
a689 1
The basic steps for building a program are always the same. First the
d691 6
a696 6
extracted afterwards. After some patches to compile properly on NetBSD are
applied, the software can be configured, then built (usually by compiling),
and finally the produced binaries etc. can be put into place on the system.
These are exactly the steps performed by the NetBSD package system, which
is implemented as a series of targets in a central Makefile(include) -
/usr/pkgsrc/mk/bsd.pkg.mk.
d736 2
a737 2
   extracted, as they are usually in the for of some compressed archive
   format, most commonly .tar.gz. If not all of the distfiles need to be
d745 5
a749 5
   present in the patches subdirectory of the package are
   applied. Patchfiles ending in .Z or .gz are uncompressed before they are
   applied, files ending in .orig or .rej are ignored. Any special options
   to patch(1) can be handed in PATCH_DIST_ARGS. See section 4.3 for more
   details.
d752 5
a756 4
   Now that the source is in a form that has a chance to compile under
   NetBSD, the program usually must be configured to be built on the local
   system. This procedure is usually automated with some script supplied
   with the program, and it results in generation of header files,
d776 6
a781 6
   If everything is set up for compilation, this target cares to do so by
   invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as the target to
   build. The defaults MAKE_PROGRAM is "gmake" if USE_GMAKE is set, "make"
   otherwise. MAKEFILE is by default set to "Makefile:, and ALL_TARGET
   defaults to "all". Any of these variables can be set to change the
   default build process.
d784 16
a799 9
   After all files are properly digested and compiled, the final step is
   to move them into the place where they can be used from anyone. As in
   the build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with
   the $INSTALL_TARGET instead, the latter defaulting to "install" (plus
   "install.man", if USE_IMAKE is set). 

If any of these targets is invoked with "make XXX" and the preceeding
targets were not performed before, they will be executed prior to the given
target in the order given above.
d807 6
a812 5
   auxiliary targets exist with "pre-" and "post-" prepended to the main
   target's name. These targets are invoked before and after the main
   target is called, giving the possibility to fix anything the
   program's configure script or install target left out.  For any of these
   auxiliary targets, equally named scripts can be placed in the package's
d817 5
a821 4
   Should one of the main targets do the wrong thing and there be no
   variable to fix this, you can redefine it with the do-* target. (Note
   that redefining the target itself instead of the do-* target is a bad
   idea, as the pre-* and post-* targets won't be called anymore, etc.)
d861 1
a861 1
 - Compare pkg/PLIST* against /tmp/x, fix the further one
d892 1
a892 1
look at the packages for plan9/sam, which uses a gzipped shell archive
d950 1
a950 1
e.g. in Amdahl, the machine orpheus.amdahl.com is one of our firewalls, and
@


1.33
log
@Document dependencies, sort PASSIVE_FETCH, and fix some typos.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.32 1998/06/03 11:11:27 agc Exp $
d1026 22
@


1.32
log
@Document pkgsrc/mk/bsd.prefs.mk (in section 9.9, including /etc/mk.conf)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.31 1998/05/25 22:01:57 tron Exp $
d693 1
a693 1
installed. It is usually set to $LOCALBASE (/usr/pkg), it's value becomes
d748 1
a748 1
   If the program's distfile contains it's own configure script, this can
d819 1
a819 1
 - IF you did a CVS import, check it out to apply the following fixes
d846 1
a846 1
 - submit (or commit, IF you have cvs access); see section 10.
d974 52
a1025 1
Add the following to your /etc/mk.conf: FETCH_BEFORE_ARGS= -p
@


1.31
log
@Document "portlint".
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.30 1998/04/20 12:14:22 frueauf Exp $
d312 1
a312 1
	INFO_FILES=	indent
d944 16
a959 11
/etc/mk.conf is that the values of these variables aren't known at the
beginning of the Makefile, and thus can't be used in .if statements. It's
OK to use them like any other variable in expansions ("${VAR}"), but not in
.if-statements, though.

Here's the preferred way to handle things if you want to include variables
in .if statements:

1. in the pkg Makefile, set all the pre-install etc targets.
2. in the pkg Makefile, .include "../../mk/bsd.pkg.mk"
3. Then put all the .if defined(USE_SOCKS), .if defined(USE_IDEA) etc
@


1.30
log
@Add a note about adjusting MAINTAINER to Section 4.1 if adopting FreeBSD ports.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.29 1998/04/20 08:25:46 frueauf Exp $
d1063 21
@


1.29
log
@Document pkg/MESSAGE.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.28 1998/04/17 22:01:01 hubertf Exp $
d318 4
@


1.28
log
@Fix sup-example
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.27 1998/04/17 21:47:26 hubertf Exp $
d437 5
@


1.27
log
@Document getting pkgsrc via sup, minor editing.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.26 1998/04/17 10:13:20 agc Exp $
d176 2
a177 1
directory /usr/pkgsrc does exist. Then, simply start "sup".
@


1.26
log
@Document INFO_FILES and USE_GTEXINFO
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.25 1998/04/16 14:10:53 frueauf Exp $
d173 5
d263 9
a271 8
"../../mk/bsd.pkg.mk" file, which sets all the definitions and actions
necessary for the package to compile and install itself. The mandatory fields
are the DISTNAME which specifies the base name of the distribution file to be
downloaded from the site on the Internet, MASTER_SITES which specifies that
site, CATEGORIES which denotes the categories into which the package falls,
PKGNAME which is the name of the package and the MAINTAINER name. This is
so that anyone who quibbles with the (always completely correct) decisions
taken by the guy who maintains the port can complain vigorously.
@


1.25
log
@Reflect the move/renaming of bsd.pkg.mk, minior typo fix, update section
11.1.4 to match our reality.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.24 1998/03/25 14:19:59 hubertf Exp $
d279 1
a279 1
port from the FreeBSD ports collection:
d300 11
@


1.24
log
@Add FAQ about how to do passive FTP
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.23 1998/03/18 07:10:30 hubertf Exp $
d258 3
a260 3
<bsd.port.mk> file, which sets all the definitions and actions necessary
for the package to compile and install itself. The mandatory fields are the
DISTNAME which specifies the base name of the distribution file to be
d275 1
a275 1
See /usr/share/mk/bsd.port.mk for a description of all available options
d285 1
a285 1
   compressed form by the package; see comment in bsd.port.mk
d537 1
a537 1
/usr/share/mk/bsd.port.mk).
d655 1
a655 1
/usr/share/mk/bsd.port.mk.
d675 1
a675 1
The main targets used during the build process defined in bsd.port.mk are:
d792 1
a792 1
 - IF you dida CVS import, check it out to apply the following fixes
d869 1
a869 1
> CONFIGURE_ARGS=	netbsd13
d926 1
a926 1
2. in the pkg Makefile, .include <bsd.port.mk>
a984 5
> # New ports collection makefile for:    bison
> # Version required:     1.25
> # Date created:         1 October 1997
> # Whom:                 agc@@netbsd.org
> #
d991 2
d996 3
d1000 1
a1000 1
> .include <bsd.port.mk>
d1022 1
d1024 12
@


1.23
log
@There is a mailing list for pkg-related discussion.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.22 1998/03/07 14:18:40 tron Exp $
d937 6
@


1.22
log
@Removed section 9.9 because the work arround doesn't work as expected,
rename section 9.10 to 9.9.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.21 1998/03/05 16:37:14 hubertf Exp $
d928 9
@


1.21
log
@Add note on use of mk.conf variables.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.20 1998/03/05 15:26:03 tron Exp $
d913 2
a914 16
 9.9 Distribution Makefile compresses manual pages automatically
 ===============================================================

Some distribution files used to create our packages come with BSDish
Makefiles that compress manual pages automatically if "MANZ" is defined.
To avoid an error on "make install" because the manual pages can't be
compressed by <bsd.port.mk> add this work arround to the package's Makefile:

# MANZ is handled automatically
.if defined(MANZ)
MANCOMPRESSED=	1
.endif


 9.10 How to pull in variables from /etc/mk.conf
 ===============================================
@


1.20
log
@Document "MANZ" work arround in section 9.9.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.19 1998/02/27 02:46:29 hubertf Exp $
d925 17
@


1.19
log
@Tix stupid typo reported by Johnny C. Lam <lamj@@stat.cmu.edu>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.18 1998/02/08 18:17:33 hubertf Exp $
d911 14
@


1.18
log
@Patch arguments were reversed, reported by
Brad Salai <bsalai@@law.roc.servtech.com>
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.17 1998/02/08 18:15:08 hubertf Exp $
d586 1
a586 1
        #ifdef (defined(__unix__) || defined(unix)) && !defined(USG)
@


1.17
log
@Fix path where packages should end up on the FTP server.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.16 1998/02/02 08:58:13 hubertf Exp $
d800 1
a800 1
   the diff: 'diff -bu foo foo.orig >../../patches/patch-xx' (mv patch-xx
@


1.16
log
@Remove -m argument from ldconfig calls, require the system to
have ${PREFIX}/lib in ld.so.conf instead. This ensures things
even work after a reboot.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.15 1998/02/02 08:10:41 hubertf Exp $
d618 1
a618 1
                ${SED} -e 's:/usr/local:'${PREFIX}':g' < $$f > $$f.pdone && mv $
d1229 1
a1229 1
   ftp://ftp.netbsd.org/pub/NetBSD/packages/`sysctl -n hw.machine_arch`
@


1.15
log
@Introduce TRUE?=/usr/bin/true, and use it.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.14 1998/01/30 13:15:05 hubertf Exp $
d287 2
a288 2
 - Rewrite any ldconfig commands as "ldconfig ... || ${TRUE}", as there
   isn't a ldconfig command on all platforms NetBSD runs on (e.g. alpha).
d392 1
a392 1
 - For @@exec and @@unexec rewrite any ldconfig-command as "ldconfig ... ||
d476 2
a477 1
   eternity with libs no longer available.
d481 1
a481 1
   to "ldconfig ... || /usr/bin/true".
@


1.14
log
@true /> /usr/bin/true
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.13 1998/01/30 13:11:42 hubertf Exp $
d287 2
a288 3
 - Rewrite any ldconfig commands as "ldconfig ... || /usr/bin/true", as
   there isn't a ldconfig command on all platforms NetBSD runs on (e.g.
   alpha).
@


1.13
log
@RCS ID update - sync with portlint for now
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.12 1998/01/29 13:47:35 hubertf Exp $
d287 3
a289 2
 - Rewrite any ldconfig commands as "ldconfig ... || true", as there isn't
   a ldconfig command on all platforms NetBSD runs on (e.g. alpha).
d394 2
a395 2
   true", as there's no ldconfig command on some of the platforms NetBSD
   runs on (e.g. alpha).
d481 1
a481 1
   to "ldconfig ... || true".
@


1.12
log
@Update process for importing a package
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.11 1998/01/28 15:37:19 hubertf Exp $
a951 1
> # <$>NetBSD<$>
d957 1
@


1.11
log
@Replace "<$ARCH"> by "${MACHINE_ARCH}", keep "<$ARCH>"
(in bsd.port.mk) for backward compatibility.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.10 1998/01/19 08:07:16 hubertf Exp $
d789 1
a789 1
   (cd ...pkgsrc/category/pkgname ; cvs import pkgsrc/category/pkgname \
d791 2
@


1.10
log
@Correct some spelling typos, pointed out by
David Brownlee <abs@@netbsd.org>.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.9 1998/01/03 06:18:00 hubertf Exp $
d482 1
a482 1
 * <$ARCH>: 
d486 6
a491 2
   actually used, and the symbol "<$ARCH>" will be replaced by what "uname
   -m" gives. 
@


1.9
log
@Concentrate FreeBSD credits, note what we call a port, some minor fixes.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.8 1998/01/01 05:52:52 hubertf Exp $
d129 1
a129 1
If you have the files on a CDROM or downloaded them to your harddisk, you
d182 1
a182 1
If you don't have a permanent internet connection and you want to know
d268 1
a268 1
one is used, they need to be seperated by spaces:
d354 1
a354 1
replace any occurances of /usr/local in any "Makefile"s in the original
d454 1
a454 1
This section addresses some specialities that one needs to take attention
d458 1
a458 1
 5.1 Miscallaneous
d520 1
a520 1
packges system looks for pkg/PLIST-mi, and pkg/PLIST-md.shared or
d556 1
a556 1
only way to ensure everything's propperly removed. The same care must be
d607 1
a607 1
propperly. To change this, add something like the following into your
d619 1
a619 1
for example. So don't blindly replace all occurences of /usr/local!
d645 1
a645 1
extracted afterwards. After some patches to compile propperly on NetBSD are
d702 2
a703 2
   to patch(1) can be handed in PATCH_DIST_ARGS. See section 4.3 for a more
   detailles.
d729 2
a730 2
   If everything's set up for compilation, this target cares to do so by
   invoking $MAKE_PROGRAMM on $MAKEFILE with $ALL_TARGET as the target to
d737 1
a737 1
   After all files are propperly digested and compiled, the final step is
d769 1
a769 1
   propperly, you can repeat the installation with this target, which will
d783 1
a783 1
 - Import unchanged FreeBSD source (ONLY if you have cvs access, not neeed
d792 1
a792 1
 - If something's not ok, fix; for patches: fix the file, then re-generate
d796 1
a796 1
 - If all builds ok: touch /tmp/bla
d799 1
a799 1
   (or whatever you set LOCALABSE and X11BASE to)
d836 1
a836 1
DIST_NAME field, and add the following wo your package's Makefile:
d922 1
a922 1
   (contents of pkg/COMMENT are ok), plus the URL of your tar-file.
d924 1
a924 1
   You will be notified if your send-pr has been adressed so you can remove
d1071 1
a1071 1
Everything seems ok, so install the files:
d1197 1
a1197 1
Layout for precompiled binary packges on ftp.netbsd.org:
@


1.8
log
@Add pkgsrc in FTP layout
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.7 1997/12/29 19:44:32 hubertf Exp $
d15 1
a15 1
 grep -B1 '^.====' Packages-new.txt | egrep -v '^.[-=]'
d23 12
a34 11
packages collection - which is derived from the FreeBSD ports collection -
incorporates any such changes necessary to make that software run on
NetBSD, and makes the installation (and reinstallation) of the software
package easy by means of a single command.

The NetBSD package system - which is derived from the FreeBSD ports system
- is used to enable such freely available third-party software to be built
easily on NetBSD hosts. Once the software has been built, it is manipulated
with the pkg_* tools so that installation and de-installation, printing of
an inventory of all installed packages and retrieval of one-line comments
or more verbose descriptions are simple.
d73 1
a1196 1
Proposal:
@


1.7
log
@Fix some typos reported by Thorsten Frueauf <frueauf@@ira.uka.de>.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.6 1997/12/27 04:27:10 hubertf Exp $
d1201 1
@


1.6
log
@Rework last commit (.gz in PLIST-manpages)
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.5 1997/12/27 04:13:29 hubertf Exp $
d111 1
a111 1
Precompiled packages are stored on ftp.netbsd.org and it's mirrors in the
d370 1
a370 1
   mention the package's name - this will automatically be added bythe
d376 1
a376 1
   shareyour sense of humour (or spelling idiosyncracies), and that others
d383 1
a383 1
   directories,and the location of inserted files.
d391 1
a391 1
   true", as there's no ldconfig command om some of the platforms NetBSD
d402 1
a402 1
   the files to install are moved in place. This can be used to du any
d615 1
a615 1
This is taken from the sysutils/rtty packagel; be sure this works for your
d753 1
a753 1
   target is called, giving the possibility to do any fix anything the
d1096 1
a1096 1
Now as you don't need the source and object files any more, clean up:
@


1.5
log
@Add note about .gz suffix of manpages in PLIST; requested by
Ty Sarna <tsarna@@endicor.com>.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.4 1997/12/26 03:42:33 hubertf Exp $
d492 2
a493 5
   details. (We don't regard any .gz suffix on manpages set in pkg/PLIST,
   as many FreeBSD ports seem to have .gz pages in PLIST even when they
   install manpages without compressing them; rather, we set it on our
   own here, if needed). This modification of the PLIST file is done on
   a copy of it, not pkg/PLIST itself.
d618 5
@


1.4
log
@Major rewrite
@
text
@d1 1
a1 1
# $NetBSD$
d488 1
a488 1
   Manpages should be installed in compressed for if MANZ is set (in
d492 5
a496 2
   details. This modification of the PLIST file is done on a copy of it,
   not pkg/PLIST itself.
@


1.3
log
@More details on how to fix RCS-Id.
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.2 1997/11/10 00:35:47 hubertf Exp $
d4 4
d9 1
a9 38
		  =======================================
		    An attempt of some documentation on
			 NetBSD's Packages system
		  =======================================

		      Alistair Crooks, Hubert Feyrer


0. Introduction and Overview
============================

There's an awful lot of freely-available software available, some of which
has also been "ported" to NetBSD.  The NetBSD packages collection, which is
derived from the FreeBSD ports collection, incorporates any changes
necessary to make that software run on NetBSD, and makes the installation
of the package easy by means of a single command.  De-installation is
equally simple.

The NetBSD package system is derived from the FreeBSD ports system.  It is
used to enable third-party software to be built easily on NetBSD hosts.
Once the software has been built, it is manipulated with the pkg_* tools so
that installation and de-installation is simple, and inventory printed, and
one-line comments and more verbose descriptions can be retrieved.

This document detailes 4 sections below. They are:

 1. To install packages by building
 2. To make a binary package
 3. To install a binary package
 4. Making your own package

The patient readers are advised to go and read the "guidelines" section of
the FreeBSD handbook
(http://www.freebsd.org/handbook/handbook251.html#porting), which provides
detailed instructions on the construction of a FreeBSD "port".  Impatient
readers are also advised to read that section.  A lot of the information is
this document is taken from that section of the FreeBSD handbook, mostly
without attribution.
d12 146
a157 2
1. To install packages by Building
====================================
d160 6
a165 2
If it is not, then you are advised to read section 4 of this document:
"Making your own package".
d171 17
d189 1
a189 1
directory. You can then type
d198 1
a198 16
place on your system.

There is one gotcha:

The distribution file (i.e. the unmodified source) must exist on your
system for the packages system to be able to build it.  If it's not, then
ftp(1) is used to fetch the distribution files automatically.  If you are
sitting behind a firewall, you must specify the relevant proxy hosts to
enable you to talk to other machines on the Internet which are not behind
your firewall.  This is an environment variable in the form of a URL e.g.
in Amdahl, the machine orpheus.amdahl.com is one of our firewalls, and it
uses port 80 as the proxy port number.  So the proxy environment variables
look like:

	ftp_proxy=ftp://orpheus.amdahl.com:80/
	http_proxy=http://orpheus.amdahl.com:80/
d201 1
a201 70
system by building as shown in the typescript below:

> Script started on Fri Oct  3 13:22:31 1997
> root@@pumpy:/u/pkgsrc/sysutils/top(1342)# make
> >> top-3.5beta5.tar.gz doesn't seem to exist on this system.
> >> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
> Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
> Successfully retrieved file.
> >> Checksum OK for top-3.5beta5.tar.gz.
> ===>  Extracting for top-3.5beta5
> ===>  Patching for top-3.5beta5
> ===>  Applying NetBSD patches for top-3.5beta5
> ===>  Configuring for top-3.5beta5
> /bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
> chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
> 
> Reading configuration from last time...
> 
> Using these settings:
>         Bourne Shell   /bin/sh
>           C compiler   cc
>     Compiler options   -DHAVE_GETOPT -O
>          Awk command   awk
>      Install command   /usr/bin/install
> 
>               Module   netbsd13
>              LoadMax   5.0
>         Default TOPN   -1
>         Nominal TOPN   18
>        Default Delay   2
> Random passwd access   yes
>           Table Size   47
>                Owner   root
>          Group Owner   kmem
>                 Mode   2755
>        bin directory   $(PREFIX)/bin
>        man directory   $(PREFIX)/man/man1
>        man extension   1
>        man style       man
> 
> Building Makefile...
> Building top.local.h...
> Building top.1...
> Doing a "make clean".
> rm -f *.o top core core.* sigdesc.h
> To create the executable, type "make".
> To install the executable, type "make install".
> ===>  Building for top-3.5beta5
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c top.c
> awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c commands.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c display.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c screen.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c username.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c utils.c
> utils.c: In function `errmsg':
> utils.c:348: warning: return discards `const' from pointer target type
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c version.c
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c getopt.c
> cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
> rm -f top
> cc -o top top.o commands.o display.o screen.o username.o  utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
> root@@pumpy:/u/pkgsrc/sysutils/top(1343)# make install
> >> Checksum OK for top-3.5beta5.tar.gz.
> ===>  Installing for top-3.5beta5
> /usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
> /usr/bin/install top.1 /usr/pkg/man/man1/top.1
> strip /usr/pkg/bin/top
> ===>  Registering installation for top-3.5beta5
> root@@pumpy:/u/pkgsrc/sysutils/top(1344)# 
d203 4
a206 4
As you can see, the package is installed under the default root of the
packages tree - /usr/pkg. Should this not conform to your tastes, simply
set the PREFIX variable in your environment, and it will use that value as
the root of your packages tree. So, to use /usr/local, set
d213 2
a214 2
2. To make a binary package
===========================
d216 6
a221 6
Once you have built and installed the package mentioned in section 1 above,
you can build it into a "binary package" - you might want to do this so
that you can use the binaries you have just built on another NetBSD system,
or to provide a simple means for others to use your binary package - this
is done by changing to the appropriate directory in the pkgsrc tree, and
typing the command
d225 6
a230 4
at the shell prompt.  This will build and install your package, and then
construct a binary package out of the results so that you can use the pkg_*
tools to manipulate this. At the present time, this binary package is in
the form of a gzipped tar file.
d232 2
a233 7
> root@@pumpy:/u/pkgsrc/sysutils/top(1344)# make package
> >> Checksum OK for top-3.5beta5.tar.gz.
> ===>  Building package for top-3.5beta5
> Creating package top-3.5beta5.tgz
> Registering depends:.
> Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'
> root@@pumpy:/u/pkgsrc/sysutils/top(1345)#
d236 3
a238 2
3. Installing a binary package
==============================
d240 2
a241 63
To install a binary package on a NetBSD system, you should use the
pkg_add(1) command.  Please pay very careful attention to the warnings
expressed in that manual page about the inherent dangers of installing
binary packages which you did not create yourself, and the security holes
that can be introduced onto your system by indiscriminate adding of such
files.

Any packages needed to run the package in question will be installed too,
assuming they are present on your system.


4. Making your own package
==========================

This section should also be known as "How to make files for a pkgsrc
directory."


4.1 Category

Firstly, you should consider into which category your software falls.  The
NetBSD package collection is divided into categories.  At the time of
writing, these categories are:

  archivers
  astro
  audio
  benchmarks
  cad
  chinese
  comms
  converters
  databases
  devel
  editors
  emulators
  games
  german
  graphics
  japanese
  korean
  lang
  mail
  math
  mbone
  misc
  net
  news
  plan9
  print
  russian
  security
  shells
  sysutils
  textproc
  vietnamese
  www
  x11

It is possible that your package may fall into more than one category - in
that case, you should pick the one most likely to describe your software.
After all, that is the place that most people will look for it, and so you
have more chance of other people using it if you describe it properly.
d243 4
a247 1
4.2 A package's directory and its component directories and files
d249 2
a250 1
4.2.1 Makefile
d252 2
a253 2
The building, installation, and creation of a binary package are all
controlled by the package's Makefile.
d255 1
a255 1
There's a Makefile for each package.  This file includes the standard
d258 33
a290 8
DISTNAME, which specifies the base name of the distribution file which will
be downloaded from the site on the Internet, MASTER_SITES which specifies
that site, CATEGORIES which denotes the categories into which the package
falls, PKGNAME which is the name of the package, and the MAINTAINER name.
This is so that anyone who quibbles with the (always completely correct)
decisions taken by the guy who maintains the port can complain vigorously.
(Actually, in my experience, the FreeBSD maintainers have all been very
responsive.)
d292 2
a293 1
See /usr/share/mk/bsd.port.mk for a description of all available options.
d295 3
a298 1
4.2.2 The files directory
d300 2
a301 5
If you have any files that you wish to be placed in the package prior to
configuration or building, you could place these files here, and use a cp
command in the pre-configure target to achieve this.  Alternatively, you
could simply diff the file against /dev/null, and use the patch mechanism
to manage the creation of this file.
d303 14
a316 2
Besides that, this directory contains the (mandatory) md5 checksome of all
the distfiles need for the package to compile.
d319 2
a320 1
4.2.2.1 The files/md5 file
d322 5
a326 5
This file contains an md5 checksum of the distribution file(s) to ensure
that the file retrieved from the Internet has not been altered by a malign
force to introduce a security hole.  The file contains the md5 checksum of
the original distribution file used to create the NetBSD package, from
which any patches were generated etc.
d328 12
a339 2
It can be generated by hand using the md5(1) command or by invoking "make
makesum".
d341 5
d347 1
a347 1
4.2.3 The patches directory
d349 1
a349 5
This directory contains files that are used by the patch(1) command to
modify the sources as distributed in the distribution file, into a form
that will compile and run perfectly on NetBSD.  The files are applied
successively, in alphabetic order (as returned by a shell "patches/patch-*"
glob expansion), so patch-aa is applied before patch-ab etc.
d351 3
a353 4
The patch-?? files should be in diff -u format.  This is because the
FreeBSD ports tsar finds this format easier to read than context diffs, and
so you have more chance of getting your NetBSD package accepted as part of
the FreeBSD ports system if you format your diffs in a unified fashion.
d356 2
a357 1
4.2.4 The pkg directory
d359 2
a360 2
This directory contains three files used to manage the creation of binary
packages.  Files from this directory are used in the binary package itself,
d365 2
d368 16
a383 1
4.2.4.1 The pkg/COMMENT file
d385 2
a386 3
A one-line description of the piece of software. There is no need to
mention the package's name - this will automatically be added by the pkg_*
tools when they are invoked.
d388 6
a394 1
4.2.4.2 The pkg/DESCR file
d396 2
a397 4
A multi-line description of the piece of software.  This should include any
credits where they are due.  Please bear in mind that others do not share
your sense of humour (or spelling idiosyncracies), and that others will
read everything that you write here.
d399 18
a417 1
4.2.4.3 The pkg/PLIST file
d419 2
a420 4
This file governs the files that are installed on your system: all the
binaries, manual pages, etc. There are other directives which may be
entered in this file, to control the creation and deletion of directories,
and the location of inserted files.
d422 3
d426 7
a432 1
4.2.5 The scripts directory
d434 1
a434 2
This directory contains any files that are necessary for configuration of
your software, etc.
d437 2
a438 1
4.2.6 The work directory
d445 82
a526 1
at the shell prompt.
d528 3
d532 31
a562 1
4.3 CPP definitions
d570 3
a572 4
__FreeBSD__.  I believe that this should be used sparingly, for
FreeBSD-specific features, but unfortunately this is not always the case.
A number also rely on the fact that the CPU type is an Intel-based
little-endian CPU.
d577 1
a577 1
without checking whether it's available -
d594 2
a595 2
FreeBSD port, if only from an aesthetic viewpoint (see section 4.4, FreeBSD
ports).
d597 2
d600 2
a601 1
4.4 FreeBSD ports
d603 170
a772 6
It's quite possible that a FreeBSD port exists for the piece of software
you're trying to build on NetBSD.  If that is the case, it's very possible
that the FreeBSD port will work on NetBSD.  However, check that the person
who ported the software to FreeBSD has not played fast and loose with the
__FreeBSD__ cpp definition without good cause - a simple way to do this is
to do
d774 32
a805 1
	grep -i freebsd patches/patch-??
a806 1
in the package directory.
d808 2
d811 2
a812 1
4.5 Idiosyncracies
d814 2
a815 1
4.5.1 If your package uses GNU autoconf
d823 2
a824 4
4.5.2 If your package uses imake or xmkmf

> USE_IMAKE= yes

d826 2
a827 6
4.5.3 You don't have to have a patches directory if you don't have any
patches, but it won't hurt you either.


4.5.4 If your package uses a different distribution method from .tar.gz:
take a look at the packages for sam, which uses a gzipped shell archive
d829 1
a829 1
DIST_NAME field, and
d837 6
a842 3
4.5.5 Your package doesn't create a subdirectory for itself (like GNU
software does, for instance), but extracts itself in the current directory:
see sam again, but the quick answer is:
d847 5
a851 2
4.5.6 Your package uses a weird Configure script: See the top package, but
the quick answer is
d858 11
a868 2
4.5.7 Your package has an HTTP URL: No problem, see the libutf and mysql
packages, just use the http URL and ftp(1) will handle it.
d870 21
a890 5
> MASTER_SITES=   http://www.tcx.se/ \
>                 http://www.buoy.com/mysql/ \
>                 http://web.tryc.on.ca/mysql/ \
>                 http://mysql.staufen.de/ \
>                 http://mysql.acer.net/
d893 2
a894 2
4.5.8 Your package builds in a different directory from its base DIST_NAME:
see tcl and tk packages:
d896 5
a900 1
> WRKSRC=         ${WRKDIR}/${DISTNAME}/unix
d902 5
d908 8
a915 5
4.5.9 Your package needs to specify a different PREFIX: This can be fraught
with danger if you're using GNU configure, as (see 4.5.1)
--prefix=${PREFIX} is automatically appended to CONFIGURE_ARGS.  SO take a
look at mit-pthreads, omit GNU_CONFIGURE=yes, use HAS_CONFIGURE=yes, and
manually add the modified PREFIX to CONFIGURE_ARGS yourself:
d917 2
a918 2
> HAS_CONFIGURE= yes
> CONFIGURE_ARGS += ${PREFIX}/dirname
d921 2
a922 1
4.6 A worked example
d925 1
a925 1
collection, and picked GNU bison.  Quite why someone would want to have
d929 11
a939 5
> root@@pumpy:/u/pkgsrc/lang(1765)# cd /usr/pkgsrc/lang
> root@@pumpy:/u/pkgsrc/lang(1765)# mkdir bison
> root@@pumpy:/u/pkgsrc/lang(1766)# cd bison
> root@@pumpy:/u/pkgsrc/lang/bison(1767)# cat > Makefile << EOF
> # <NetBSD RCS Id>
d955 32
a986 1
> EOF
d988 4
d1005 7
a1011 15
> root@@pumpy:/u/pkgsrc/lang/bison(1770)# md5 /usr/pkgsrc/distfiles/bison-1.25.tar.gz | sed -e 's;/usr/pkgsrc/distfiles/;;' > files/md5
> root@@pumpy:/u/pkgsrc/lang/bison(1771)# cat > pkg/COMMENT << EOF
> GNU yacc clone.
> EOF
> root@@pumpy:/u/pkgsrc/lang/bison(1772)# cat > pkg/DESCR << EOF
> GNU version of yacc.  Can make re-entrant parsers, and numerous other
> improvements.  Why you would want this when Berkeley yacc(1) is part
> of the NetBSD source tree is beyond me.
>  
> Alistair Crooks (agc@@netbsd.org)
>  
> EOF
> root@@pumpy:/u/pkgsrc/lang/bison(1773)# cat > pkg/PLIST << EOF
> bin/bison
> EOF
d1063 3
d1079 5
d1090 3
a1094 1
> root@@pumpy:/u/pkgsrc/lang/bison(1788)# 
a1095 3
Finally, please tar up and gzip the package directory (without the binary
package) and mail it to me (agc@@netbsd.org), remembering to uuencode it
first.
d1097 3
d1101 2
a1102 1
4.7 Do-it-yourself - Gotchas
d1104 68
a1171 3
Whenever you're preparing a port from the FreeBSD collection or doing it
from scratch, there's a number of points to take care for in order to get
everything done propperly. Here is an attempt of list of all these gotchas.
d1174 2
a1175 1
4.7.1 Makefile
d1177 7
a1183 5
 - Add MANCOMPRESSED (if not already there), see comment in bsd.port.mk
 - Update MAN?; important for manpages being compressed correctly if MANZ
   is set
 - Replace /usr/local by ${PREFIX} in all Files but Makefiles (see patches
   below) 
d1186 31
a1216 1
4.7.2 pkg/PLIST
d1218 1
a1218 54
 - If there's a "@@exec ldconfig ...", add an "@@unexec ldconfig ...", so the
   hints-file for ld.so doesn't grow without end.
 - Add any missing @@dirrm statements


4.7.3 Debugging

To check out all these gotchas, here are the steps that I do in order to
get a package working (Please note this is basically the same as above,
only with some debugging aids ;):

 - Retrieve port from FreeBSD collection
 - Fix RCS-Id: remove the '$'s around the FreeBSD RCS Id, and insert the
   word FreeBSD, then add a $NetBSD$ before the "FreeBSD Id ..." string

   I.e.
   before:
	# $Id: Makefile,v 1.17 1997/06/16 06:39:51 max Exp $

   after:
	# $NetBSD$
	# FreeBSD Id: Makefile,v 1.17 1997/06/16 06:39:51 max Exp

 - Import unchanged FreeBSD source (ONLY if you have cvs access, not neeed
   otherwise):
   (cd ...pkgsrc/category/pkgname ; cvs import pkgsrc/category/pkgname \
	FREEBSD FreeBSD-current-yyyy-mm-dd)
 - remove tree && checkout new one (again, ONLY needed if you have cvs
   access)
 - Look at Makefile, fix if necessary
 - Look at patches, remember if not appropriate
 - have a look at pkg/PLIST, add a "@@comment $NetBSD$" line at the beginning
   of PLIST
 - make
 - If something's not ok, fix; for patches: fix the file, then re-generate
   the diff: 'diff foo foo.orig >../../patches/patch-xx' (mv patch-xx
   patch-xx.orig before); If there's no foo.orig from a previous patch, be
   sure to have an old version of the file somewhere; re-iterate :)
 - If all builds ok: touch /tmp/bla
 - make install
 - find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla >/tmp/x
 - pkg_delete blub
 - find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla: if this brings up any files,
   they are missing pkg/PLIST; add them.
 - Compare pkg/PLIST against /tmp/x, fix the further one
   ( sort /tmp/x >/tmp/x2 ; sort pkg/PLIST >/tmp/P ; sdiff /tmp/x2 /tmp/P )
 - make reinstall && make package
 - pkg_delete blub
 - find /usr/pkg/ /usr/X11R6/ -type f -newer /tmp/bla shouldn't find anything
   now
 - pkg_add .../blub.tgz
 - Play with it :)
 - pkg_delete - still no file should be left (re-run above find)
 - submit (or commit, IF you have cvs access :)
d1223 3
a1225 2
# mode:		Text
# fill-column:	75
@


1.2
log
@ - note "maek makesum"
 - note where to get pkgsrc
 - some other minor cleanups and reformatting
@
text
@d1 1
a1 1
# $NetBSD: Packages.txt,v 1.1 1997/11/05 09:35:52 hubertf Exp $
d654 18
d674 2
a675 1
 - have a look at pkg/PLIST
d696 1
a696 1
 - submit :)
@


1.1
log
@some documentation
@
text
@d1 3
a3 1
# $NetBSD$
d7 2
a8 2
		       the NetBSD's Packages system
                  =======================================
a10 1
		       Tue Nov  4 11:20:56 GMT 1997
d16 12
a27 13
There's an awful lot of freely-available software available, some of
which has also been "ported" to NetBSD.  The NetBSD packages
collection, which is derived from the FreeBSD ports collection,
incorporates any changes necessary to make that software run on
NetBSD, and makes the installation of the package easy by means of a
single command.  De-installation is equally simple.

The NetBSD package system is derived from the FreeBSD ports system. 
It is used to enable third-party software to be built easily on NetBSD
hosts.  Once the software has been built, it is manipulated with the
pkg_* tools so that installation and de-installation is simple, and
inventory printed, and one-line comments and more verbose descriptions
can be retrieved.
d29 1
a29 1
this document detailes 4 sections below. They are:
d48 7
a54 3
This assumes that the package is already part of the NetBSD package
system.  If it is not, then you are advised to read section 4 of this
document:  "Making your own package".
d56 2
a57 2
Firstly, become root and change into the relevant directory. You can then
type
d83 2
a84 2
Taking the top system utility as an example, we can install it on
our system by building as shown in the typescript below:
d155 4
a158 4
As you can see, the package is installed under the default root of
the packages tree - /usr/pkg. Should this not conform to your tastes,
simply set the PREFIX variable in your environment, and it will use that
value as the root of your packages tree. So, to use /usr/local, set
d168 6
a173 6
Once you have built and installed the package mentioned in section 1
above, you can build it into a "binary package" - you might want to do
this so that you can use the binaries you have just built on another
NetBSD system, or to provide a simple means for others to use your
binary package - this is done by changing to the appropriate directory
in the pkgsrc tree, and typing the command
d177 4
a180 4
at the shell prompt.  This will build and install your package, and
then construct a binary package out of the results so that you can use
the pkg_* tools to manipulate this. At the present time, this binary
package is in the form of a gzipped tar file.
d197 3
a199 3
binary packages which you did not create yourself, and the security
holes that can be introduced onto your system by indiscriminate adding
of such files.
d214 3
a216 3
Firstly, you should consider into which category your software falls. 
The NetBSD package collection is divided into categories.  At the time
of writing, these categories are:
d253 4
a256 5
It is possible that your package may fall into more than one category
- in that case, you should pick the one most likely to describe your
software.  After all, that is the place that most people will look for
it, and so you have more chance of other people using it if you
describe it properly.
d278 1
a278 1
See /usr/share/mk/bsd.port.mk for a description of all available options. 
d290 1
a290 1
the distfiles need for the package to compile. 
d295 5
a299 10
This file contains an md5 checksum of the distribution file(s).  It can be
generated by hand using the md5(1) command.  An md5 checksum is kept on
most ports to ensure that the file retrieved from the Internet has not been
altered by a malign force to introduce a security hole.  The file contains
the md5 checksum of the original distribution file used to create the
NetBSD package, from which any patches were generated etc.

(I usually create this by doing

	md5 <dist-file> > files/md5
d301 2
a302 2
and then manually editing the name of the file to delete any directory
names)
d321 5
a325 5
This directory contains three files used to manage the creation of
binary packages.  Files from this directory are used in the binary
package itself, and will thus be installed on other machines, so you
should be aware that there is a wider audience than you might think
for your comments and witticisms.
d330 3
a332 3
A one-line description of the piece of software. There is no need
to mention the package's name - this will automatically be added by
the pkg_* tools when they are invoked.
d337 4
a340 4
A multi-line description of the piece of software.  This should
include any credits where they are due.  Please bear in mind that
others do not share your sense of humour (or spelling idiosyncracies),
and that others will read everything that you write here.
d348 1
a348 1
and the location of inserted files.  
d353 2
a354 2
This directory contains any files that are necessary for configuration
of your software, etc.
d369 15
a383 15
To port an application to NetBSD, it's usually necessary for the
compiler to be able to judge the system on which it's compiling,
and we use definitions so that the C pre-processor can do this.

The really impatient should just note that a number of the FreeBSD
ports (which are called packages in the NetBSD world) rely on the CPP
definition __FreeBSD__.  I believe that this should be used sparingly,
for FreeBSD-specific features, but unfortunately this is not always
the case.  A number also rely on the fact that the CPU type is an
Intel-based little-endian CPU.

To test whether you are working on a 4.4 BSD-derived system, you
should use the BSD definition, which is defined in <sys/param.h> on
said systems.  Unfortunately, it may not always be appropriate to
include that header file without checking whether it's available -
d389 2
a390 2
and then you can surround the BSD-specific parts of your port using
the conditional:
d396 2
a397 3
Please use the __NetBSD__ definition sparingly - it should only apply
to features of NetBSD that are not present in other 4.4-lite derived
BSDs.
d400 2
a401 2
FreeBSD port, if only from an aesthetic viewpoint (see section 4.4,
FreeBSD ports).
d406 6
a411 6
It's quite possible that a FreeBSD port exists for the piece of
software you're trying to build on NetBSD.  If that is the case, it's
very possible that the FreeBSD port will work on NetBSD.  However,
check that the person who ported the software to FreeBSD has not
played fast and loose with the __FreeBSD__ cpp definition without good
cause - a simple way to do this is to do
d424 2
a425 2
Note that this appends --prefix=${PREFIX} to CONFIGURE_ARGS, so you
don't have to do that yourself, and this may not be what you want.
d437 5
a441 4
4.5.4 If your package uses a different distribution method from
.tar.gz:  take a look at the packages for sam, which uses a gzipped
shell archive (shar), but the quick solution is to set EXTRACT_SUFX to
the name after the DIST_NAME field, and
d451 1
d455 3
a457 2
4.5.6 Your package uses a weird Configure script:
See the top package, but the quick answer is
d463 3
a465 3
4.5.7 Your package has an HTTP URL:
No problem, see the libutf and mysql packages, just use the http URL
and ftp(1) will handle it.
d475 1
d484 1
d492 3
a494 3
collection, and picked GNU bison.  Quite why someone would want to
have bison when Berkeley yacc is already present in the tree is beyond
me, but it's useful for the purposes of this exercise.
d620 3
a622 3
Finally, please tar up and gzip the package directory (without the
binary package) and mail it to me (agc@@netbsd.org), remembering to
uuencode it first.
d625 1
a625 1
4.7 Gotchas
d629 2
a630 2
everything done propperly. Here is an attempt of list of all these
gotchas. 
d640 1
d647 1
d669 1
d679 6
@

.