On Tue, Dec 06, 2005 at 05:24:19PM +0100, Hubert Feyrer wrote:
> On Tue, 6 Dec 2005, Dieter Baron wrote:
> >>I see... is the format of this file documented somehow?
> >
> > It's simply lines of the format
> >	category/directory:packagename-version
> >which is the format used internally by pkg_chk.
> 
> First, that does not answer the question about documentation (see "others 
> may use the file, too").

  Which I answered at the end of my mail, right after ``others may use
the file, too''.  Thank you for reading my mail fully before replying.

> What is the "directory" here - the same as the pkg's directory in pkgsrc, 
> as in pkgsrc/category/directory? Makes me wonder why that is needed, as 
> it's not used in the dependency system (and neither is the category).
> 
> I wonder why this can't be generated on demand, e.g. by running "ls -lR" 
> or so, see pkg_install, which does not require the burden of maintaining 
> such a file.

  category/directory is where the package lives in pkgsrc.  pkg_chk
needs this information when compling from source, which it also
supports.

> >>ISTR there used to be a "make index" which created something similar that
> >>was (is?) used on FreeBSD for package downloads by their installer.
> >>
> >>Having only one such file around may make things a lot easier, and given
> >>that iMil's working on a very similar feature, working with him on the
> >>format of that file would probably be good.
> >
> > Indeed, as would be working with Jeremy's index generation.  But
> >that takes time, and this patch works *now*.  I would like to have
> >that feature in the 2005Q4 branch.  We can always migrate pkg_chk to
> >use the common format once it is fixed.
> >
> >>As well as (of course) documenting its existance and format for future
> >>tools, which will likely pop up and use that file.
> >
> > It is rather pkg_chk specific.  For future tools, using Jeremy's
> >file format is probably better.  Documenting the file's format and
> >name in the pkg_chk man page is a good idea, though.
> 
> If you already know that there's a better alternative, it may be good to 
> go that way...

  Which I intend to do.  But hashing out all the issues of such a file
format takes time, and this patch works now.  What is the benefit of
denying our users this feature, which has even been requested, for an
undefined period of time?  When the better file format is finished, we
can migrate pkg_chk to use it.  We won't even have to provide
backwards compatibility, we can tell users to recreate the summary
with the new tool.  If you wish, I will note that the curent file
format and the way to create the summary are likely to change in the
future.

					yours,
					dillo