On Mon, Apr 12, 2010 at 9:07 AM, Leinier Cruz Salfran <salfrancl.lis...@gmail.com> wrote: > On Sun, Apr 11, 2010 at 8:34 PM, Marcin Wisnicki > <mwisnicki+free...@gmail.com> wrote: >> On Sun, 11 Apr 2010 12:37:27 +0100, Robert Watson wrote: >> >>> On Fri, 9 Apr 2010, Alexander Churanov wrote: >>> >>>> 2010/4/9 Leinier Cruz Salfran <salfrancl.lis...@gmail.com> >>>> >>>>> i want to ask you one thing: can you make the 'pkg_install' suite >>>>> reusable .. means install 'libinstall.a' as a shared object in order >>>>> to make it reusable by others devs >>>> >>>> I'd like to add my 50 cents. From my point of view, the true UNIX way >>>> is re-using whole programs. This provides unbelievable isolation and >>>> correctness. If you don't want to fork myriads of processes each >>>> second, then, it's, probably, better to ask for pipe mode of pkg_* >>>> tools. For example, aspell works that way. You start a process, write >>>> commands and queries and read results. >>> >>> While there are clearly benefits to process isolation, there are >>> countless situations in UNIX where I've said to myself "Oh, I wish I had >>> a lib<foo> not just a <foo> command". This is particularly the case for >>> monitoring tools, where third-party applications have a lot of trouble >>> parsing and tracking the output of tools like ps(1), etc. This is why >>> recently we've been working on libmemstat(3), libprocstat(3), >>> libnetstat(3), etc -- so that tools can avoid rewriting that code as >>> well as avoid the parsing problem. >> >> A middle-ground solution to this is to standardise on a common data >> exchange format with a schema definition language. With schema you can >> autogenerate high level parsers and generators, validators and other things >> for free. It does not have to be XML with XML-Schema (though there are good >> plaintext schema languages like RelaxNG-compact and you could possibly find >> less verbose text encoding for XML). >> >> If, say ps or ipfw, had a switch like '--format-output-yaml' and >> '--print-output-schema' (alternatively schema files could be stored >> somewhere in $prefix/share) it would be trivial to use them anywhere. >> >> The only problem I see is agreeing on a single format and forcing everyone >> to use it. Which is probably why it will never happen :( >> > > hello marcin > > that can be a smart solution but i prefer to use functions directly > from library .. i think it's better > > well, alexander .. i must to follow your first suggestion: use 'pkg_*' > commands (meanwhile) .. i plan to make this software usable to netbsd > and openbsd too .. i'm not sure but maybe they have the same > situation and for that reason i think use the commands is the way to > follow
Just to give you an idea of what's out there... NetBSD used the same basic solution that FreeBSD did, but they diverged about 3 years ago and they have their own library based solution. I think that OpenBSD has their own package maintenance tool written in perl. As for us, we're going the libpkg direction-ish AFAIK, but it's going to take time before we get there. In the meantime, there's also a tool named pkgin which does similar to what you describe and it's portable between pkg_install on FreeBSD and the libpkg-ish solution on NetBSD. HTH, -Garrett _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
