Re: Packaging WM themes - question
On 05/25/2001 11:41:00 AM bem5r wrote:
>> 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.)
Some would complain we've already packaged up almost every DFSG tar.gz file
on the internet. Thus we've already done that effort.
>> 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.
Don't forget the ever important copyright file. Notice what you're
suggesting essentially creating a deb file, but storing only the .diff and
placing the source off the main servers.
>> 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
Lets say I make a "tarpackage" of some GPLed historical ENIAC progam. If
you interpret the ".diff"/"tarpackage" as a patch to GPLed data, doesn't
that mean Debian has to provide "source code" for the GPLed software? OK,
this is a lame arguement.
>> case cited by Ben, which started this thread, we can mirror the data
>> ourselves, if necessary.)
If we're going to essentially make a .deb out it, including mirroring it,
but stick it in a .tgz instead, why mess around with alternative formats,
just make it a .deb! Your comment above does not exactly help your
argument...
>> 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
False. It's easy to maintain the source archives and binary archives at
Debian (OK, no easy, but our admins do such a good job they make it look
easy).
It's always harder to coordinate pointers to offsite data. Look at all the
web pages with broken links.
>> 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
Instead, she would use the new tool to download the data, package it (in
.tardeb format), announce the new package, upload the (.tardeb or .diff)
package.
Nothing changes, not the procedure, not the effort required, except the
file format.
>> perhaps other information). After that, the developer is done. The
Until the link changes necessitating a new upload, or the distributed file
format changes requiring different dependancies.
>> 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.
No, it's a good discussion, the point of which is that the design of the
"data" section needs alot more work than just recreating the ".deb" system
with a new name and source files reachable via a non-debian URL.
Reply to: