bin/77082: src/usr.sbin/pkg_install - Add 3 new macros to clean
pkg-plist
Florent Thoumie
flz at xbsd.org
Fri Feb 4 11:20:25 PST 2005
The following reply was made to PR bin/77082; it has been noted by GNATS.
From: Florent Thoumie <flz at xbsd.org>
To: Brooks Davis <brooks at one-eyed-alien.net>
Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-bugs at freebsd.org,
hq at freebsd.org
Subject: Re: bin/77082: src/usr.sbin/pkg_install - Add 3 new macros to clean
pkg-plist
Date: Fri, 04 Feb 2005 20:13:06 +0100
Brooks Davis wrote:
> On Fri, Feb 04, 2005 at 07:41:29PM +0100, Florent Thoumie wrote:
>
>>Brooks Davis wrote:
>>
>>
>>>It seems like dirrmtry should take an optional message to emit if the
>>>event that the directory can not be delete. That way the user can be
>>>informed that the directory should be removed if they are really done
>>>using the port.
>>
>> I asked myself if I should put this feature in my patch and
>> I finally haven't because it required some extra-stuff
>> (handling optional arguments for @ commands is painful), and a
>> simple '@unexec [ -d ${PREFIX}/etc ] && echo ...' is easier I
>> guess. But that's no problem for me to include that if everybody
>> thinks it worth it.
>
>
> Given this workaround, it's probably not a high priority to add this.
> Hmm, what about a seperate @echoifexists or similar command?
I have nothing against that. The command above sounded really
simple to me that it wouldn't need a separate @ command. But
why not.
>>>Have you thought about how to solve the boot strapping problems with
>>>pkg_install/pkg_delete?
>>
>> I have absolutely no idea what you're talking about, I started
>> looking at pkg_install source yesterday at night. Could you
>> give me some pointers about that ?
>
>
> The issue is that you need to find a way to keep users from installing
> packages they can't uninstall. If you add new commands and they are
> used in ports, users with older systems won't have the necessicary
> pkg_delete commands to make them work. The current system doens't even
> give a graceful way of detecting this condition both in the port and
> when the users installs a pkg from the -stable collections online.
> Longer term, we need some versioning in the plist and ports, but first
> we've got to solve the problem we're stuck with now.
Ok, what you meant is now clearer to me. I have no good idea of
how this exactly works but IIRC i've seen sysutils/pkg_install
whose job must be to "solve" this problem. I think we have kind
of version, with packing list format version. I need to dig into
this. I've only seen a little part of pkg_install actually.
>>>Our nominal pkg_install maintainer is MIA at the moment.
>>
>> Ok, actually I knew eik has been working on it, but I didn't
>> know who was the active maintainer now.
>
>
> Last I heard, eik was the one working it, but no one has heard from him
> in a while. He's been gone long enough that someone else could
> certaintly commit to pkg_install given public review.
>
>
>> I have thought of a new purge command, that would act like
>> dpkg --purge on Debian but AFAIK that would be impossible
>> since it would need persistent package records (that still
>> exists after a package has been removed as long as we have
>> some configuration files for this port in the tree).
>
>
> This would be a really cool feature. Off hand, you'd probably want to
> create another dirctory under /var/db to store these records. That
> would certaintly be allowed to support such a feature.
I just wanted to add @conf feature because ports lacks some
guidelines concerning how to handle configuration, where to
put sample, and I needed that support in pkg_install before
I can write my patch for bsd.port.mk.
I'm quite interested in pkg_install, I think there could be
a lot of interesting things to add. I'll probably try to add
such a purge command later.
--
Florent Thoumie
flz at xbsd.org
More information about the freebsd-bugs
mailing list