[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#454329: tetex-base -- Doesn't purge all files after piuparts Install+Upgrade+Purge test

Frank Küster wrote:
> Dear Luk,
> I've got a question regarding a fix for the piuparts test release
> goal. Kumar who reported the bug redirected us to you.
> Kumar Appaiah <a.kumar@alumni.iitm.ac.in> wrote:
>>>>    /etc/texdoctk/texdoctk.dat     owned by: tetex-base
> [...]
>>>>    /etc/texmf/updmap.d/10tetex-base.cfg   owned by: tetex-base
>>> I'm a bit puzzled about the two files which are still owned by
>>> tetex-base after purging the package. Isn't that a bug in dpkg?
>> This could be possible, though I am unsure. Also, I think the
>> ownership of the file is being reported by piuparts; that is, piuparts
>> records the package to which each file belongs. 
> This is true, it's not dpkg's fault.
> But here comes the real question to you, Luk:
>>> On the other hand, I have a question regarding 10tetex-base.cfg.
>>> tetex-base is now only a transitional package.  We already have code in
>>> the TeXLive packages which "handles" this file: It is made ineffective,
>>> but renamed into 10tetex-base.cnf.obsolete.
>>> This was done on purpose, because this conffile might contain local
>>> changes which are still valuable for the local admin, although there's
>>> no way for an automatic taking over to some "current" conffile. 
>>> I feel that this should be a valid reason to keep a file around after a
>>> transition. Did you discuss similar situations in the context of this
>>> release goal?  Whom could I ask for advice?
> And Kumars main answer was to ask you...

The thing is that it's not just a transition, it's an install, an
upgrade and a purge. When someone purges a package there shouldn't be
any owned files left... But you're kind of right that this is a dpkg bug
as it doesn't support taking over conffiles properly. So my advice is to
either leave it as is and 'wait' for a solution in dpkg or remove the
files when purged. The latter is only tricky when *after* the transition
the file can still be owned by more than one package from a maintainer's
point of view.



Reply to: