> The benefits are great because the quality of the packages remains high.
Irregardless of the package quality, the software itself, able to execute, load libraries, and run, or the dataset itself, confers great benefits to anyone who specifically requires those capabilities the software provides, hence justifying the original sub-optimal, satisficing, online, approximate, expedient project of generating rough quality packages. The user, having been enabled to solve whatever problem through the use of the software, made possible by its packaging, is now immediately able to progress onto dependent tasks. If thought of in terms of formal systems, (programs as proofs), the addition of the new software entails an infinite set of hitherto impossible deductions, as well as a super-recursive proof speed-up, such that no recursive function bounds the reductions in the length of deductions. As the sheer practical availability of large and complex software systems contributes the greatest improvements and constitutes a decisive factor in consideration of methods of improving the capabilities of software systems (given the extent of unpackaged software), I would be happy if people were to take my proposal seriously and consider collaborating on the implementations. I am only taking this approach because, considering all the tasks to which I might apply myself, it appears to yield the most gain while being notably underrepresented (as there remain many notorious instances of software that is not "practically available" (available as a working but not necessarily Debian QA compliant package)). As the justification of the project is esoteric, and the results significant, I am obliged to continue to be a persistent advocate. Merely packaging the software is not sufficient. The capabilities must be formalized and question answering software set up. Fortunately, existing (yet to be packaged) systems provide these capabilities. The FRDCSA project (despite some of the more immediately humanitarian projects) consists of a large database of requirements and solutions that augment the sheer "practical availability" with consequent capabilities such as the efficient matching of problems to solutions. As a practical example of this, once the packages are made, we will subject the documentation to automated analysis using state-of-the-art Question Answering systems (a reimplementation of LCC's Groundhog). The website http://frdcsa.onshore.net/frdcsa lists many of the additional requirements. 'as (e10, x1)', 'practical (x1)', 'example (x1)', 'of (x1, x2)', 'this (x2)', 'once (e9)', 'package (x3)', 'be (e8, x3, e9)', 'make (e9, x3)', 'we (x4)', 'subject (e10, x4, x5)', 'documentation (x5)', 'to (x5, x6)', 'automate (e11, x6)', 'analysis (x6)', 'use (e12, x6, x7)', 'Question (x7)', 'Answering (x7)', 'system (x7)' Please feel free to contact me, especially if you are interested in this project or if I am in breech of list etiquette. Sincerely, Andrew Dougherty P.S. This project is not limited to packaging AI or AI-related systems only, but to all software systems. > On Sun, 2008-01-06 at 11:41 -0600, Andrew Dougherty wrote: > > The issue of "automatic packaging" is IMHO a red-herring. Even if the > > rough packages are done completely by hand, the problem remains that > > there is a lot of useful, properly licensed software for which no > > package exists. Consequently, the software has not been mapped to the > > FHS properly, it is more difficult to develop additional software > > which depends upon it, it is more difficult for any user to install > > the software, etc. The benefits of packaging are great. It promotes > > code reuse, and also makes it easier to discover functionality. > > The benefits are great because the quality of the packages remains high. Disagreed as above. > The quality only remains high when packages have maintainers with the > time to keep the packages in line with other developments within Debian. > This package set will not be used in isolation - all component packages > must function alongside the rest of Debian and they must also function > as individual packages - e.g. where only a single package (with > dependencies) of your set is installed on a particular system. No matter > how you might expect the packages to be used, no matter how you may > protest that this isn't the way the packages should be used, unless you > have good reasons for dependencies that prevent use in isolation then > packages will be used in unexpected ways that raise a whole new set of > problems. Often times complex applications have large sets of necessary dependencies. > > Any ideas as to how we can make all these packages? Is there any > > interest in some kind of effort aimed at this, to increase the package > > coverage? It's not possible to spam WNPP, nor create all the packages > > myself. Can Debian create some kind of official USE AT YOUR OWN RISK > > repository of user-contributed packages? > > Anyone can create a repository but tagging it "official" when the > packages are not of sufficient quality for Debian itself doesn't help > anyone, really. I've seen quite a few horror packages in unofficial > repositories. The only way to get decent packages is with a maintainer > who has the time to keep the packages in good order. Forget the "official", I was afraid having called it so would lead to confusion. What I meant by official was merely that developers and budding new maintainers would have some central repository for rough quality packages. > > Would people like to work on > > making rough packages from the list? Would they like to write tools > > that reduce rough package creation to a wizard, so that Linux users > > with no Debian expertise with an interest in having packages can > > create them (and link to this tool from Sourceforge and Freshmeat > > saying: "Want a package of this?"). > > Such packages would be just as useless as the ones currently available > on various non-Debian homepages. I have a list of all the apt-get.org sources and have incorporated their information into the Comprehensive Software Ontology and desire to begin backing them up. They are not useless! > Packaging isn't easy and automation is very difficult to do well. I have used my packager program (http://frdcsa.onshore.net/frdcsa) to create all the packages in my archive, and I can occasionally roll a package in a matter of a minute or two. The average software codebase is not so diverse as to be utterly unrelated to other packages. Furthermore, many tasks, such as identifying licensing, are really quite simple and the effect of automation will be felt over thousands of packages. > > Can we start a business where we > > contract to make packages for people? > > I get the impression you think making a package is a one-off. Someone > needs to make a commitment to maintain the package into the future. At > some point, if you simply keep adding packages, that commitment becomes > a crushing burden. Volunteers need to be motivated and overload is a > very common reason for that motivation to disappear. Quite often, the > end result of such burdens is that Debian QA has to remove the packages > for lack of maintenance, so it just adds more work to other volunteers. No maintainence is necessary with these rough quality packages. It can be done, but there is no mandate to do so. > > Can we build mappings between > > packages in Debian and other distributions and automatically convert > > these using Alien plus some tools to correct dependencies? Would > > anyone like to join my project to create these packages, or give me > > advice how to go about creating them? > > What you are trying to do is bring an entire environment / package set > into Debian. I'm doing the same thing with a different package set for > embedded devices. I am not restricted to AI or AI-related packages. Your systems are equally relevant, therefore we can consider collaborating. For instance, the WNPP is not a very sophisticated queue. Perhaps we can engineer a replacement. After Debian-Devel would be the proper place to lodge such a request. > It takes a lot of time. Wherever possible I try to keep to the same > build system for all packages. I try to apply changes across all > packages at the same time. In reality, there is no quick fix for such > situations and I don't see that automation is even desirable either. > Scripting can help around the edges (reports, summaries, status etc.). This is not a quick fix but an enormous project having hundreds of prerequisite codebases and 900 custom Perl modules, many databases, etc. > Break the problem down into smaller chunks, work on the base packages or > a few popular ones and gradually move into the rest of the field. You > won't be able to package them all but by bringing some into Debian, it > is very likely that others will see the appeal and join with the work. I have already made 200 packages and acceptance into Debian is not necessary and in some sense undesireable, as it would require a large maintainence effort. > Concentrate on what you can actually do yourself - get that done and > then see about the rest. Like many other areas of volunteer work, if you > have the itch, you need to scratch it because nobody else is likely to > have the time or motivation. I have done all of this myself. Debian is an apropos place to seek out people interested in making Debian packages. Where I may be off the mark is that there may be no interest in making rough quality packages. > -- > > > Neil Williams > ============= > http://www.data-freedom.org/ > http://www.nosoftwarepatents.com/ > http://www.linux.codehelp.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
