From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=DATE_IN_PAST_12_24,DMARC_NONE, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,INVALID_DATE,MAILING_LIST_MULTI, RDNS_DYNAMIC autolearn=no autolearn_force=no version=4.0.0 Received: from as1-4-5-1.han.s.bonet.se ([194.236.131.211] helo=fry) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15VYz8-0008Vd-00 for gentoo-dev@cvs.gentoo.org; Sat, 11 Aug 2001 07:39:27 -0600 Received: from fry (fry [127.0.0.1]) by fry (Postfix) with ESMTP id 989EC68E for ; Sat, 11 Aug 2001 15:37:12 +0200 (CEST) Subject: Re: [gentoo-dev] The new Portage Job System From: Mikael Hallendal To: gentoo-dev@cvs.gentoo.org In-Reply-To: <0108111205010F.00661@desktop.dan.net> References: <0108111205010F.00661@desktop.dan.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12.99 (Preview Release) Message-Id: <997537032.5103.20.camel@fry> Mime-Version: 1.0 Sender: gentoo-dev-admin@cvs.gentoo.org Errors-To: gentoo-dev-admin@cvs.gentoo.org X-BeenThere: gentoo-dev@cvs.gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@cvs.gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Sat Aug 11 07:40:02 2001 X-Original-Date: 11 Aug 2001 15:37:12 +0200 X-Archives-Salt: 4ffba5c8-5f06-41ec-80e3-d25a8a2352ff X-Archives-Hash: 21e88daa15c96bd2972457e2ffbce5ed Den 11 Aug 2001 12:05:01 +0300 skrev Dan Armak: > Hi all, Hi! As I was in the discussion on IRC #gentoo I agree that we should have something like this, I do howevery disagree on some of the stuff below... > Under profiles/jobs, or in a similar location, will be a job dir (Possibly > profiles/default/jobs, and the references may then be redirected through > /etc/make.profile). Developers can place jobs in it for Portage to execute. Should it really be possible to redirect this? I guess it should always be in the same place in portage and should be redirected by redirecting the portage-tree. > Helper files: > ---------------- > Jobs can have misc files, a separate dir should be given to these i.e. > profiles/jobs/files. Agreed. > Generic scripts: > -------------------- > Provide a dir profiles/jobs/scripts and populate it with *generic* scripts. > Under profiles/jobs put job spec files which, in their first few (commented > out) lines, have info about when to run them, and then have a #! line that > specifies one of these generic scripts as the interpreter. For example, a job > spec for moving a package would be called move-koffice.job, and begin: > > # Job spec description: move the koffice package from kde-apps to app-office > # Run Once > # Author: Dan Armak > # $Header: $ > #! /usr/portage/profiles/jobs/scripts/movepackage.sh > move koffice kde-apps app-office > ... > and so on, from here script-specific info would follow. This is the best > model IMHO. > Of course, under this model a job file can still be a script in its own > right, and use none of the generic scripts. I really don't like this approach. This way a wrong written script might corrupt a users database. I think it's better if we have a few scripts (i.e. those we have found out we need) and then we use the job-files for giving parameters to the script. Like in the case of moving a package we could have something like: In job-file: type: rellocate author: Mikael Hallendal version: $Header$ control-file: koffice-to-app-office.control the control-file is then in files/ portage takes a look at type, recognizes it as a rellocate-type of job. It excecutes: '/usr/lib/portage/bin/rellocate /usr/portage/profiles/jobs/files/koffice-to-app-office.control' Only the system-team may add/approve scripts into portage so that we get some control of what goes in. This way a badly written job-file will result in an error when excecuting the script. A badly written control-file might do more damage but I think this is unavoidable and the control-file should have a really easy syntax. > The Portage-handled header: (I don't like this but have no better > ideas) Hmm, I'm not sure I follow you here. What is this for? > When to run - options: > ----------------------------- > 1. The jobs will be executed after each run of emerge, including emerge rsync. What types of jobs would be needed to run after each emerge? > 2. Before each run of emerge, to accommodate the following scenario: change > in cvs requires job to run before any emerges. How will this be of any use. If something changed in the cvs it will break the users tree at the same time he gets the job-descr. the actuall job wouldn't run until next rsync. > 4. Provide "emerge jobs" command to run on demand. I think that we should have a 'emerge jobs'-kinda a tool which should be used by developers which don't use 'emerge rsync'. I do however think that jobs for users should be run by 'emerge rsync' and no otherwise. > Ideas/needs for jobs: > --------------------------- > 1. Move a package to a different category, update /var/db/pkg if the package > was already installed. This is what we're doing with kde/gnome. This is indeed a very much needed. > 2. Output some info to the user. For example about an important new change in > Portage/emerge/new KDE version etc., for the users who don't read the cvs > logs or gentoo-dev. This is also a good feature. But should only be run after an emerge rsync. > 3. Merge a new version of sys-apps/portage when this is needed for some > ebuilds' new versions to work, like in the \" story. A user who got the new > ebuilds with non-escaped quotes but didn't update portage would be in big > trouble. Perhaps this should be handled either by (2), ie. give the user a message about upgrading there portage-system. Or by actually doing inside of 'emerge rsync'. The problem with automatically do stuff is that there are people (me for one) that don't like when things happend by themself. I like to have control of when I do update a package. > 4. After merging a package, output usage intructions. Deprecate the > pkg_postinst usage, emerge outputs info after it anyway. > > 5. As above, run a configuration program. > > 6. Manage a bug report system. A user who got an error running one of uor > ebuilds would get this job executed. > ... 4-5 should be handled inside the ebuild (imho). I see no reason why it should be in the jobs-system instead. If a package needs to be configured afterwords it should be done in pkg_postinst (). Same for giving the user a notice about the package. 6: would be a nice feature, but I don't think that it should be a job, it should be in portage system itself. The system should give a question if it fails to merge an ebuild asking if the user would like to report the bug. If so it starts the routines for doing so and puts the results in /var/db/bug-reports or something, then when doing emerge rsync portage looks in /var/db/bug-reports and sends them somewhere. Regards, Mikael Hallendal