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.)
vlm@norlight.com (Vince Mulhollon) replied:
> Some would complain we've already packaged up almost every DFSG tar.gz
> file on the internet. Thus we've already done that effort.
Hardly. All I need to do is go to netlib to see how much stuff is out
there that we haven't touched. We have packaged a lot of stuff and,
arguably, the most important stuff, but I doubt that we have packaged
most of the stuff, much less almost all of it.
Besides, just because something is packaged doesn't mean that all of
the effort has already been spent. Effort is still needed to maintain
these packages. Disk space is still required to store them. In fact,
for packages of pure "data" (which is what I'm talking about), double
the amount of disk space is required, since it is stored once in an
orig.tar.gz file and then an almost identical copy is stored in a deb
file.
> >> To improve this system, we in Debian could provide the
> >> meta-information for much of this data separately. ...
>
> 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.
No deb file is created. No diff file is used. Some form of copyright
information should be provided in the meta-information (so as to
inform the user of his or her rights), but the copyright does not
affect the meta-information any more than the copyright of a book
affects its reference in a library's card catalog.
> >> 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.
No. You misunderstand. This is *not* for programs. This is not for
anything that will need to be patched. This is for data that can be
downloaded, untarred, and used as is. Programs should be packaged in
deb files, using our current system.
> >> 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...
There is no deb. We mirror the tar.gz file. That's all.
> >> 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.
Hmm ... when something changes is it easier to (1) download, rebuild,
upload; or (2) change a link. In my opinion, it requires less work to
do (2).
> >> 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.
Did you even read my proposal? Nobody is building or uploading
anything.
> >> 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.
That is not what I proposed. My proposal is for a tool which downloads
a tar.gz of data and installs it directly onto the system. No deb is
created. There is no diff file.
- Brian
Reply to: