ruBSD 2013 pkg talk report

Thu Dec 19 11:37:46 UTC 2013

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

On 19/12/13 11:19, Baptiste Daroussin wrote:
> On Wed, Dec 18, 2013 at 12:13:44AM +0000, Vsevolod Stakhov wrote:
>> Hello,

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

I still think that this functionality should be essential for pkg. For
example, I've built vim package with motiff, and I have no chance to
upgrade it from pkg repo. Hence, the proper choice is to let ports to
do this stuff (since we plan ports to use pkg solver for dependencies
resolution). Certainly, we should not stick to /usr/ports and make
being hardcoded, but this should be provided out of the box for FreeBSD.

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

It is very, very dangerous way to do it in this way. Remember all
those dlopen and LD_PRELOAD stuff which would definitely break
everything. From my sense, the base system and kernel should generate
virtual packages that contains specific options. Then we may deal with
them in an ordinary way.

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

See above: I think that pkg should have some abstract build system
interface with plugins to concrete ones.

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

Actually, my solver uses origins as well at the moment. So if pkgname
conversion is too though then we may try to start with the solver
merging (which is a complicated task anyway).

- -- 
Vsevolod Stakhov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSstqHAAoJEAdke2eQCBQ3RWwQAIy4+ihvEBbwusa0tDzbdCuu
/xBQV7Or+7aq90V7QRGilC4tT+QU3cfl3ux1/62IpXKc9EGct91qANXUeuPlxi3W
0inemjiLfG7+pSxOiNJinH17g0lP9o+go4xHyHzf1syb5r0YszC+47qzei8mwNGQ
uQlIyyrT2SBtYUirw64buheArPQAFEKItegpdV1Vgec+/Ss6aSJ/gtkvBMjVudm6
kxpXOWwd6AkwfYoFJOMsZ5c0nE3YmYnexUzpXMh6pv6HedT/3EcY5UBo7O+IZkuF
+FU4DKun81ro/jDpisHEl2Re8DEEhtKQ4JkHU45YvQQCsyn7cUMkf+uhOY+5Oro7
+hhr/pXsf3paY7CJtf+2V+S4nzppyE7XvWmzV5JphC/FTaT2M3cSnrhvw6oIH8KO
DAUB67srFtdg9TR6Sb9E9grH22ANKma0Jcx9hl88YJe5zVu5MeVP4991WBr6UrvO
zhybKvYuqn5N4fIfxqicrvWXnB8wIBDlcW/qfxOEGZc0Jtm7RtAsHRNPEoGym3ag
HNjzVuQKhdCOen2l13BhxvXSeRPlH5DWMPTaZrhIe1nOOS3B6HsCwiu4a31gvjtZ
VjQ4+hhQkQ0d4GZgq66/DmxjvN4uO8QEk/iB5h2TBsur1tcDJcSe2pWFT6ByUoiM
cVxvNxGwGoypUSgD8RUK
=aF+U
-----END PGP SIGNATURE-----