ruBSD 2013 pkg talk report

[Baptiste Daroussin]

On Wed, Dec 18, 2013 at 12:13:44AM +0000, 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.

First thank you for having given that presentation and for this feedback!

> 
> 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.

Right now I would recommand to pkg lock the said package.
The other solution would be to create a home made repository and say to pkg that
the said package can only be upgraded from that repository.

The other solution would be to extend the plugin system of pkg to get plugable
repository system and create a portstree plugin that build directory the ports
to update it, and will respect pkg annotate -A repository but this depends on
the ports using pkg for dependency/conflict resolution and that will be quite
tough to do.

> 
> 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.

the useful things would be to extend imho the system to depend on symbols
being able to create smart provides (based on symbols) and smart
requires (need a libbla.so with (bla_ipv6 function) this is doable but tough as
well (any idea welcome here)

> 
> 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.

We need priorities, we do not have it yet, beside that you can use pkg annotate
-A repository to say a package can only be upgraded from a given repository.

> 
> 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.

I agree with that beside pkg will never know directly how to build from the
ports tree, but a plugin can do it. (pkg should remain package building system
agnostic)
> 
> Q: Why have you chosen SAT and not X/Y or Z?
> A: SAT provides mathematically proved basis for the whole problem and it
> is much simpler to extend some proved base than to invent the wheel
> trying to solve the specific problem.

+1
> 
> Q: Why haven't you chosen other solutions?
> A: We have 28K ports and it is literally impossible to adopt each port
> to some external system. Therefore we plan to migrate to the new world
> smoothly by adding new features to SAT algorithm.

+1
> 
> Q: It seems that all these improvements are only in development or
> projected state.
> A: Indeed, many of these features are not yet implemented.
> Unfortunately, pkg system requires more developers than there is now and
> we appreciate any help in improving pkg to make our packages system
> better :)
> 
+10000

I would like to add here that lots of things like vsevolod's sat solver are
tough to incorporate because we first need to workaround (and fix) lots of
problem in the ports tree, he has done a really fantastic work on the solver we
really need it, but to go in that direction we will need to:
1 fix
https://wiki.freebsd.org/ports/PkgNameCollisions
2 face a very complicated migration from ORIGIN to pkgname and unique identifier
internally. The choice to continue with the ports tree was a good and reasonable
choice, but it also have a huge price.

regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20131219/b3fab6ba/attachment-0001.sig>