From nobody Thu Sep 12 22:52:58 2024 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X4Xlk6DRQz5X2MJ for ; Thu, 12 Sep 2024 22:53:06 +0000 (UTC) (envelope-from mirror176@hotmail.com) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11olkn2041.outbound.protection.outlook.com [40.92.19.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X4Xlk0TGTz4MK2 for ; Thu, 12 Sep 2024 22:53:06 +0000 (UTC) (envelope-from mirror176@hotmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hotmail.com header.s=selector1 header.b=XDVxohdx; dmarc=pass (policy=none) header.from=hotmail.com; spf=pass (mx1.freebsd.org: domain of mirror176@hotmail.com designates 40.92.19.41 as permitted sender) smtp.mailfrom=mirror176@hotmail.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Pz3pork2p2Yi0QqYBDyfVMqjrxajNdkEjx/cOc6T1CoYRMQF9QPsWGjqS1mu36hFVPo/cvv6DwOdOC2mK+7FxJhYVh3aHkJJg8CQQbkKsimfsMU0PlWLGhdyhJSS3wkq8coPKvNElaQ4NSLHtjxNUeHvRmtDqPq/ZZuHrgMR+p1p0Usg7UUgd1athbSXTzHtaRzSQLnmYo2+adwAOw/goRDxllAghCNi6ckH4r2rNTdIVkWGuTnC9dMqE2MVSIBzca5oC/9yVddbQO7CS8LNv5x8NYyMNl2sJ/Q3Nj0GWw41LLBVpZTyJD9aGHIhmyTIL87d8EejV2YDrh/JtEQFug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+HMiRWC30t+RZMD1ls1XLpu8YG0uUC89KDdBr5YyzQ4=; b=a3pR6cNrnooX6s3KvxrqxhSlj6+tD5nEZl9+31bTizUElxbcoLC+kCXlLd9xHnreGK0ZJtrGWwcO7fMITlNnNp9DG9M+Z104uihOHqvJ9H89h/ozu6+yowlykUWuoq9RMasgcolYyMVb4KWv+9QdPgkWkO7elUWq4SWatdNcNtOI7cqrTbVD3zyz3PBrSV//pji2tEC7W1xbIcawmuCEown5Gt49NgUJpQwwCvQY/s+Xoaz8W5uRBUHgj1M2J1zr5eV47AIGvV6oeXxPq4YyFCV8t3HSJPmM7Z9RTV9Ph8MxhbaGZ2BPp1jrCrRtHUC6M8a42Uyhgf9sEbsMIcB+HA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+HMiRWC30t+RZMD1ls1XLpu8YG0uUC89KDdBr5YyzQ4=; b=XDVxohdxWFh0a9neuAXt5vaSTL+Wm4iaAotKk7T7alUFte3unVgnoiDcZ8+fg26r/Rp8GsyKC2raWa77jKOvIhBP2giRrMtSfQ3tLxgo6kRGikTcxyKE4ImQmpZvsBrS+rH+zUSSu6uYJw97BIoD+i3G/7zPfXIrTUJ13FaKVMT996jiY5n9SE0BkHbRP/RnED0moFCwsJ09R2p7iFRUTHqeljzxdGTiukC0CO+JfDD4rF/leinjVI2R2U7vDA7QRnUVnuxvG6heCgCDu+YM2yhhw8PpCuL3y/u4dx5rBRJkNVhVKtO5v4M5K8smSOOSHkbY1s4xaRL6pZ09YH3Rcw== Received: from CO1PR11MB4770.namprd11.prod.outlook.com (2603:10b6:303:94::19) by MN0PR11MB6301.namprd11.prod.outlook.com (2603:10b6:208:3c3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7939.24; Thu, 12 Sep 2024 22:53:02 +0000 Received: from CO1PR11MB4770.namprd11.prod.outlook.com ([fe80::bffd:9e35:4afa:a747]) by CO1PR11MB4770.namprd11.prod.outlook.com ([fe80::bffd:9e35:4afa:a747%5]) with mapi id 15.20.7962.017; Thu, 12 Sep 2024 22:53:02 +0000 Message-ID: Date: Thu, 12 Sep 2024 15:52:58 -0700 User-Agent: Mozilla Thunderbird Subject: Re: port installation basics To: questions@freebsd.org References: <1UDlGbz6DvIgGns6@aceecat.org> Content-Language: en-US From: "Edward Sanford Sutton, III" In-Reply-To: <1UDlGbz6DvIgGns6@aceecat.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MN0PR03CA0029.namprd03.prod.outlook.com (2603:10b6:208:52f::34) To CO1PR11MB4770.namprd11.prod.outlook.com (2603:10b6:303:94::19) X-Microsoft-Original-Message-ID: <3f226c03-b9e8-4222-b668-f9f034cd6a14@hotmail.com> List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR11MB4770:EE_|MN0PR11MB6301:EE_ X-MS-Office365-Filtering-Correlation-Id: c52ea057-4b25-45c9-61e6-08dcd37da75a X-Microsoft-Antispam: BCL:0;ARA:14566002|19110799003|6090799003|461199028|5072599009|15080799006|8060799006|7092599003|3412199025|4302099013|440099028|56899033|1602099012; X-Microsoft-Antispam-Message-Info: apeZGNbVIBLGO6dXD/lcYrfvzBLk/D1GsajSj8XraVlRAYdlAwhfco4EmQhHfmFAooa4F3VRkhE/tEYHMLIkKsgFdcqVgEllsfnoougQnu5MuXIMUFhVdSlt2JymfuUuNiB3FKMxKBhuRgUkXxLS1hggvhpqyGX/dLXgJFotFX0NLTIBPx5isItjrypOt/l2lrYtEGOsDtkF0lCCgE4yM6luohk/e0BiEnVxSG3/65yZnTE9DkarEG/YW7MTWEkcvKgL+vfhtA1CbEvMSUNSqALZf1hgmm2Yk4bMUQgod02K56ibnT6EFuyiqTa1UFH9xJJWNVf1maOUCcsuEQ/JrgZ0iocDL1eVMjUI1gciKcfKfNARYS7aEQHJ/rnxmoVBS7Sw7qgVE3fmDaOKaCCGgqjSogzpTt+r1q94Rh2BxfarZZ282o+uqkP/tXfS67i41Opm7WBxy4zm4MxhxSDqu6POijhBX1uae4MDfQcx9iVyIitA0Q8Vwmr3xW6QoIpiov8HWT0BdXpQZtHoHI0z5mJdMQHxZl3pIGayBc7ZfodWX8OQTS7qVbYRzcFLVu0fwZJl3isPtdt/lEZigBQhc4vLAcYKt4fSCASdpPRpC8cQZVyQTVCqlQLJpeylsrc1m89FDUq5t1I2t4kNN9CQjV83ED2oWSOZ9JmrPB/7XGGN1iJmKOZSCjbZ7Zv1GXh3RXopcBfHoSR5nIBmmG4a3H95yRUwWrUKsTXse/VuoK4y4940TdiJK6fe9zF11RYDe8dcCapcSkeBrt9Hx+EF9iA/L9j56dWU9bDgJJuUChtJ5XQqlQY43n57apnGFg02AUiPH6VbW8s4cncEjmDLA+1CFEAPiKGnGntcfoqPi1pwMKuUJ81mH8AGPk5iGZd+a3IyPjO9u58OIMN0szBboxlrmq6rqw4fkTZ4GUMT1Bc= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R1ViTStONVpjanlPM1NxcWRvdUE2UUlEWm54ODVaVkl4VVAvT1JsVUk3QWMw?= =?utf-8?B?akJ1L0JqNmRsOGZiWEo1emdWd29sMHNERnpJYUVSZlQ1M2V5ZDh2NTZudVBx?= =?utf-8?B?bC8yMzdqQnljS0w4V3dQckRmVGgvOU1VNW5SODlOUWNod3ZrYXZxaG82SlNu?= =?utf-8?B?ZHFPeFNIT0FycFRDMmJwTENtaG1yVFhMWE1OWVREZjViZmpSR2VuTjNnNm04?= =?utf-8?B?OG9jWXpHSGFqbHRjejg2WC93dDF4L2M2YUtEenQrRndyN29qL0IrUURsVU9m?= =?utf-8?B?Zkd2UXU4QkhUZWZyTnVPc1BBbWVuYXpIL2lSYTVFbTA1VGk0eFQvYmdpMzdK?= =?utf-8?B?emJacTcvSzJVVHJGTGUzelJSM2ZTeGh5WTVzODJTTVBEQXloS0NqRzdIbXRt?= =?utf-8?B?OVZ1eC9HTklnUERWZk5wSFhveFh6cUxmOWYxSGZ3aGUwVGtFK0VKU21nUlp0?= =?utf-8?B?aUtlV0ZyblhuV0FuTG5uVllrcElYSlU1eEhPbWl4eWlyVTJ2bzJucWgremZG?= =?utf-8?B?a1RPRXBpS0Y3dExtb0I5bzJPaXNXNGw1dFVRVDk4WUNXNnZiYXpodXhkd0NW?= =?utf-8?B?MVFVNkR6b0JJaThIM0F6ZklIQlpOOURLMWlCQ1U4L0lkcW1PczZydW9Xc3VP?= =?utf-8?B?TVo1L3BIVmdGT2RiZWN3S3ZVMFcxSzlhVFlJMEtaUjFTSXhWekxCcGZ5VkUy?= =?utf-8?B?c3J2WkNvZkJINHgya2ZhQkZZeUV5VzBsYkJ4VFh0cWU3UklwWUhtaml0Wk0y?= =?utf-8?B?Z2FiYTVxOXFqUW9uVHpzWVhOSnhGY3hqaW9WTWIyUkRjSlFNY3NiZHROdDI5?= =?utf-8?B?TERDbjcrRVFvWW1kNXBvMWxrb3hVWGl6WWdXSlVmQmlqNnY5U2Z5NDJOdE5F?= =?utf-8?B?RjJ6NXdmM0N1eCs5ZUVndTh2K1luZnFhcnUyZ09NZkV4bEpRd016UEdQWnFO?= =?utf-8?B?TndNRU82NFY0Z3c1am05NG1oTWRnZTdJV0c2T09IK3cvUFhnbzd1bEtQQmdr?= =?utf-8?B?YlhkQkZ2a2FnYTRYOGRJM01GcmFDbUFSZ2pVeUF4NDNWcXpPTm1oSHh5YTVp?= =?utf-8?B?RFdSVW9xQW1DckNJakFFZTZSNmtyd3pPT2ZWd0FpcWloWnhnRzJDQ2d5bTRI?= =?utf-8?B?NWdyT2VJRm1TWGlEOVhSMDZXdm95b1BPVDNXaWoyOXNQOGExZ2pOTUdVMjUv?= =?utf-8?B?Q2xra055WXRFeVlsK3M4d1lMWTM5ZEJjTUkwUEZYQTBlc3JiaTZ4V1dlYXRw?= =?utf-8?B?K29xYUlFaGlTVU80UXBudTdlYkM1UE8zR2JrVGVpbldVRURqRzJtVHc4WFly?= =?utf-8?B?Sjl3SUJzZFcxcGdwS2VudEpWTklGdUNQMnkxWVVWcy9tTWVLVlhnT2s3WjB0?= =?utf-8?B?ZWcrMWxCU2ZnQWl5YmY4N2Jmd0l1eW5ZdkNPYnU5cUY1a05Va2NnWXNwY29Y?= =?utf-8?B?MGFCeXpyNFVaK0Q1U05CRXJFQ2lQeG8ySzFINjZIUWZwK2k3QnNWN2VSMjh5?= =?utf-8?B?MGJKSUlUMmtKaVNLOXdpci9TamprcmRuRDFyODBqYU13NmlIaFowZFdSTDNE?= =?utf-8?B?WXpWQ0lhMEJBenFoOXVZa0x2eUxqOFJ6N3ZqVnR0bHUyeVAvdWZuK0k4QW1y?= =?utf-8?Q?nvi69QNXazDa8eK2SRlghJ1dCStD4YJ5LyQVlg7zdeNo=3D?= X-OriginatorOrg: sct-15-20-7719-20-msonline-outlook-d1079.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: c52ea057-4b25-45c9-61e6-08dcd37da75a X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4770.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2024 22:53:01.5924 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6301 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.48 / 15.00]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector10001:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/16]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[hotmail.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[hotmail.com:+]; TO_DN_NONE(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.19.41:from]; MLMMJ_DEST(0.00)[questions@freebsd.org]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; RCVD_IN_DNSWL_NONE(0.00)[40.92.19.41:from] X-Rspamd-Queue-Id: 4X4Xlk0TGTz4MK2 On 9/12/24 13:30, fatty.merchandise677@aceecat.org wrote: > On Thu, Sep 12, 2024 at 12:41:02PM GMT, Edward Sanford Sutton, III wrote: > >>> I am torn between packages and ports. I read discouraging things >>> about using both, and yet I seem to need both for the following >>> reasons: > >> Using both has problems if you change an option which changes what >> is available from a dependency; if you change something in a custom >> built dependency then you "may" need to custom build what depends on >> it too. Making other changes like switching compilers completely >> might create problematic scenarios too requiring what depends on it >> to be built manually. Another issue can arise when you build ports >> from a tree that is a different git checkout from the one used in >> official packages. Even more confusing to think about when realizing >> that not every package is rebuilt with every update; different >> packages therefore don't always come from the same tree state even >> on the official repo. > > Another thing I seem to remember from my previous dabblings (long > ago): if I install a package (say bash) and later I build a port that > has bash as a dependency, it will be rebuilt (and maybe even > reinstalled, I don't remember that part anymore). I'd say this is > broken, but maybe it's different now? If the dependency is not satisfied then it will be rebuilt (ex: library checked by version and currently installed one is too old). If I recall, the dependency install should fail as it is already installed. This could be easily tested by 'breaking' a dependency test in a port (point it to a nonexistent file or too new of a version) and running make (for the dependencies but a general make or make install should trigger it). Such an issue can be triggered by version changes in the tree vs what is installed (official or custom built ports won't matter then) or ports tree bugs. Only other way I can think to trigger it is to have port options get changed and rebuild+reinstall ports before their dependencies but that should just break the installed port for what I can think of. >>> I have not figured out how to build ports without getting sucked >>> into unbounded rabbit holes of configuration dialogs. I know the >>> advice to do `make config-recursive` upfront, but it doesn't help: >>> what seems to be happening is that I get config dialogs for *all >>> potential* recursive dependencies of the port I'm building, >>> regardless of my answers along the way. For example, even if I >>> exclude X11 support in git configuration, I am then confronted >>> with dialogs which are only relevant to gitk. Is there any way to >>> avoid this? > > I've tried this multiple times, always building a list of overrides > in make.conf (mostly negative ones). I always end up in such a rabbit > hole. I don't know what I'm doing wrong :( > > One of the things I like about FreeBSD is that pretty much everything > has a manpage. That used to be true in some penguin distros as well, > but not any more. So I try to turn on an option for that, if there is > one. > >> `make -DBATCH` will build with defaults while `make -DINTERACTIVE` >> works for the remaining ports and skips batchable ports. Most >> support batch anyway. You can also define these in /etc/make.conf by >> adding lines like BATCH=yes. > > This is interesting and potentially helpful. If I run `make -DBATCH` > in a particular port subtree, will this also be in effect for the > dependencies? Correct. Otherwise it would serve little value. >> Flavors were the answer to get ports that can be packaged with >> different options or dependencies. I say it needs work to reach full >> potential but its a start and can cover cases like with/without a >> gui or building to depend on different version of interpreters. > > Are flavors visible in the pkg tool in any way other than as simply > separate packages (like emacs and emacs-nox)? `make -C/usr/ports/editors/emacs -VFLAVORS` will list that port's flavors. I'd try `pkg install emacs@nox` to request a flavor be installed. I normally do not use those though and admit it seems hard to find documentation for pkg + flavors. My main interaction is dealing with things like the default version of PHP has changed and nextcloud-php82-29.0.5 doesn't get my custom made updates automigrating it to the next php version; my poudriere builds use www/nextcloud for the instruction of what to build so it automatically follows the default for php changes but pkg doesn't know. End result is I don't yet have a solution to avoid having to periodically and manually check & cleanup such leftovers. Seeing packages listed for removal without an appropriate replacement being installed when executing `pkg upgrade` is another clue Always check the output of pkg commands once removal count is not 0 and don't proceed unless you understand why or accept the removals. >> Similarly, if you are building+installing directly from the ports >> tree, you are building in an unclean environment (at least after the >> first port). Sometimes the ported program uses a build system that >> dynamically detects the environment and modifies the build according >> to what it sees. If the port doesn't override autodetections with >> guaranteed forced states of what should be available or not then you >> get a package that depends on something that isn't tracked properly > > I don't quite get this. Where else would the "impostor" environment > come from? Things like a custom PATH you mean? I never got far enough > for that to be a problem :-P Specifically I have previously found that having a port installed that was not a dependency of another port modified its build to include other files; I think it was two kde ports that caused it and I provided a patch which made its way into the tree if I recall. The port's framework didn't modify the autotools (or whatever it was) script which executed during `make configure` (not to be confused with the similar sounding `make config` target). Upon detection, there were changes to what was built and installed. Files were then installed by its `gmake install` (or equivalent) but were never noted in pkg-plist. Removing the port didn't account for those extra files which I think is how I found it (or it caused me some other grief). If I had tried to create a pkg and install it on another machine, those extra files would be missing from the package. As far as the port's framework above it knew, no change had occurred as I hadn't altered any option accordingly so there would have been no reason to alter a plist, change an autoconf flag, etc. https://cgit.freebsd.org/ports/commit/?id=5e33d1709369d21c966c8ac57443a5af99c8b8fa sounds like a real+recent issue & how the port was altered to no longer unintentionally allow autodetect of a dependency instead of following the port's options, or I just misunderstood things. Port maintainers and the build system won't have all of your same ports installed when they rum `make` in a port's directory. If the port uses things like autotools and similar systems to detect what is on your system and modify what they build, how they build it, and what they install and where, then you have different results from the what the maintainer and official repository saw on their run. For files to install, the list normally comes from a manually maintained list found in a port's pkg-plist file (there are exceptions). Ports will usually alter that file conditionally based on options from `make config` or maybe other variables like OS version. I wouldn't expect binutils port to manually detect if a system has elfutils present on it and change how it builds. The build servers will not be in a state where sometimes elfutils is installed and sometimes it is not so you would always get 1 package; having an option/flavor to change that makes a package that reliably can have it be altered for a build step and/or impact its recorded state for a runtime dependency. There are exceptions, but the majority of maintainers and the pkg infrastructure uses clean environments when building. If a bug is found for dirty environments, it should still be reported/fixed. Last I looked a long time ago, I found a # of ports were using already installed copies of files instead of using copies from the workdir when a port is being built (=rebuild/upgrade a port without uninstalling it first). Some ports failed to build until you uninstalled them while other times it builds even though it 'silently' used already install files in place of extracted/built files as it should have. That too is a bug and should be fixed but I assume it sometimes requires more extensive reworking of the tooling that the program originally uses for building. Maybe someday I will do another run on a few ports looking for that.