FreeBSD.org intrusion announced November 17th 2012

PKGNG is meant as a complete replacement for the old pkg_* tools with some additional functionalities but it's not meant to replace ports-mgmt/portmaster or anything similar because it does not know how to build ports.
 
UNIXgod said:
Was pkgng supposed to replace the pkg_* system? or just supplement it like port(upgrade|master) are for the ports system?

Though I could see that for embedded systems it would be nice to have something like pkgng only as then one wouldn't need a separated system for administration and building. But that's what nanobsd is for.

Finally as for application development as time goes on seamless options could be created for the so called model/view/controller style development. In the case for needing a database for model being compatible with a filesystem style database like /var/db/pkg would be simple enough for pretty much anything. Non flatfile simulated rdbms unlike sqlite could be used as well for large buildsystems where concurrency may be an issues (i.e. postgresql, mysql, nosql?) ... since the command is the controller unless c hooks are exposed it's open source so anyone could build it into another application if desired... Finally for the view what is most important is the console which we already have. This could easily be brought into a 4th generation web front-end for giving access to clients who pay for such things. The gui would have been another suggestion but we aren't on ubuntu and for the current market of automation outside of browser won't be on which gfx framework anymore.

tl;dr
Unless sqlite can provide something over structuring like /var/db/pkg does or a variation of the theme pkgng should be modular and the dependency should be optional to the user to decide.
(Disclaimer: I haven't used pkgng yet... If I'm completely overstepping my boundaries here by assuming how the pkgng package manager works please educate an inform me)
Click to expand...

I've echoed your concerns about the deprecation of a flat-file package registry (each directory in
effect a database of its installed port, no front-end library required, easy access via command-line
tools, pipes)... in posts to the freebsd-ports lists, freebsd-current list, and in threads here,
including real-world examples (shell tab completion into the flat-file structure ..) but AFAIK there
are more persons interested in the new default than there are persons sharing any concerns I may have
about it, at least those who have posted about it.
Maybe the other posts I've made (besides this one) discuss it with greater detail.
 
jb_fvwm2 said:
I've echoed your concerns about the deprecation of a flat-file package registry (each directory in
effect a database of its installed port, no front-end library required, easy access via command-line
tools, pipes)... in posts to the freebsd-ports lists, freebsd-current list, and in threads here,
including real-world examples (shell tab completion into the flat-file structure ..) but AFAIK there
are more persons interested in the new default than there are persons sharing any concerns I may have
about it, at least those who have posted about it.
Maybe the other posts I've made (besides this one) discuss it with greater detail.
Click to expand...

Oh wow. Then I am not misinformed. Does the pkgng author/maintainer have an interest in following the `UNIX Philosophy` approach making pkgng an actual drop in replacement to pkg_* system? Even if it's for backward compatibility for third party ports or services that have scripted against pkg_* and the current package registry system.
 
There's always the other way of looking at it and that's treating the pkg database (be it flat files or sqlite) a "black box", you're not supposed to know how it works inside. All you know is the published API and trust that the API remains compatible trough the updates.

For me the essence of UNIX way of doing things has always been "do one thing and do it well", in my opinion abstractions and data hiding are not in conflict with this philosophy.
 
To counterpoint, "many ways of doing things, since this is unix not ..." ( I read a post which postulated that putting all the program parameters in the registry (windows) is a
shortsighted method of implementing something rc.d-like. ... I often think of that analogy when pondering this issue.)
 
You must log in or register to reply here.
Back
Top