tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: suggestion: Host fly-off between pkgin and nih and subsequent official integration

> Anyway this is probably moot if pkgsrc position is that users aren't
> supposed to build from source without the use of pbulk/distbb.

I cannot say for pkgsrc, so, the following is my personal position:

1. Some of your statement are true. Yes, we have to improve usability of
   pkgsrc and supporting tools.
2. pkg_rr is not smart enough yet to handle all possible issues. There
   are a number of well known problems. So, it needs to be improved.
3. Neither pbulk nor distbb are as simple in configuring as they should
   be for the end users (average admins). I don't care about pbulk but I'll
   improve distbb.
4. Users should NOT use "bmake replace" or "bmake install" and then
   complain that something doesn't work. bmake is a tool for pkgsrc
   developers, experts and kamikaze.
5. If you use pkg_rr for updates (suppose for a moment that problems
   with conflicting packages were successfully fixed) you'll babysit
   your packages if build failures happen. The same for FreeBSD
   portupgrade and FIRGET-ITS-NAME.
6. For end users much easier way for system update is to use pkgin/nih
   and binary repositories built by developers. This is true both for
   NetBSD and DragonFlyBSD. This what Joyent does for their clients.
7. pkgsrc's pkg_install has very good functionality to build wonderful
   package managers on top of it. It is definitely superior to FreeBSD's pkg_*.
   So, FreeBSD's pkgng(1) approach (all in one replacement for pkg_*)
   is irrelevant.
8. As pkgin and nih are built on top of pkg_install, they are, to some
   extent, equivalent. So, I don't see any reason to "integrate"
   to mk/. Each of them have good features. pkgsrc users have a choice.
9. pkgin in NetBSD base system is bad idea. I'd prefer to remove
   pkg_install from base and replace it with _tiny_ pkg_setup shell
   script. This was already discussed, though.
10. Adding unconditional dependencies to pkgin/nih from all packages in
   pkgsrc (like FreeBSD devs did with pkgng(1)) is extreamly stupid
   idea. No comments.
11. pkgng is a huge step forward for FreeBSD ports. Good luck to its
   developers and FreeBSD users!
12. Single tool able to do both binary and source based updates is a
  MUST HAVE. I'll work on it.
13. Maybe sqlite as database for pkgdb (/var/db/pkg) is a good idea.
14. There are some lessons other system may give us.
15. revbumps is disputable approach. Well, for bulk builds it is good
   enough but it doesn't solve ALL problems.

Best regards, Aleksey Cheusov.

Home | Main Index | Thread Index | Old Index