Tzafrir Cohen wrote: > On Tue, Apr 24, 2007 at 10:34:50PM +0900, Charles Plessy wrote: >> Le Tue, Apr 24, 2007 at 09:17:38AM -0400, Matthew McGuire a écrit : >> >>> a single tasksel system does sound nice, but it makes building the >>> iso images for the installers impossible. If the user can select an >>> essentially infinite number of tasks from the one interface then >>> the installer would require a disk image too large for CD media. >> Hi, >> >> I think that a solution was already previously proposed by me and >> others: If the pacakges necessary for the installation of the CDDs were >> not available, the tasks would be greyed, and when the network is >> available, it does not matter that the packages pulled by the CDD are >> not present on the physical installaiton medium. > > If the network is not loaded, then the network packages sources are > remmed out by the installer, right? > > So if the local media has only the tasks that are available from local > packages, the problem is solved, right? >
That seems reasonable to me. Since the base system is installed by d-i by default regardless of the task selection it seems reasonable that tasksel remove items that cannot be satisfied by the contents of the configured apt repository. After some brief looking at tasksel source I think all the necessary features exist. Theoretically the tasks directory could be populated with new task files by the CDD team as needed. Additionally it seems reasonable to use udebs to do so. Since there are no declared conffiles for tasksel this is probably the most direct route to changing the available task list for a CDD. So this supports the arguments given earlier about how to maintain the CDD specific tasks. The more I look at this the more I think the trade-off is worth it. This way a given CDD could have sub-tasks for specific use inside the overall CDD. Imagine if you will a business CDD with the following tasks: debian-business-directory-server debian-business-kerberos-server debian-business-desktop debian-business-ltsp-server debian-business-ltsp-client Ok, so that list may be overkill, but I think it delivers my point. Would people be averse to this approach? If so why? Additionally are there any alternate approaches? I haven't seen a detailed alternative on list. Now to figure out how to build a CDD specific d-i based on the d-i build system. I noticed there are daily images built for business card and netinstall images. Would someone be willing to share the daily build scripts for these? I would like to see if something like jigdo could be leveraged to help build CDD specific d-i images. Consider the possibility that CDD images are officially released via jigdo. So that we don't waste a bunch of disk space on the delta between the different CDD projects and at the same time properly advertise the CDD as a project internal to Debian. Yes, Debian Internal Project makes better sense to me as well. The really nice feature of this approach is the current installer disks don't have to be changed. That is unless I find something that gets in the way. :-) Any feedback is welcome. This doesn't look as complex as I initially thought. Thanks, Matthew PS: I am not at all versed in debian-edu solutions so I welcome any ideas from them or other existing derivative groups. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
