[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How should we deal with 'pointless-on-this-arch' packages?



Ron Johnson <ron.l.johnson@cox.net> writes:

> On 10/15/06 02:33, Goswin von Brederlow wrote:
>> Ron Johnson <ron.l.johnson@cox.net> writes:
>> 
>>> On 10/15/06 00:03, Goswin von Brederlow wrote:
>>>> "Roberto C. Sanchez" <roberto@connexer.com> writes:
>>>>
>>>>> On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote:
>>> [snip]
>>>> I think it should be in the porters control what packages to
>>>> build for an arch with some guidelines what sort of packages can
>>>> be removed without loosing release status. For example removing
>>>> KDE would not be OK. Removal should be reserved for extreme cases
>>>> though. Things that just need long to build should be put into
>>>> weak_no_auto and limited to the stronger buildds of an arch.
>>> Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything
>>> that requires Mesa/OpenGL, and all of Charles Plessy's scientific
>>> packages  be marked do_not_build on 68k/Coldfire & ARM?
>> 
>> Because it is perfectly fine to run kde on such a system. Anything
>> that can run gnome can run kde. Anything that can run X can run kde I
>> would even say. Kicking one alternative for something (like kde) but
>> not others (like gnome) should not be allowed.
>
> But I *am* saying that porters/maintainers should think about
> dropping all the heavy CPU- & RAM-using packages.
>
> Including GNOME.

There are things in kde and gnome that aren't such resource
hoggers. While I never would run kde or gnome on my Amiga I from time
to time enjoyed playing gsame or other little games. I think you would
be hard pressed to find an arh where no component of kde or gnome has
a use. It is just too big a range of applications.

>>                                               If the port decides
>> that they don't need any X, e.g. there is no hardware capable of
>> running X applications, then they could remove all X stuff as a
>> whole. That would be different from removing kde.
>> 
>> But I feel that X, Gnome, KDE is a big part of what makes Debian what
>> it is. If you remove all that is it still Debian?
>
> Am I not running Debian if I only have a minimal system installed?
> Of course I am.
>
> XFce, fvwm, BlackBox, AfterStep, WindowManager(?) and jwm would all
> still let you have a nice low-power system.

What if the port decides that they don't need fvwm because everyone
from the team uses another wm? Wouldn't you as user be pissed of that
your favourite wm isn't available anymore?

There should be some guidelines that preserve the flavour of Debian,
the wide choice of packages for every taste out there. Something that
draws a line between being Debian and for example Embedded-Debian.
That should serve both Debian and the port.

> [snip]
>>> If an Amiga (using the unaccelerated fb driver?) is running as an X
>>> Terminal for a powerful, modern box, the Amiga would need to process
>>> the OpenGL commands, no?
>> 
>> There are no amigas with unaccelerated FB driver I believe, which does
>> not mean the FB is all that fast though. There are also crads with 3D
>> hardware and even cards allowing to use PCI graphic cards,
>> theoretically. But I don't think there is anything actually supported
>> and in use capable of realtime 3D gaming. Would a Virge 3D card even
>> be good enough to play Tuxracer? Anything that needs realtime GL is
>> probably useless for m68k.
>> 
>> So even if you could get hardware GL working remotely m68k just
>> couldn't do it I think.
>
> Then why build Mesa/GL packages for 68k and ARM and (probably?) MIPS?

There are non real time uses. A lot of stuff works fine without
requiring 50 FPS. For example I wrote a little fractal programm that
displays the M-Set in 3D and uses simple distributed computing. I
would keep 20 computers at university busy computing over night and
display the results on my Amiga. If the image takes 10h on 20
computers to compute then you don't need a high FPS to draw a
progress.

MfG
        Goswin



Reply to: