On Mon, Jul 20, 2009 at 08:02:24AM -0500, Carlo de Falco wrote:
>
> On 19 Jul 2009, at 15:23, Thomas Weber wrote:
>
>> On Sun, Jul 19, 2009 at 09:12:06PM +0200, Søren Hauberg wrote:
>>> søn, 19 07 2009 kl. 19:44 +0200, skrev Thomas Weber:
>>>> are there objections against moving lauchli.m from special-matrix
>>>> into
>>>> miscellaneous and eliminating the (then empty) special-matrix
>>>> package?
>>>
>>> I don't have any objections to moving this function elsewhere, but
>>> perhaps someone else does? Anyway, why should this function go into
>>> 'miscellaneous'? I'm not against this choice of package, I'm just
>>> curious as to why this one got picked.
>>
>> Well, I couldn't think of a better place/package. For what it's worth,
>> we patched it into the "octave-miscellaneous" package in Debian over a
>> year ago and haven't received any complaints.
>>
>> Maybe a strategy like the following would be good:
>> 1) If you have 1-2 small functions, that fit nowhere in the more
>> specialized packages, put them into miscellaneous.
>>
>> 2) If functions are of general interest and not specialized, put them
>> into general.
>>
>> Another candidate for such a treatment would be physical-constants,
>> which generates just one .m file (also its generation uses a Python
>> script).
>>
>> Thomas
>
> I am personally against the idea of grouping together all packages that
> contain few (or even only one) functions, for example I like the ability
> to have "physicalconstant" installed without
> garbling the octave namespace with all the stuff in the "miscellaneous"
> or "general" package
> which I usually don't use...
> I also believe this approach is more consistent with the packaging
> system phylosophy:
> In the near future (I should have finished doing this long time ago,
> sorry for my delay Søren ;) ) we expect to move to a release system
> where each package maintainer can take care of his/her package
> independently, so forcibly grouping functions that are maintained by
> different people would likely mess up things quite a bit...
The reality is that most small packages are maintained by nobody. That's
the reason why they stay small.
> In case it is to much of a hussle to have a deb package for each octave
> package, maybe you could have debs containing more than one octave
> package?
That's not possible, unless i fork octave-forge. I can't arbitrarily
create new source packages (well, I can, but then that's a fork, isn't
it).
Anyway, I won't insist on this proposal.
Thomas
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
