Re: Back to the point (was: Re: Reasonable maximum package size ?)
On Tue, 12 Jun 2007, Wouter Verhelst wrote:
I tried to give a meaningful answer to that in
<[🔎] 20070611201627.GB20581@country.grep.be>, but received no reply; I guess
it got drowned in the silly "all disks are reliable!" noise.
Perhaps you may want to read the three final paragraphs there and give
your opinion.
Well, in fact your opinion was reall meaningful and for the moment I
had nothing to add - that's why I keept silence to keep the trafic on this
thread that was drifting away low. To awake this thread again I'm quoting
you here.
On Mon, 11 Jun 2007, Wouter Verhelst wrote:
Note that that also doesn't talk about *what* exactly defines the line
between "an insanely large piece of junk" and "a piece of interesting
data large enough to be useful, but not so large as to become a
problem". The borderline there would seem to be rather gray.
You are perfectly riht here. But even if it is gray there should be
a document that draws this gray line for two reasons:
1. Make sure DDs know about the problem
2. Characterize the points in the far white and far black area.
Personally, I'd advice the OP to try to find the smallest data set that
is still at least moderately useful for the package,
Sounds like a very reasonable advise for Packaging Manual.
and to package that
(so that people not familiar with the software or the type of data it
requires can still try it out), unless that would require a package
larger than a few tens of megabytes. Additionally, it would be useful to
point in the package description and/or its documentation
I'd prefer the real pointer in the docs while the description should
just say: Read doc_xy (preferably README.Debian to learn how to obtain
larger data sets. I expect from a good doc that it contains a
complete code example.
to either a
way to automatically generate debs out of a larger data set so that
users can generate their own data debs and distribute them on their own
network, or to a separate debian archive that they can add to their
sources.list if they want.
This comes very close to what I would regard really good user support.
I don't think setting a hard limit (as in, with numbers) on maximum
recommended package size is a very good thing to do; I'm tempted to
think that this kind of limit is not really static over time, and thus
that wording such as "roughly two times the average package size at the
time the package is created" or so would be more appropriate.
Yes. When I was speaking about numbers I had more like a function
dependand from certain key parameters in mind than hard numbers.
So "roughly two times the average package size at the time the package
is created" fits absolutely my expectation for a description of the
limit.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: