Re: Google Summer of Code student application

[Kamil Rytarowski <n54%gmx.com@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07.03.2016 14:37, youri wrote:
> Hi all,
> 
> I'm a student starting a masters degree in computer science next
> year and wish to participate in Google Summer of Code 2016.
> 
> My main focus is software packaging with pkgsrc: I maintain 76
> packages including the Xfce4 desktop. I also enjoy programming,
> especially C. So, I wish to work on the 'pkgin improvements'
> project:
> 
> https://wiki.netbsd.org/projects/project/pkgin_improve/
> 
> I'm familiar with the NetBSD way of doing things and I have
> already contributed some code to pkgin and have worked with the
> current pkgin maintainers iMil and jperkin before when submitting
> PRs. My interests are making multi-repository more solid and
> improve usability as well as robustness and closing bug reports and
> pull requests to aid maintenance. I also wish to add a script in
> src to bootstrap pkgin after NetBSD installation rather than having
> to install explicitly from sysinst.
> 
> The project will be a good way for me to learn some more
> programming and to improve pkgin, a tool that many people use
> accross many different platforms. In my opinion, it is vital that
> pkgin gets more robust and more user friendly.
> 
> 
> Cheers,
> 
> Youri Mouton
> 

Sounds good.

Please let me cite the quest and embed my comments:


pkgin is aimed at being an apt-/yum-like tool for managing pkgsrc
binary packages. It relies on pkg_summary(5) for installation, removal
and upgrade of packages and associated dependencies, using a remote
repository.

While pkgin is now widely used and seems to handle packages
installation, upgrade and removal correctly, there's room for
improvement. In particular:

Main quest

    Support for multi-repository
    Speed-up installed packages database calculation
    Speed-up local vs remote packages matching
    Implement an automated-test system
    Handle conflicting situations (MySQL conflicting with MySQL...)
[(kamil) I recommend for the above steps to pickup libsolv and adapt
for pkgin. It was developed by openSUSE RPM team (notably by the
author of screen(1)) and adapted for several tools, iianm finally
adopted by Red Hat. It has compatible BSD license and uses
public-domain algorithms.]
    Better logging for installed / removed / warnings / errors
[(kamil) I recall the same ideas in the RPM world and it was torn down
due the fact that yum/zypper and other might know nothing about
low-level rpm(1) usage (for us operations via pkg_add(1) or
pkg_delete(1) are equivalent). Currently the pkgin database without
prior "up" might have problems with database consistency. I guess
there might be need to abstract common library part for pkg_add(1) and
pkgin(1) and do logging there.]


To be confirmed / discussed:

    Make pkgin independent from pkg_install binaries, use pkg_install
libraries or abstract them

Bonus I

In order to ease pkgin's integration with third party tools, it would
be useful to split it into a library (libpkgin) providing all methods
needed to manipulate packages, i.e., all pkgin's runtime capabilities
and flags.

[(kamil) Sounds good]

Bonus II (operation "burn the troll")

It would be a very nice addition to abstract SQLite backend so pkgin
could be plugged to any database system. A proof of concept using bdb
or cdb would fulfill the task.

[(kamil) What are end-user gains here? In the RPM world BDB was
problematic and for example poldek was using the Berkeley database
directly, not through the RPM interfaces. cdb(1) might be fancy...
however in case of troubles and debugging more people are familiar
with SQL queries than yet another pbinary] format with new set of
utilities.]

Useful steps:

    Understand pkgsrc
    Understand pkg_summary(5)'s logic
    Understand SQLite integration
    Understand pkgin's `impact.c' logic

[(kamil) Comments:
1. For full updatability I recommend to research OBSOLETES/REPLACES in
pkgsrc to track renames. Currently I'm forced to rm(1) all packages
and reinstall from scratch all packages, as alternative ways of doing
it fail for me. It works well and it's handled by libsolv use-case
scenarios.
2. I would like to see more divergence between pkg_add(1) and
pkgin(1), in terms of code-sharing (common library in backend?), while
I'm favor of low-level tool (like pkg_add(1)) to operate over packages
and keep repository of installed packages integral and high-level with
capability to track dependencies and remote repositories.
3. It's worth to research better integration with NetBSD install media
possibly replacing pkg_add there. Whether we want to maintain pkgin
inside pkgsrc, how/whether to upgrade pkgin in NetBSD's base with the
one from pkgsrc etc.]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW3e7gAAoJEEuzCOmwLnZsHB0P/RRbo7lG0AI6x4LYssG04lst
WhjSXpXjGb8HNcsgRFX8syfLHdfJqEbEdumpYDALlK1LvIkchQvv+utK6Orjt0jf
KLOfN1zbH0F8qVfeI3vDHAiXWcS4IMHcMfnuw0ONIDngP9B+Dt661C0htgoUbG+l
oAuZs8W6CU/liML5YtvECyZUVVwdK+gbxkoJBzBjWvNRdadQ8yB55N4H8zuVbIS3
FnMgT6DU0UVTWp0dWpGKrjNPAK4ijyAGDgbbxIrV0x50xzRWzIMokP4WXstkO131
fcB9PDoQq460V4L1M/mu6TMyFY5Unr969FYgdRhlU/lqxVa9ZLRshqVcw+tW0lTT
Tofb3YmgrEccV6XJwqfL/UzwlkK4ppza7aCTPW4gAoXzWf4fpP3vcr3lcuN4VVwu
/VRmqVqVhKb4SdJFpPnnEKjMqrTBss7SgZKdi0rjZJbyA6l7Fiz7lqP8NS02G7Ge
gPxuzZ9LPD4pHjrbuZ9fBBxeqoHY2MHe7ZNsJxloRp40QSo/QtyN+ssWmyLv9YqC
odpfViks0Ikr39qaw/EuosaJ2tMEH2LA3wWAQZrlJbO62Dvtu9wLSc/lECiY7Zdl
6RlqlnpZ3ki6cGc5cFI42eiAz5mkL/TbOq44Hut1neXWzN5vEfDLu6B0bfgyRouD
MPDF7FtbbPpu3UT8Ghl7
=HKOU
-----END PGP SIGNATURE-----