On Sun, 06 Jan 2008 23:20:26 -0600 (CST) Andrew Dougherty <andrewdo@frdcsa.org> wrote: > > 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. Poor quality leads to bugs which leads to maintainer work. Get the packages right first time. > Merely packaging the software is not sufficient. The capabilities > must be formalized and question answering software set up. So you need a set of committed, motivated, maintainers. > Often times complex applications have large sets of necessary > dependencies. So? Package them properly. > 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. Rough == poor == unacceptable. > > 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! Actually, apt-get.org is wildly out of date (and very slow). There are some real horror packages on those repos from apt-get.org that still work. > > 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. Yuk. > > 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. Reason enough to dismiss all such packages as unacceptable - no better than not being packaged in the first place. If I was to take on such a package, the first thing I'd do is shred debian/* > > 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. Sorry - I have no desire for these packages in Debian myself. I'm only answering on the basis of quality and Debian. > > 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. And? It has to start somewhere. Cross building Debian is a huge task but it hasn't stopped people starting the work. > > 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. You seem to want the benefits of Debian quality without submitting to the requirements of Debian for yourself. If that is so, such behaviour is repulsive, IMHO. > 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. I think you should consider *why* there is such a reaction to poor quality packages. So far, it would seem that your automated, rough, packages are actually worse than not packaging anything. If you want to work with Debian, work in the Debian way which means high quality packages - *all* packages. This isn't exclusive to Debian, there are plenty of horror RPM's across the web and they cause enormous aggravation for distros using RPM for their high quality packages. "Just because you can [make rubbish .debs], does not mean you should." "Just because you can [make a rough .deb], does not mean it is acceptable." Sponsors see plenty of horror .debs - it isn't hard to make a bad package. Merely making the software into a .deb does not confer any intrinsic benefits on the package - that requires making .debs that are of sufficient quality to be acceptable to Debian. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpg6I0W5bOZ8.pgp
Description: PGP signature