From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EI74c-0000Ka-Fl for garchives@archives.gentoo.org; Wed, 21 Sep 2005 16:03:54 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j8LFvEFe015196; Wed, 21 Sep 2005 15:57:14 GMT Received: from loopy.telegraphics.com.au (loopy.telegraphics.com.au [202.45.126.152]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j8LFvAlJ013707 for ; Wed, 21 Sep 2005 15:57:13 GMT Received: by loopy.telegraphics.com.au (Postfix, from userid 1001) id 51C71E81CE; Thu, 22 Sep 2005 02:03:08 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by loopy.telegraphics.com.au (Postfix) with ESMTP id 507B0E7FCA for ; Thu, 22 Sep 2005 02:03:08 +1000 (EST) Date: Thu, 22 Sep 2005 02:03:08 +1000 (EST) From: Finn Thain To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] idea: strict run-time dependencies to remove perl-cleaner, python-updater... In-Reply-To: Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="768252030-1708706050-1127318588=:22779" X-Archives-Salt: 07474314-6d34-4199-af7c-e56281702376 X-Archives-Hash: c0941bdcefff6a49d3d9f9fbc7cbf9ae This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --768252030-1708706050-1127318588=:22779 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Sep 2005, pclouds wrote: > This is an idea. > Everytime you update python, perl to a major version, you have to run > perl-cleaner/python-updater to re-emerge all packages that depend on > previous version. The situation is probably similar to kernel > packages. When you re-compile and install new kernel, you need to > re-emerge kernel packages to make sure it work properly. I'd rather a > consistent approach to solve these problems instead seperate updater > for separate programs such as python-updater, perl-cleaner. >=20 > The idea is to use a number to identify compatibility. Those versions > which have the same number are expected to work well with other > installed programs. If the number is different, then all other depend > programs should be re-emerged. I assume there is no such thing as a kernel-updater (at least there isn't= =20 one on my system). Your suggestion would make it easier to write one. But,= =20 since kernel symbol versioning is precise enough to detect ABI=20 compatibility between versions, isn't the problem largely solved in the=20 kernel? I'm not sure that such a script is needed other than to save you=20 from having to figure out what pkg contains the module that just broke? There is also the problem that some portion of gentoo users roll their own= =20 kernels, without telling portage. So, if you wanted to write a kernel-updater, wouldn't it be better to=20 exhaustively check the module symbols against the Module.symvers file?=20 (There is also the vermagic field in modinfo, not sure where that comes=20 from. I'm assuming CONFIG_MODVERSIONS, but those not using that hopefully= =20 know what they are doing anyway :-). > When portage merge a package (A) to system, it allow the package to > specify a number (or string, whatever) to specify a compatibility > number. When other packages (e.g B) that depend on package A are > merged, it will keep A's special number in /var/db/pkg. If package A > is re-emerged and break compatibility, this number should change. > Otherwise, this number remains the same. > Those program like perl-cleaner, python-updater may benefit from these > numbers. It may check for numbers stored in /var/db/pkg's B and number > in A's. If these numbers differ, B should be re-emerged. > As for python, all python 2.4's number should be "2.4" and python > 2.2.x should be "2.2". Perl is similar. As for kernel, the number > should be timestamp. The rebuilder/module ebuilds don't need to know that version x is=20 compatible with version x+n if the rebuilder is only ever run upon ebuild= =20 advise after an upgrade. Consequently, you could just have portage record the actual versions of=20 the deps that were in use at the time a pkg was emerged (if it doesn't=20 already?). Then the rebuilder just has to look for any kernel modules that= =20 were emerged while depending on a kernel older than the present one. (I=20 don't know if this would help with package.provided kernels and=20 !CONFIG_MODVERSIONS kernels, it might.) IMHO an exhaustive search is still the best approach. (But don't ask me what you do if the module is not slotted and the=20 original kernel is still installed as a fall back...) -f > Suppose i can feed a kernel ebuild with a config file :), then everytime= =20 > i change config, re-emege kernel, compatibility number should change.=20 > That's the signature for, say, kernel-updater to update all kernel=20 > packages. >=20 > To implement this feature, ebuild should provide a function, say, > pkg_version() that return compatibility number. Portage should store > this number in /var/db/pkg. Also, when emerge an ebuild, portage > should store current compatibility numbers of all direct dependencies. > The rest of work is left to perl-cleaner, python-updater, > kernel-updater ..., checking compatibility numbers and update packages > appropriately. >=20 > How about this? > -- > Bi C=E1=BB=9D Lao >=20 >=20 --768252030-1708706050-1127318588=:22779-- -- gentoo-portage-dev@gentoo.org mailing list