FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 01-07-2008, 04:20 AM
Andrew Dougherty
 
Default Debian-AI

> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-07-2008, 06:38 AM
Neil Williams
 
Default Debian-AI

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/
 

Thread Tools




All times are GMT. The time now is 09:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org