[ros-dev] rosapps

blastos at infomaniak.ch blastos at infomaniak.ch
Thu Mar 12 22:01:56 CET 2009


Why don't we mimic the linux Gentoo distribution?

Gentoo uses flags  USE who changes dependencies at build time

from the gentoo's handbook @ 
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part2_chap2:

"2. USE flags

2.a. What are USE flags?

The ideas behind USE flags

When you are installing Gentoo (or any other distribution, or even 
operating system for that matter) you make choices depending on the 
environment you are working with. A setup for a server differs from a 
setup for a workstation. A gaming workstation differs from a 3D 
rendering workstation.

This is not only true for choosing what packages you want to install, 
but also what features a certain package should support. If you don't 
need OpenGL, why would you bother installing OpenGL and build OpenGL 
support in most of your packages? If you don't want to use KDE, why 
would you bother compiling packages with KDE support if those packages 
work flawlessly without?

To help users in deciding what to install/activate and what not, we 
wanted the user to specify his/her environment in an easy way. This 
forces the user into deciding what they really want and eases the 
process for Portage, our package management system, to make useful 
decisions.

Definition of a USE flag

Enter the USE flags. Such a flag is a keyword that embodies support and 
dependency-information for a certain concept. If you define a certain 
USE flag, Portage will know that you want support for the chosen 
keyword. Of course this also alters the dependency information for a 
package.

Let us take a look at a specific example: the kde keyword. If you do not 
have this keyword in your USE variable, all packages that have optional 
KDE support will be compiled without KDE support. All packages that have 
an optional KDE dependency will be installed without installing the KDE 
libraries (as dependency). If you have defined the kde keyword, then 
those packages will be compiled with KDE support, and the KDE libraries 
will be installed as dependency.

_By correctly defining the keywords you will receive a system tailored 
specifically to your needs._ "

It's just my 2 cents...

Abelenda David

Thomas Bluemel a écrit :
> Instead of actually removing this stuff from trunk, can't we drive this 
> by an environment variable with rbuild so that it skips building modules 
> not neccessary?
>
> Thomas
> Aleksey Bragin wrote:
>   
>> So, are there any objections in separating thirdparty, additional, 
>> sometimes helpful stuff into addons module, and having all apps which 
>> exist in Windows, but aren't required for booting into rosapps?
>>
>> Please, let's come to a solution, because having such a trash can which 
>> rosapps is now is unbearable.
>>
>>
>> WBR,
>> Aleksey Bragin.
>>
>> On Mar 9, 2009, at 2:50 AM, Ged wrote:
>>
>>     
>>> I would opt for deleting everything in rosapps.
>>>
>>> I’m not really sure why it’s important to start rearranging it as 
>>> there’s very little of use in there.
>>>
>>>  
>>>
>>> As per our project mandate we aren’t interested in anything which 
>>> isn’t core.
>>>
>>>  
>>>
>>> Ged.
>>>
>>>  
>>>
>>>  
>>>
>>> *From:* ros-dev-bounces at reactos.org 
>>> [mailto:ros-dev-bounces at reactos.org] *On Behalf Of *Aleksey Bragin
>>> *Sent:* 08 March 2009 18:16
>>> *To:* ReactOS Development List
>>> *Subject:* Re: [ros-dev] rosapps
>>>
>>>  
>>>
>>> I'll explain his idea.
>>>
>>>  
>>>
>>> The idea he would likes to propose is to separate the mess inside 
>>> rosapps, and provide a clear division of what goes where:
>>>
>>> 1. trunk/reactos contains ONLY stuff which is vital for the system to 
>>> work minimally. Including explorer, GUI, and things like that, but 
>>> without calculator, solitaire, or anything like that.
>>>
>>> 2. rosapps - components similar to those present in Windows, but not 
>>> vital for the boot process.
>>>
>>> 3. addons - components, which are additional to the base set of apps 
>>> and drivers Windows ships with.
>>>
>>>  
>>>
>>> Comments are welcome on his idea.
>>>
>>>  
>>>
>>> My own comment is that the idea seems to recall what we originally 
>>> been discussing a year or more ago, but stopped caring as more devs 
>>> got more powerful PCs. There is no strict solution on what goes where 
>>> now, actually that's why his idea started - he proposed to move winver 
>>> and winhlp back to trunk, and I was arguing over it.
>>>
>>>  
>>>
>>>  
>>>
>>> WBR,
>>>
>>> Aleksey Bragin.
>>>
>>>  
>>>
>>>  
>>>
>>> On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:
>>>
>>>
>>>
>>> Huh?  The rosapps module isn't included by default in the build to 
>>> begin with, so how does it decrease build time?  Also, the 
>>> applications in there are supposed to be providing equivalent 
>>> functionality found in Windows.  Downloader is an exception, but what 
>>> else is?
>>>
>>> On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind at yandex.ru 
>>> <mailto:lentind at yandex.ru>> wrote:
>>>
>>> Hi.
>>>
>>> I suggest to divide rosapps on two parts:
>>>
>>> 1) Components which are present in Windows (rosapps)
>>> 2) 3rd party components (3rdapps)
>>>
>>> In rosapps it is necessary to place all components without which the
>>> system can normally work (calc, hh, winhlp32, charmap, games and etc)
>>>
>>> In 3rdapps components which are not present in Windows (downloader,
>>> imagesoft and etc) will take places
>>>
>>> Such placing of components will allow to reduce compilation time as you
>>> can not compile not the modules necessary to you (rosapps and/or 3rdapps)
>>>
>>> Please tell your opinion on my proposition.
>>>
>>>       
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev at reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>     
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>   



More information about the Ros-dev mailing list