Re: Packaging WM themes - question
> On 25-May-01, 09:37 (CDT), Brian Mays <brian@debian.org> wrote:
> > > Ben: It might make sense to split it into 2 or 3 packages but
> > > certainly not more.
> >
> > I agree. Consider the following when making these decisions:
> >
> > (1) Does the entire set of software come from one source?
> >
> > (2) Is the entire upstream source packaged and updated together?
> >
> > (3) Does everything work together or provide the same utility or
> > service?
Steve Greenland <stevegr@debian.org> added:
> (4) Should they be packaged at all? Does packaging these themes
> actually provide any more functionality than downloading and unpacking
> a tar.gz (or whatever the format is) file in the appropriate location?
A very good point. For years, I have advocated some sort of data
management tool for handling bundles of pure data. (This issue first
came up when we were discussing the packaging of various on-line Linux
periodicals for Debian.) I still think that such a tool is a good idea.
This tool, which could perhaps be built into dpkg, would manage
data packaged in generic tar balls. It would unpack them under an
appropriate directory of the filesystem (reserved for such data) and
catalog their contents. Since it uses the most common and generic
package format (namely, tar.gz), it can easily manage material from
outside of Debian, thereby, drastically extending the scope of our
packaging system without much effort on our part. (Consider how much
effort would be required to build Debian packages of all or most of the
data available on the internet in tar.gz files.)
To improve this system, we in Debian could provide the meta-information
for much of this data separately. I suggest that it should go into some
form of central database for the project. This meta-information would
most likely include the location of the data on the internet (via a URL)
and a description, but it could also include additional information:
what to do with the data once it has been installed, what additional
configuration is required by a Debian system to use the data, how to add
appropriate symlinks within the filesystem to the data, dependencies on
Debian packages, etc.
My proposed scheme has a couple of advantages over building the data
into conventional Debian packages. As already mentioned, a tool for
managing generic tar balls provides us with an excellent opportunity
to leverage the vast amount of data that already is available on the
internet. Because we can make use of what is already being provided by
others, we do not need to spend our resources providing another copy of
the same thing. (In the case of difficult to reach data, such as the
case cited by Ben, which started this thread, we can mirror the data
ourselves, if necessary.)
Another advantage of the tool proposed here, is that the
meta-information is collected and maintained in one place (one database)
rather than being spread across several hundred packages. This will
make it easier to maintain this information. Therefore, when a Debian
developer comes across a useful piece of data, which he or she thinks
would be an asset for Debian, he or she no longer would need to download
the data, package it, announce the new package to the mailing lists,
and upload the package. Instead, he or she would use the new tool to
provide a description of the data and its location on the internet (and
perhaps other information). After that, the developer is done. The
tool contacts the central database located on one of our servers and
adds a new record. The change is propagated to all Debian systems,
and all Debian users can now get the data as easily as downloading and
installing a new package.
The one problem with my proposal is that nobody will implement it. I
certainly do not have the time to develop the tool, and since this
scheme has been proposed before without any results, I believe that all
of my words have been posted for nothing.
I would like to end my message with a plea to any developer out there
with the time to package large data sets for Debian. Instead of
spending your time on this task, please consider working to develop the
tool proposed here, so that building such packages becomes unnecessary
in the future.
- Brian
Reply to: