Re: prerm for disappearing packages?
Jonathan Nieder wrote:
> However it is implemented, the rule should be:
>
> When it is time for a transitional package to go, it is removed just
> as though the user specified "dpkg --remote $pkgname".
Yes.
> What is a transitional package and when is its time to go is
> complicated issue.
Currently, yes. If we add a special section/control field/whatever else, it
does not. Front-end will do all the upgrade then see what packages which was
upgraded are transitional and do removal of them.
[...] Removing the
> transitional package as early as dependencies allow can simplify
> dependency resolution for other packages in the same run
Hmm, I failed to imagine a scenario for simplification. Do you have an example?
>> Failed maintainer script results or in upgrade stop
> [...]
>> or dpkg managers to call other maintainer scripts as a fallback, they succeed
>> (if they not, upgrade stops too) and upgrade continues.
>
> I used to think of it that way, but AFAICT I was confused.
>
> Example:
>
> Suppose I want to upgrade packages a, b, and c to a new version with
> Depends: bash (>= 5). Upgrading bash to version 5 fails (in preinst,
> say), so dpkg aborts the bash upgrade (bash 4.1 postinst succeeds).
> Now what?
Upgrade stops, bash maintainer receives a pair of grave bugs :) What else can
we do?
> What I meant is it could ask the user instead of starting over. In
> some special cases (automatic build machine capable of diagnosing and
> solving problems such as lack of free space?) something smarter might
> be possible.
I don't see much difference with 'upgrade stops, smart AI resolves the
problems and calls the same front-end command'. Front-end will figure that
some of packages are already upgraded and will schedule the actions to
continue the plan. Or even different front-end/dpkg commands can be done by
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
Reply to: