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


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc05a37.6040...@gmail.com

Reply via email to