ruBSD 2013 pkg talk report

[Vsevolod Stakhov]

On 19/12/13 19:10, Bryan Drewery wrote:
> On 12/17/2013 6:13 PM, Vsevolod Stakhov wrote:
>> Hello,
> 
>> I'd like to summarize the feedback I've received from pkg users
>> during that event. I got many questions about ports and packages
>> and I think that questions are useful for the overall pkg
>> development.
> 
>> The most of questions were related to options and base system:
> 
>> Q: What if I have a package built from ports with some custom
>> options and a repository has newer package but with different set
>> of options? A: I proposed to skip updating such a package from
>> binary repo, but initiate its building from ports directly
>> (assuming that ports uses pkg for dependency/conflicts resolving).
>> That sounds reasonable and seems to be very convenient for an end
>> user.
> 
>> Q: What if I have a system with some build options that are not 
>> compatible with binary packages, e.g. DISABLE_IPV6. A: I think it
>> is useful to have a special metafile for each repo that describes
>> compatible systems, including not merely ABI, but a specific set of
>> non-compatible options. The alternative is to create virtual base 
>> system packages (e.g. kernel-noipv6), that may be placed in the 
>> dependencies list.
> 
>> Q: What if I have my own custom repo that has older software but
>> with my local patches. A: I suggested to assign a priority to each
>> repo and never replace packages from a high priority repo by
>> packages from low priority repo. That should fix this request.
> 
>> Q: What about portupgrade and other related tools? A: I claimed
>> that these tools are going to be deprecated and packages will be
>> managed from pkg even if you want to build a custom package from 
>> the sources.
> 
> These tools are not deprecated for port building. portupgrade and
> portmaster will live on. They are port building tools. pkg is not.
> These are only no longer intended to be used to install packages.

Well, considering that we plan to use pkg for dependencies and conflicts
resolving what's the real purpose of having 3 alternative systems of
ports management? I really have no understanding why do we want to
complicate things that are already complicated?

>From the point of view of a normal user, I may tell that everything I
want is to have an ability to manage packages and ports transparently.
Look at the macports, their user shell is perfect: you have no
difference between building software from sources and getting it from
repository. However, you can use only source packages while the default
behaviour is to choose binary packages.

I'm not talking about the current situation when pkg cannot work with
ports and source packages. But eventually we want to implement that
feature and use pkg as the only solver for both ports and binary
packages. In this situation I consider portupgrade and portmaster as a
confusing evil: a user can easily break his system by improper usage of
such tools.

-- 
Vsevolod Stakhov