pkgsrc-WIP-discuss archive

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

Re: CVS commit: wip/awk-pkgsrc-dewey



I hope wip-discuss is good for this answer.

 >> Based on wip/awk-pkgsrc-dewey and wip/runawk
 >> I have a plan to develop more tools for managing packages.
 >> What's wrong? What you worry about?

> No problem, I was just curious about the long term plans for this.

Long term plans? Easy.

1) Yet another package manager :-)

  a) pkg_chk has too much things/functions for one executable.
     I'd like to see it more modular.
  b) pkg_chk -s is just tooooooooo slow.
     This is because it slowely scan pkgsrc tree.
  c) pkg_chk -b is slow too.
     Neither -s -b use pkg_summary.
  d) I didn't use pkgmanager much but I don't think lisp
     is for this sort of tasks. BTW it has some problems
     with portability.
     Though, I speak lisp _a_little_ (textproc/dictem)

   Goals:
     - should work with pkg_summary.gz in binary upgrade mode.
     - should use pkg_src_summary.txt for source-based upgrade.
     - should work with multiple repositories, for example,
       ftp://ftp.netbsd.org/... and local repository for wip packages.
       Ideally users should be allowed to set "preferences", i.e.
       what thing should be installed from what repository,
       what packages must NOT be upgraded etc.
     - should call user settable external executable for building
       binaries (pkg_comp, pbulk, bulk framework or anything else).
     - user settable program for fetching packages and summary.
     - optional local cache for binary packages.
     - clean code.
     - no GUI :-)

   Implementation notes:
     - portable shell and awk only. They are enough (As always :-) ? )
     - wip/pkg_cmp_summary for comparing.
     - wip/pkg_src_update_summary for source-based upgrades.
     - wip/pkg_update_summary for optionally updating binary pkg_summary.
     - wip/awk-pkgsrc-dewey for handling dependancies/conflicts/
       future supersedes ;-) etc.
     - wip/pipestatus for running pipes safely.
2) yet another bulk build framework

   a) pbulk was just badly designed. Too much code written in C.
      There is no reason for this project to use C at all.
   b) pbulk has criptic logs. They are much worse than that of
      Hubert's bulk build framework.
   c) I disagree with pbulk's author how my bulk build should
      work in general.

   Goals:
     - better logging
     - faster scanning
     - clean code

   Implementation notes:
     - portable shell and awk only.
     - wip/paexec - for parallizing. I wrote this small tool months ago
       for my work.
     - optional pkg_src_micro_summary and pkg_src_update_summary
       for faster scanning.
     - wip/awk-pkgsrc-dewey for handling dependancies.
     - wip/pipestatus for running pipes safely.

> Even if the programs have different use they can still be bundled
> to ease maintenance burden. For example, we don't have separate packages
> for pkg_add and pkg_info.
pkg_src_summary, pkg_update_summary, pkg_src_update_summary and
pkg_cmp_summary can be united to single package but I don't know
how to name it :-)

-- 
Best regards, Aleksey Cheusov.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
pkgsrc-wip-discuss mailing list
pkgsrc-wip-discuss%lists.sourceforge.net@localhost
https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-discuss




Home | Main Index | Thread Index | Old Index