James Hawkins <truiken <at> gmail.com> writes:
> > Currently we have some categories that exactly fit to one dll and
> > some categories that include multiple dlls that are related. Also
> > there is overlap between those two. (And perhaps some that fit in
> > neither.)
> >
> > E.g. there is wine-quartz (one dll dlls/quartz/ ) and
> > wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ).
> >
Well, the common (newbie) user probably won't know anything about dshow (neither
do i ;) ), nor will he know what quartz stands for. The only thing he will see
in his console is something like:
fixme:quartz: blablabla
So for example if he was about to search for duplicates before filing a bug,
it's really better to have a per dll component.
> One component per dll is ideal for development.
> There are some situations where a group component works best, e.g.
> directX. In most cases though, per dll is best. We can have both
> types of components. The following is a list of components that need
> to get the boot or be renamed:
>
> wine-rebar (this is comctl32, no need for this component)
> wine-binary (what does that even mean?)
> wine-gdi-(printing) -> gdi
> wine-gui (per dll)
> wine-multimedia (per dll)
> wine-net (needs to be per dll)
> wine-patches (what was this for?)
> wine-user -> user32
> wine-usp10.dll -> usp10
> bug list, comments, login (what are these for?)
>
totally agree with James. I'll await the changes.....
