[clc-devel] core/opt dependencies
Hi all, one outstanding point is still the question how to deal with dependencies for core and even opt ports. IIRC one result of CruxCon 2005 was, to handle that in the following way: - All core/opt ports should list run-time dependencies - but not to glibc and gcc - no build-time dependencies As a first step I've created a dependency list of all core ports [1] with a slightly modified version of Johannes' 'finddeps' [2]. To simplify this, the script 'mkdeplist' [3] could be used. The output of 'reducedeps' [4] is a compressed list with no redundant dependencies [5]. [6] is a list of all core/opt ports installed on my system. Be aware, [3] and [4] are quick hacks without any comments and error checks. One drawback of the method above is, that the list is not complete, because only deps which can be found with ldd are listed. Other deps like hicolor-icon-theme for gtk or ruby for yapo are missing. Ok so far, but how to proceed ? - if we agree with the rules above, I'll add all the missing deps to the core ports. - remove build-time deps like pkgconfig - define a list of core-core ports, which must be installed to build ports, or ... ? - it would be nice if we had a complete core/opt list. I'm volunteer for creating/maintaining such a list. To build them I need the output of 'mkdeplist /usr/ports/opt'. Thanks for your attention and kind regards Juergen [1] http://jue.li/crux/misc/core_deps_full.txt [2] http://jue.li/crux/misc/finddeps [3] http://jue.li/crux/misc/mkdeplist [4] http://jue.li/crux/misc/reducedeps [5] http://jue.li/crux/misc/core_deps.txt [6] http://jue.li/crux/misc/all_deps.txt -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
On 12/29/05 12:27 Juergen Daubert wrote:
one outstanding point is still the question how to deal with dependencies for core and even opt ports. IIRC one result of CruxCon 2005 was, to handle that in the following way:
- All core/opt ports should list run-time dependencies - but not to glibc and gcc - no build-time dependencies
Maybe I'm a bit late for this note, anyway, after having used the new collection layout for a while, I feel a bit nostalgic regarding the previous base/opt division. To me x11, gtk, firefox etc are not exactly what I'd call core requirements for a CRUX setup (even if it's important to have them on the iso). An idea is to move the ports from the previous opt collection into the current opt, with some ex-base port too, thus obtaining a true core collection, that really represent things that should not be removed (ie by prt-get) and are not listed as dependencies for other ports since they're implied (pkgconfig?). Note that this will not impact end users at all.
- remove build-time deps like pkgconfig - define a list of core-core ports, which must be installed to build ports, or ... ?
This two points would be handled by the suggested core/opt separation.
- if we agree with the rules above, I'll add all the missing deps to the core ports. - it would be nice if we had a complete core/opt list. I'm volunteer for creating/maintaining such a list. To build them I need the output of 'mkdeplist /usr/ports/opt'.
I plan to setup (in a few days) a build machine to fully test core and opt ports for missing deps, broken urls, etc. I'll send you the list of found deps for opt on a stock opt+core setup. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Simone Rota [2005-12-29 21:19]:
On 12/29/05 12:27 Juergen Daubert wrote:
one outstanding point is still the question how to deal with dependencies for core and even opt ports. IIRC one result of CruxCon 2005 was, to handle that in the following way:
- All core/opt ports should list run-time dependencies - but not to glibc and gcc - no build-time dependencies
Maybe I'm a bit late for this note, anyway, after having used the new collection layout for a while, I feel a bit nostalgic regarding the previous base/opt division.
To me x11, gtk, firefox etc are not exactly what I'd call core requirements for a CRUX setup (even if it's important to have them on the iso).
Yes, I've been thinking about this as well.
An idea is to move the ports from the previous opt collection into the current opt, with some ex-base port too, thus obtaining a true core collection, that really represent things that should not be removed (ie by prt-get) and are not listed as dependencies for other ports since they're implied (pkgconfig?).
I like this proposal. Regards, Tilman
On Thu, Dec 29, 2005 at 09:19:24PM +0100, Simone Rota wrote:
On 12/29/05 12:27 Juergen Daubert wrote:
one outstanding point is still the question how to deal with dependencies for core and even opt ports. IIRC one result of CruxCon 2005 was, to handle that in the following way:
- All core/opt ports should list run-time dependencies - but not to glibc and gcc - no build-time dependencies
Maybe I'm a bit late for this note, anyway, after having used the new collection layout for a while, I feel a bit nostalgic regarding the previous base/opt division.
To me x11, gtk, firefox etc are not exactly what I'd call core requirements for a CRUX setup (even if it's important to have them on the iso).
I can understand your feelings about the current divison of ports in core/opt. We still have the problem, that we try to map some basic functionallity with a filesystem layout. ATM core represents all ports included on the cd. But I agree that x11, gtk etc. are not vital for a "core" crux system. One desperate approach could be to put all core/opt ports in one collection, e.g crux, and achieve the additioal grouping with some extra meta-data in the Pkgfiles or other mechanisms like helper-files ... kind regards Jürgen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Hi, On Thu, Dec 29, 2005 at 21:19:24 +0100, Simone Rota wrote: [...]
Maybe I'm a bit late for this note, anyway, after having used the new collection layout for a while, I feel a bit nostalgic regarding the previous base/opt division.
To me x11, gtk, firefox etc are not exactly what I'd call core requirements for a CRUX setup (even if it's important to have them on the iso).
An idea is to move the ports from the previous opt collection into the current opt, with some ex-base port too, thus obtaining a true core collection, that really represent things that should not be removed (ie by prt-get) and are not listed as dependencies for other ports since they're implied (pkgconfig?).
I agree that the "don't touch it unless you know what you're doing" property of base ports was quite nice. In fact, while reading your post I thought that it's maybe even wrong to have i.e. windowmaker or gtk in core; I'd prefer if the ports tree would be neutral WRT things like window managers etc. why should windowmaker be in core, and all the others in opt? Using "Per's choice" for the official ISO sounds good to me, but it seems to me that there's no real (user-visible) reason to reproduce that in the ports tree. The two disadvantages are that it's less transparent to the user what's included on the ISO and that it requires some changes to the top level Makefile to build the ISO images (which on the other hand will probably make it easier to build ISO images with blackbox instead of windowmaker ;-)). While I'm convinced that Simone's proposal is better than the current situation, we'll have to make sure that it's worth the effort. If a majority here thinks it is, I'm all for it. Let's try to agree on something before we make a 2.2 release. Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Hi all,
one outstanding point is still the question how to deal with dependencies for core and even opt ports. IIRC one result of CruxCon 2005 was, to handle that in the following way:
- All core/opt ports should list run-time dependencies - but not to glibc and gcc - no build-time dependencies That sounds fine to me. As mentioned later in this thread, there's a
Hi, On Thu, Dec 29, 2005 at 12:27:22 +0100, Juergen Daubert wrote: list of build time requirements which we expect the users to install; examples for those are: wget, make, binutils, autoconf, automake, libtool, pkgconfig, tar, gzip, bzip2, patch, grep, find, sed, awk, plus those I forgot. There's an extended selection of ports which are kinda required to run a crux system, like rc, filesystem, util-linux etc. I guess it might be a good idea to list both categories of "required" ports in the handbook of the future release. Jürgen, thanks for your time and efforts to get this change done. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
participants (4)
-
Johannes Winkelmann -
Juergen Daubert -
Simone Rota -
Tilman Sauerbeck