ap22-mod_perl2-* WTH!

[jhell]

On 06/03/2010 15:27, Philip M. Gollucci wrote:
> On 06/03/10 12:39, jhell wrote:
>>
>> I did not install a package named ap22-mod_perl2, I installed mod_perl2
>> from ports!. So when looking for this package to check its status with
>> pkg_info -g mod_perl2-\*
>>
>> I get!
>> can't find package 'mod_perl2-*' installed or in a file!
>>
>> So needless to say (ls /var/db/pkg/ |grep mod_perl) to double check
>> revealed the subject line.
>>
>> Can the person responsible for this change either back this out or come
>> up with a better solution? using PKGNAMEPREFIX along with some conjured
>> up APACHE_PKGNAMEPREFIX in ports/Mk/bsd.apache.mk does not seem like a
>> viable solution to anything common to today problems.

: No, it does solve issues and was requeste several times.  It also
: matches other ports/ tree things that do this.  At least one of which is
: that you can build mod_perl2 with both www/apache20 and www/apache22.
: You might even have half a chance of knowing which one you are
: installing too when you do a pkg_add.

In what case will this actually happen ? bot apache20 and apache22 list
each other as a CONFLICT...

If this is a case for a jail(1) type environment then were going to
start adjusting package names where these instances are few to none ?

Maybe a better compromise would be to come up with a better solution for
those few edge cases rather than adjust the package name for the many.
Maybe a define that local to only that Makefile ? that when set adjusts
the package name per the users request rather than making the assumption
that everyone is going to do this...

>> Maybe just copying the compile time options from var/db/ports/ if they
>> exist to the packaging directory would be a better idea than
>>
>> apr-ipv6-devrandom-gdbm-db42-ndbm-mysql51-pgsql84-sqlite3-1.4.2.1.3.9_1
> No, this is so CONFLICTS in Makefiles can work.  Several shared
> libraries in ports/ do this.
> 
>> machine it was compiled for i386 i486 i586 etc... etc.. etc.
> The package already goes in an /$arch/ dir so thats not so usefule.
> 
> Sorry we agree to disagree.
> 



-- 

 jhell