On Sat, Dec 05 2009, Norbert Preining wrote:
> Not wanting to start another flame war, but ...
>
> On Sa, 05 Dez 2009, Patrick Schoenfeld wrote:
>> The crux is the last point. For a good reason postrm must not require
>> tools it depends on to be around when removing the package itself.
>
> making
Not wanting to start another flame war, but ...
On Sa, 05 Dez 2009, Patrick Schoenfeld wrote:
> The crux is the last point. For a good reason postrm must not require
> tools it depends on to be around when removing the package itself.
making dpkg policy compliant would help, too, then we removed
On Sat, Dec 05 2009, Patrick Schoenfeld wrote:
> On Sat, Dec 05, 2009 at 05:25:29PM -0600, Manoj Srivastava wrote:
>> On Sat, Dec 05 2009, Patrick Schoenfeld wrote:
>>
>> > On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote:
>> >> It is the package's responsibility to remove those files
Package: wnpp
Owner: Jonathan Yu
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libtest-corpus-audio-mpd-perl
Version : 1.093230
Upstream Author : Jerome Quelin
* URL : http://search.cpan.org/dist/Test-Corpu
On Sat, Dec 05, 2009 at 05:25:29PM -0600, Manoj Srivastava wrote:
> On Sat, Dec 05 2009, Patrick Schoenfeld wrote:
>
> > On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote:
> >> It is the package's responsibility to remove those files, "ucf --purge"
> >> does not do that, see ucf(1).
> >
On Sat, Dec 05 2009, Patrick Schoenfeld wrote:
> On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote:
>> It is the package's responsibility to remove those files, "ucf --purge"
>> does not do that, see ucf(1).
>
> I never said that. The problem are not the files owned by the package,
> bu
On Sat, Dec 05, 2009 at 07:16:58PM +0100, Daniel Baumann wrote:
> Patrick Schoenfeld wrote:
> >So the call of ucf looks something like that:
> >
> >if which ucf >/dev/null; then
> >ucf --purge /etc/foo.conf
> >fi
>
> no, the correct one is:
>
> if which ucf >/dev/null; then
>
On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote:
> It is the package's responsibility to remove those files, "ucf --purge"
> does not do that, see ucf(1).
I never said that. The problem are not the files owned by the package,
but the files owned by ucf, which are modified by ucfr, whi
On Sat, Dec 05 2009, Patrick Schoenfeld wrote:
> What speaks against it? Its basically a mini tool (Installed-Size: 260)
> and not making it essential leads to the mentioned situations.
I am afraid I do not follow -- what situations are improved by
making ucf essential?
> The only bad
On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote:
> the right solution here would be to fix it so that it did, not to add
> it to Essential.
On a side note, I thought the right solution was to integrate the ucf
functionality into dpkg. Any update on this, or was this just wishful
th
On Sat, Dec 05, 2009 at 06:17:20PM +0100, Patrick Schoenfeld wrote:
> > ucf being priority required is not sufficient. It is still possible to
> > remove such a package (mawk is a good example) and therefore you would
> > still need to execute ucf conditionally.
> You are right. My bad.
> > The
To whom it may concern:
I agree completely with Damyan's idea, and Gregor seems to be
supportive of it. Nothing depends on it in Debian, and I am all for
improving general code quality of what we have, even if it is to the
exclusion of this package.
Users that really need it can always use the CP
On 2009-12-05, Daniel Baumann wrote:
> Patrick Schoenfeld wrote:
>> So the call of ucf looks something like that:
>>
>> if which ucf >/dev/null; then
>> ucf --purge /etc/foo.conf
>> fi
>
> no, the correct one is:
>
> if which ucf >/dev/null; then
> $whatever_ucf_command /
Patrick Schoenfeld wrote:
So the call of ucf looks something like that:
if which ucf >/dev/null; then
ucf --purge /etc/foo.conf
fi
no, the correct one is:
if which ucf >/dev/null; then
$whatever_ucf_command /etc/foo.conf
else
rm -f /etc/foo.conf
fi
--
Address:
On Sat, Dec 05 2009, Patrick Schoenfeld wrote:
Short Answer: hell no.
Read below for why that would be a bad idea.
> when testing my packages with piuparts I noticed an inability of
> our package management. Dpkg does not have support for management
> of dynamically generated con
On Sat, Dec 05 2009, brian m. carlson wrote:
> On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote:
>> That is okay, as long as ucf is around. But as soon as it isn't
>> the purge of a package is succesful while leaving modified files around.
>> So the effect is that a purge does no
On 2009-12-05 16:47 +0100, Patrick Schoenfeld wrote:
> Hi,
>
> when testing my packages with piuparts I noticed an inability of
> our package management. Dpkg does not have support for management
> of dynamically generated configuration files. Therefore some packages
> now use ucf.
>
> The basic u
On Sat, Dec 05, 2009 at 04:56:02PM +, brian m. carlson wrote:
> On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote:
> > That is okay, as long as ucf is around. But as soon as it isn't
> > the purge of a package is succesful while leaving modified files around.
> > So the effect
On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote:
> That is okay, as long as ucf is around. But as soon as it isn't
> the purge of a package is succesful while leaving modified files around.
> So the effect is that a purge does not "remove everything".
>
> Do we really want that?
Hi,
when testing my packages with piuparts I noticed an inability of
our package management. Dpkg does not have support for management
of dynamically generated configuration files. Therefore some packages
now use ucf.
The basic usage is somewhat like
- Registering config files to ucf on installat
Le vendredi 4 décembre 2009 20:36:19, Joey Hess a écrit :
> But it does seem likely that packages using it could fall back to
> current config file handling if Config::Model were not available
> in an embedded system.
Agreed. That's a reasonable goal.
Dominique
--
http://config-model.wiki.sourcef
Le vendredi 4 décembre 2009 19:38:19, Neil Williams a écrit :
> That's a user change, I thought the point of this was that changes *not
> done by users* are causing problems. Different problem.
Currently, debian package will detect correctly if a user (or a script) left
the configuration unmodifi
On Sat, 05 Dec 2009 09:58:59 +0200, Damyan Ivanov wrote:
> > Useful suggestions are gladly accepted and appreciated. Please give me a
> > less crappy alternative. I beg of you. PLEASE.
> File RM: bug on libwordpress-xmlrpc-perl. Less bad code = less
> problems in the long term.
$ apt-cache rdepe
-=| Jonathan Yu, Fri, Dec 04, 2009 at 09:55:24PM -0500 |=-
> Basically, the author of Wordpress::XMLRPC requires his own helper
> modules, which may be used in several distributions (since he produces
> many of them). However, I'm hesitant to create multiple packages for
> them because:
>
> 1. T
24 matches
Mail list logo
