Michael Tokarev writes:
> On 03.09.2012 12:15, Guillem Jover wrote:
>> But then --control-path was intended only for read accesses for things
>> like dpkg-repack or dpkg-reconfigure, never for *removing* files from
>> the dpkg database. Removing such files from maintainer scripts is just
>> *wron
On 03.09.2012 12:15, Guillem Jover wrote:
[]
> But then --control-path was intended only for read accesses for things
> like dpkg-repack or dpkg-reconfigure, never for *removing* files from
> the dpkg database. Removing such files from maintainer scripts is just
> *wrong*, the correct solution is t
On Sun, 2012-09-02 at 15:41:48 -0700, Steve Langasek wrote:
> On Sun, Sep 02, 2012 at 11:26:34PM +0100, Ben Hutchings wrote:
> > > Not sure about cleaner, but that's the supported dpkg interface.
>
> > That certainly seems a bit cleaner than assuming we know what the dpkg
> > database looks like i
Hi,
On Sun, 02 Sep 2012, Steve Langasek wrote:
> > That certainly seems a bit cleaner than assuming we know what the dpkg
> > database looks like it. However the manual page says 'Warning: this
> > command is deprecated, please switch to use --control-list and
> > --control-show instead.' Those
On 02.09.2012 23:54, Ben Hutchings wrote:
> On Sun, 2012-09-02 at 23:17 +0400, Michael Tokarev wrote:
> [...]
>> But the OP system does not have old autofs5 package installed,
>> only the config files from it, and the maintscripts. Which is
>> exactly the problem.
>>
>> I want to ensure that if ol
Steve Langasek wrote:
> Ben Hutchings wrote:
> > # in autofs.postinst
> > rm -f /var/lib/dpkg/info/autofs5.postrm
> > (There may be a cleaner way to do this.)
>
> if postrm=$(dpkg-query -c autofs5 postrm 2>/dev/null); then
> rm -f "$postrm"
> fi
>
> Not sure about cleaner, but that's the su
On Sun, Sep 02, 2012 at 11:26:34PM +0100, Ben Hutchings wrote:
> > if postrm=$(dpkg-query -c autofs5 postrm 2>/dev/null); then
> > rm -f "$postrm"
> > fi
> > Not sure about cleaner, but that's the supported dpkg interface.
> That certainly seems a bit cleaner than assuming we know what the dp
On Sun, 2012-09-02 at 14:04 -0700, Steve Langasek wrote:
> On Sun, Sep 02, 2012 at 08:54:39PM +0100, Ben Hutchings wrote:
> > On Sun, 2012-09-02 at 23:17 +0400, Michael Tokarev wrote:
> > [...]
> > > But the OP system does not have old autofs5 package installed,
> > > only the config files from it,
On Sun, Sep 02, 2012 at 08:54:39PM +0100, Ben Hutchings wrote:
> On Sun, 2012-09-02 at 23:17 +0400, Michael Tokarev wrote:
> [...]
> > But the OP system does not have old autofs5 package installed,
> > only the config files from it, and the maintscripts. Which is
> > exactly the problem.
> > I wa
On Sun, 2012-09-02 at 23:17 +0400, Michael Tokarev wrote:
[...]
> But the OP system does not have old autofs5 package installed,
> only the config files from it, and the maintscripts. Which is
> exactly the problem.
>
> I want to ensure that if old autofs5 is installed, installing
> new autofs sh
On 02.09.2012 21:21, Salvatore Bonaccorso wrote:
[]
>> Basically I want to ensure that if one installs package B to
>> a system with A installed, A should be upgraded to A' at the
>> same time. This works when upgrading A to A' (satisfying A'
>> dependency and installing B), but does not work when
Hi Michael
On Sun, Sep 02, 2012 at 02:18:56PM +0400, Michael Tokarev wrote:
> It's been not once when I hit an issue described below.
> Now I hit it in one of the packages I maintain, but so
> far I can't figure out a good solution for it.
>
> The issue is with package renaming and handling of dp
Hello.
It's been not once when I hit an issue described below.
Now I hit it in one of the packages I maintain, but so
far I can't figure out a good solution for it.
The issue is with package renaming and handling of dpkg
maintscripts.
Having in mind typical renaming scenario: package A has
been
13 matches
Mail list logo
