what next for the pkg_install rewrite
bapt at freebsd.org
Fri Aug 20 08:50:20 UTC 2010
I agree having a packaging@ mailing list would help to discuss about
We need to summarize the ideas of each one, then discuss about it. Only then
we can specified what needs to be done and how (keeping in mind that we need
to keep compatibility at least as a fallback or directly). when that part of the
work is done we could be able to propose the statement to portmgr for them to
validate and to update the ports policy if needed (hopefully they would have
taken part in the discussion so the validation should be formal)
If everyone agree with the following:
What I propose to do is to let the discussion going on for the next couple of
days (or moredepending on the activity on this thread) and then write down all
that has been proposed (pro, con) then we should be able to start the
specification for pkg_install next generation :)
I propose myself as someone has to do the job, but if you think you or other are
better suited for the job go ahead propose yourself or name the one you want to
back to the subject.
I personnaly believe that pkg_install needs a complete rewrite. we have strong
basis, libarchive, the GSoC code: libpkg, pkg_complete and many more (pkg_patch)
(sorry if I forgot some).
The new specifications has to be validated by portmgr at the begining of the
project and the code should repect that specifications: once we have all
accepted what would become the new pkg_install we won't add features or
behaviour that are not in the specification until the release and integration in
We need to centralized the code in the same place with the same scm (I would
love if we could avoid p4 :)) ideas are welcomed :)
We need to keep the compatiblity (as much as possible) with the existing
pkg_install, through wrappers, scripts, or fallback code.
The Plist has to be reworked: a new clean format which represents the new
features that ports provide
I also agree that pkgname and version should be separated
A new policy on package names should be written to prevent the apr case or at
least internally the package origin should be used to identify the packages.
perhaps we could keep the informations on the build options within the metadatas
Package should know which architecture they are made for : i386, amd64, noarch,
It would allow to prevent rebuilding of cross plateform package on clusters, it
would allow to prevent being able to install sparc64 package on i386?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20100820/b55a1cf8/attachment.pgp
More information about the freebsd-ports