Fwd: Re: [clc-devel] core/opt dependencies
--- Jay Dolan wrote:
Date: Fri, 30 Dec 2005 06:28:36 -0800 (PST) From: Jay Dolan Subject: Re: [clc-devel] core/opt dependencies To: Juergen Daubert
--- Juergen Daubert wrote:
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 ...
There is really no need for such metadata. Per will compile a list of ports (probably very close to what was 'base') that will be pre-selected when setup is run. When else do you need to know what's in 'base'? In this way, setup will be slightly less confusing to first-timers, too, because they will not be faced with "What's base, opt, and contrib?" Instead, just the package names will be visible because if it's on the cd, it's 'core'. Let's not make it more complicated than it has to be :)
Sorry for the 2x mail Jue. Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
On Fri, Dec 30, 2005 at 06:30:04AM -0800, Jay Dolan wrote:
--- Jay Dolan wrote:
There is really no need for such metadata. Per will compile a list of ports (probably very close to what was 'base') that will be pre-selected when setup is run. When else do you need to know what's in 'base'? In this way, setup will be slightly less confusing to first-timers, too, because they will not be faced with "What's base, opt, and contrib?" Instead, just the package names will be visible because if it's on the cd, it's 'core'. Let's not make it more complicated than it has to be :)
ok, than the ports listed as dependencies in core ports are all of core but not those one on that list ? Where is that list ? Hmm, sounds not very straight-forward to me, but anyway, as long as this point is not really clear, it makes no sense to touch the core ports and add any dependency information. best regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
--- Juergen Daubert <jue@jue.li> wrote:
ok, than the ports listed as dependencies in core ports are all of core but not those one on that list ? Where is that list ?
Hmm, sounds not very straight-forward to me, but anyway, as long as this point is not really clear, it makes no sense to touch the core ports and add any dependency information.
I think all ports except a very select few (c build chain) will have dependency information. Deps will be omitted from those ports simply because users won't be expected to rebuild them. They will be updated only with new CRUX releases - thus we can ensure a consistent bootstrapped build environment. Those few ports happen to be a subset of 'preselected essential setup packages' - a list that only needs to be maintained in the setup script. Does this make sense? Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
On Fri, Dec 30, 2005 at 07:39:25AM -0800, Jay Dolan wrote:
I think all ports except a very select few (c build chain) will have dependency information.
You are still talking about run-time dependencies ? -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
--- Juergen Daubert <jue@jue.li> wrote:
You are still talking about run-time dependencies ?
Correct. And so, I'm not even sure that there /are/ any dependencies for them (not exactly things I know a heck of a lot about). But either way, the ports for gcc, glibc, binutils, ..will not have a populated Depends on: line because it is not recommended that users rebuild or update these ports in the first place. Thus, the ports tree is more-or-less uniform. All ports advertise runtime dependencies except for those belonging to the c build chain. In the users eyes, these are 'do not touch' anyway. Furthermore, setup simply maintains a list of what is necessary to have a functional install, and those are only preselected (not forced). The only classification for 'core' is 'I'm on the cd'. Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Jay Dolan [2005-12-30 08:30]:
Thus, the ports tree is more-or-less uniform. All ports advertise runtime dependencies except for those belonging to the c build chain. In the users eyes, these are 'do not touch' anyway. Furthermore, setup simply maintains a list of what is necessary to have a functional install, and those are only preselected (not forced).
This doesn't solve the issue w/ pkgconfig (which is a build time dependency, but it certainly doesn't belong to the c build chain). Regards, Tilman -- GnuPG key available at http://code-monkey.de/files/tsauerbeck-public-key.asc
On 12/30/05 17:39 Tilman Sauerbeck wrote:
Thus, the ports tree is more-or-less uniform. All ports advertise runtime dependencies except for those belonging to the c build chain. In the users eyes, these are 'do not touch' anyway. Furthermore, setup simply maintains a list of what is necessary to have a functional install, and those are only preselected (not forced).
This doesn't solve the issue w/ pkgconfig (which is a build time dependency, but it certainly doesn't belong to the c build chain).
True, the same could be said about findutils and sed: maybe they're not strictly needed but they're often used at build time. I had a deeper look at the current core collection: I consider most of the ports to be essential for a functional Linux setup. Personally I'd prefer to have all the GUI-related stuff in opt, since most of my installations are server related; my concept of 'do not touch' includes all the other core ports and goes a litlle beyond the mere toolchain. I understand this view is totally subjective, anyway as stated before this way is a lot easier for packagers since it provides a well-defined list of implicit dependencies that are available on a minimal (but not to the extreme) CRUX system. That said I think this adantage is valueable not only at CRUX installation time. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
participants (4)
-
Jay Dolan -
Juergen Daubert -
Simone Rota -
Tilman Sauerbeck