tech-pkg archive

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

Re: pkg_add and remote packages



Dieter Baron wrote:
In article <47F68F28.7060006%pkgsrc.org@localhost> Johnny wrote:
: For comparison, I offer the the experiences I've recently had with : Rubygems installation and distribution. All gem repositories have a : standard format.

:      http://gems.foo.org/gems/  gems directory
:      http://gems.foo.org/yaml   YAML description of available gems

: If you ask the "gem" tool to install a particular remote gem by name : *and* version, then it grabs it directly from the gems directory. : Otherwise, it grabs the YAML file to see what gems are available and : which match the name given and offers the user the choice of different : version to install.

  That's nice, but the problem Joerg ran into also happens for single
package installs with specified version: finding out about missing
dependencies.  How does ruby gems handle that?

The YAML file includes all of the dependency information for each gem, so you can determine what's needed without needing to fetch or inspect the gem itself. I feel this is the right thing to do in pkg_summary if we don't already do this.

: This standard format for the repositories is good -- in fact, : practically any installed set of gems on your own system can be used : directly as a gem repository for other users. The YAML file referenced : here corresponds to the pkg_summary file you mentioned, and I think it's : a good idea to require that it be generated for remote package : repositories. Is it possible to make the summary file easy to generate?
  It is:
    $ (for n in *.tgz; do pkg_info -X "$n"; done) | gzip -9 > pkg_summary.gz

: Perhaps a binary package should consist of two files in the package : directory:

:         packages/foo-1.0.tar.gz
:         packages/foo-1.0.pkg_summary

: These two files can be generated automatically by "make package". Then : to create the "global" pkg_summary file, you just concatentate all of : the *.pkg_summary files together.

  Hm, that would make it easier to update pkg_summary.  And it would
eliminate the need to download the whole thing for just installing one
package: download the *.pkg_summary file and you have the list of
dependecies.

  However, it would clutter up the package repository significantly.
I'm undecided wether I think it's worthwhile.

It would double the number of files in the repository. Still, it's worth considering if it makes remote repositories more useful. We could install the *.pkg_summary files into a parallel directory, e.g. packages/summaries/foo-1.0 if that's any better.

: The *.pkg_summary files should also : be something that can be generated from data within the .tar.gz file in : case it's not present so that a package repository admin can run a tool : to create the missing *.pkg_summary files.

  That was one of the basic design criteria for pkg_summary.

Yes, I see that now. If it's as simple as running "pkg_info -X" on a binary package to get the summary info, that's equivalent to running "gem spec" on a gem to extract the same information.

: As for caching the fetched binary packages, perhaps we should just cache : them directly under ${PKG_DBDIR}, e.g. /var/pkg/packages/.

  Yes, that's what I meant.  But that caching should be optional,
since fetching across a local network is common enough.

I think we agree on this point.

        Cheers,

        -- Johnny C. Lam


Home | Main Index | Thread Index | Old Index