-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 11, 2007, at 7:49 PM, Greg A. Woods wrote:

> At Wed, 11 Jul 2007 15:25:44 +0200, Joerg Sonnenberger wrote:
> Subject: Re: [HEADS UP] pkg_install pullup
>>
>> On Wed, Jul 11, 2007 at 12:47:06AM -0400, Greg A. Woods wrote:
>>> At Wed, 11 Jul 2007 01:22:47 +0200, Joerg Sonnenberger wrote:
>>> Subject: [HEADS UP] pkg_install pullup
>>>>
>>>> Already removed in the current version are:
>>>> - part of the backend to support multiple @cwd directives
>>>> - pkg_create doesn't allow require scripts any longer, support in
>>>> pkg_add and pkg_info will be removed at a later point.n
>>>
>>> That's not a good idea.  Why remove a VERY useful feature?
>>
>> Because it is redundant. The install script is called twice, once for
>> pre-install mode, once for post-install mode. If it returns
>> un-successful in the pre-install phase, the full installation is
>> stopped.
>
> No, the requirements script is NOT redundant.  (It might be used
> sometimes for some rather strange purposes in FreeBSD ports, but it is
> definitely not redundant in any way!)
>
> The install script has an entirely different purpose in the pre- 
> install
> phase.
>
> Perhaps your view has been blinded by the mass of ugly infrastructure
> inside pkgsrc which can be used to create the behemoths of ugly
> multi-purpose scripts which already vastly overload the meaning and
> purpose of the install script.  Pkgsrc is far from the only creator of
> package bundles usable by pkg_install!
>
> It is very important to have at least the minimum of separate scripts
> for separate purposes that pkg_install was designed to have.   
> Besides, a
> "+REQUIRE" script is a necessary standard component of the "pkg"  
> format
> used by pkg_install.
>
>
>>>> - pkg_create -h and -X were dropped
>>>
>>> I'm not so sure it's a good idea to remove those features either.
>>
>> The PLIST can be filtered to get the result of -X and -h seriously
>> breaks too many things to be useful.
>
> The "breaks too many things to be useful" might be true for '-h', but
> none of what you say is true of -X.
>
>
>> They are complete unused. The master/slave mode was *NEVER* used,
>> neither for pkgsrc nor for ports.
>
> Well, just because pkgsrc and ports don't use those features doesn't
> mean that they are not very useful on their own outside of pkgsrc or
> ports.  Pkgsrc and ports are not the only creators of "pkg" bundles  
> for
> their respective platforms.
So be concrete do you use it ? because if we can't find anybody who  
use these features.

>
>> The only practical area where it might
>> be helpful is installation into sub-directory (DESTDIR mode  
>> similiar to
>> installworld). That can be done much easier and will be part of the
>> commit that removes master/slave mode and drops the external tar
>> invocation. Keeping this around means a lot of useless code to  
>> convert
>> and I don't see a valid reason for such a maintainance mess. I can't
>> even test is without creating my own test suite yet.
>
> Well if NetBSD's pkg_install had been kept a proper derivative of the
> original then there wouldn't be such a maintenance mess in the first
> place -- there would be a lot more hands and eyes to do the necessary
> maintenance work.
>
> I really very strongly object to making NetBSD's pkg_install
> incompatible in any API way with FreeBSD (or OpenBSD or anyone else  
> who
> has picked up and is using pkg_install).
>
We are incompatible now AFAIK.

> I'm sure I won't be the only one to object even more strongly if
> NetBSD's pkg_install suddenly becomes incompatible with the underlying
> "pkg" format.  Perhaps you haven't done enough research yet to have
> heard of ESP and its use of the "pkg" format?
>
> If you want to design a new pkgsrc package management tool and a new
> package bundle format then fine, go ahead and do that, but PLEASE call
> it something else!  Do not pretend that you're improving pkg_install.
>
>
>> Being compatible was irrelevant for ages.
>
> Maybe for you.  Perhaps you are too focused on a homogeneous
> environment.  Such environments are still exceedingly rare in the real
> world, especially when they are composed of NetBSD hosts (or even all
> "pkgsrc" hosts).
>
>
> It is really important for you to think about the uses of pkg_install
> outside of pkgsrc.  It is critical that a modern operating system come
> with a standardized package management tool of some form.  It's
> unfortunate that the *BSDs chose the N.I.H. philosophy and rolled  
> their
> own yet again, but that's history now.  It would be really sad if  
> NetBSD
> again distanced itself even further from the pack by blowing all  
> hope of
> maintaining any compatibility with even its fellow *BSDs in this  
> matter.
>
Nobody use pkg_install outside pkgsrc. In your point of view we have  
to implement also rpm parser to pkg_install.
>
> Really the goal of the NetBSD base OS, w.r.t. pkg_install, should  
> be to
> make it possible to use FreeBSD ports on NetBSD and without having to
> replace pkg_install (or any other basic tools, such as make) in the
> process!
>
Greg I hate flame wars and I think that we have to respect  each  
other on these mailing lists. But I think that you should start some  
work :) because you are teaching Joerg how to understand pkgsrc. If  
you think that you can do it better write code!! For now I haven't  
seen here anything constructive from you.

>
> -- 
> 						Greg A. Woods
>
> H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack  
> <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>       Secrets of the Weird  
> <woods@weird.com>

Regards
- -----------------------------------------
Adam Hamsik
jabber: haad@jabber.org
icq: 249727910

Proud NetBSD user.

We program to have fun.
Even when we program for money, we want to have fun as well.
~ Yukihiro Matsumoto




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFGlUTMlIxPgX3Go0MRAok7AJ9Q0VFLC6uQovaEvXdRtnbAIIl+4ACgmXZL
LHXI2ttERJeHJSgU2s5qmoQ=
=Vjpg
-----END PGP SIGNATURE-----