Re: Packaging WM themes - question
I'll put my summary at the top and bottom of this email... I want "debian
data packages" to be real packages that deeply integrate with Debian, not
simply run a ".zip to .deb format converter" on textfiles.com, and/or a
simple mirror of textfiles.com. A .deb of a binary is more than a renamed
".tar.gz" and thats what I want from a .deb of a data file. Nothing deeply
integrates with a binary .deb based Debian system better than another .deb
based package, data or binary....
On 05/25/2001 01:12:50 PM bemays wrote:
>> > 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.
I concede, you are correct. I suppose all of CPAN is not packaged either,
as another example.
>> 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.
Regarding the double hit on disk space, "simply" change the system to not
create errors on a "data" section package if no .orig.tar.gz is uploaded,
or working the "opposite" way, don't allow .debs in "data" section, only
.orig and .diff (and .dsc I suppose)
>> > >> 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.
I would still push for filing the metadata where the copyright of the data
itself lies. I like the idea that if I install a debian box using only
stable/main I can guarantee that there are no license encumberances on the
machine of any sort, its all DFSG.
I use the term ".diff" to stand for whatever you call any modifications to
the data, including the addition of metadata, and ".deb" to stand for
whatever you call the thing you upload that provides the metadata to
Debian.
>> > >> 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.
I concede this point, like I originally said, it was 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...
>>
>> There is no deb. We mirror the tar.gz file. That's all.
Typically a binary program will have a source and a diff full of metadata
(control file, copyright file, ...) and a .deb that is ready to install.
Your mirroring the source and a diff/metadata/whatever you call it, is not
much different.
If you mirror the tar.gz, you are storing an equivalent set of data
(admittedly, with an extra source file) but in a different format.
I'm not sure replicating the procedures and tools for .deb would be easier
than a "simple" patch to the .deb system that merely does not require an
.orig file for a package in section "data". Or work it the other way, if a
package is in section "data" do not allow a .deb file to exist, make the
user download the .orig and .diff and the user has to "compile" it (not
much effort to compile a text file.
>> > >> 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).
How are you proposing to fix the metadata? You still have to download the
old metadata, change the link, and upload the new metadata.
The closest comparison I can think of is a .deb of a binary changing it's
upstream URL. You'd apt-get source package, dch, change the URL, debuild,
dupload. In comparison to your system where you'd "download metadata",
change the URL, "upload the metadata". Same tasks, fetch it, fix it,
distribute it.
OK, you win, kind of, with your system you don't have to run the dreaded
dch and debuild, but thats not much of a win.
>> > >> 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.
You'd be building a set of metadata that is appropriate for the raw data,
like URLs, copyrights, dependancies, control files. You'd be uploading
the metadata into the debian system somehow so debianites can use it.
I interpret your position as the metadata should be contained in a new and
separate system from the one we use for binaries. I'm arguing that the
system we use to store binary metadata would work well enough for "raw
data", and could be much more efficient with some really minor
modifications...
The decision of make a tiny change to the present infrastructure, or create
a near duplicate of our current infrastructure with different names for the
same concepts and procedures.
>> > >> 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.
So, you want netscape to download and decompress a file when you click on a
URL? You can do that with no modifications. Add a mime type and a handler
for it, maybe.
I would prefer a method of integrating the data deeply into the Debian
system. Dependancies on other data files, Dependancies on binary packages.
Copyright files. Man and info pages describing data formats, describing
each individual data file. Control files with useful sections for the
data. Conformance to the filesystems directory structure. Management of
data sets using the fancy .deb tools instead of ftp and tar. Tracking of
bugs (everything from faulty data to typos to copyright violations) in the
BTS. Data viewers and data manipulators added to the menu system. Debconf
ability to run a translator on the raw data (tar.gz is a .sgml and you want
a .txt generated, debconf to the rescue!). For data like satellite, tides,
and astronomical data, use logrotate on the data. Automatic updates of
data and "living documents" using apt-get (install debian weekly news once,
read the latest in your MOTD forever). Add mime types and mime handlers
when an unusual data format is installed. I want an icon for the new mime
type registered with kde and gnome, if they are installed. Add entries or
a whole nother dictionary to the dict system if necessary. Locales support
for translations. Additions (if any required) to config files of other
programs (extensions to emacs to read those data files). Symbolic links of
appropriate graphics into the backgrounds directories of kde and gnome if
installed.
In summary, I want "debian data packages" to be real packages that deeply
integrate with Debian, not simply run a ".zip to .deb format converter" on
textfiles.com, and/or a simple mirror of textfiles.com. A .deb of a binary
is more than a renamed ".tar.gz" and thats what I want from a .deb of a
data file. Nothing deeply integrates with a binary .deb based Debian
system better than another .deb based package, data or binary....
Reply to: