Re: further package removals/potential package removals

[Jeff Johnson <n3npq nc rr com>]

Enrico Scholz wrote:

> Jeff Johnson <n3npq nc rr com> writes:
>
>  
>
> > > If you think that the fact that Nautilus has a lot of "features" means
> > > that it's necessary for it to cause the entire desktop as a single
> > > unsplittable ball of mud, well, you have been misinformed.
> > >      
> > By George, I think he's got it! The point is that dependencies are not
> > the problem,
> >    
>
> The gnupg -> (perl,openldap) deps *are* a problem, because they are not
> needed for the gnupg core functionality but only for two extra programs,
> which are unused on most systems.
>
>
>  
>
> > bloat is.
> >    
>
> Yes, the stupid kernel packaging which brings 30 MB of bloat into / is a
> problem also. But nevertheless, the deps should be cut. A candidate would
> be 'pam' which brings 'glib2' in, or all the packages with 'Requires:
> kernel>=2.6' which should be either removed or rewritten to 'Conflicts:
> kernel<2.6'.
>  

Perhaps. The rationale for preferring Requires: rather than Conflicts: 
is that
depsolvers have a
  Will an upgrade "fix" a dependency problem?
but do not have a similar, widely deployed, policy for Conflicts: afaik.

Well,  apt does, and perhaps smartpm, but let's not go there ...

>  
>
> > No, choosing locales is an install option that applies to binary
> > options that is anaconda selectable,
> >    
>
> I might be wrong (I do not have time to verify it now) but afair, on my
> last FC3 installation, the language selection in anaconda had no influence
> on %_install_langs but sets some value in /etc/sysconfig/i18n only.
>  

If true, then it's a bug in anaconda, which does permit selection of 
desired locales,
and has attempted to limit the number of installed locales in the past.

>  
>
> > > > Try --excludedocs, been in rpm for years.
> > > >        
> > > I must have overlooked the Anaconda checkbox that turns that on.  And
> > > the "yum update" option, too.
> > >      
> > So make an RFE.
> >    
>
> Has probably only a small chance of success. 'anaconda' will follow more
> and more the Gnome UI guidelines so that there is no room for useful
> features. Existing ones like package selection or detailed progress
> reports were removed already.
>
>  

Predciting the future without attempting an RFE is pointless blather. 
Not that you
haven't made many reasonable RFE's over the years ...

>  
>
> > The mechanism exists even if anaconda and yum choose not to use
> > --excludedocs. The mechanism is also globally configurable, put
> >    %_netsharedpath /usr/share/doc
> >    
>
> mmmh... %_netsharedpath... we had a lot of fruitless discussions about
> this so I wonder that you mention it here ;)
>
> It has serious implementation flaws (infection of parent paths; bug
> #52725 lasts for >3 years in bugzilla) and there does not exist a
> mechanisms to test it in %scriptlets (which causes problems e.g. in
> all the java packages).
>
> Using %_netsharedpath to disable installation of certain files is not a
> good idea.  E.g. files in /usr/share/doc are required by cups for its
> web-frontend.  %_netsharedpath is for situations where the files exist
> but are managed externally.
>  

Yep, all well known. %_netsharedpath is a naive mechanism.

OTOH, %_netsharedpath *will* prevent /usr/share/doc from being 
populated, and
the "infection" you speak of, for an empty /usr/share/doc directory, is 
irrelevant on this thread.

>  
>
> > in /etc/rpm/macros.
> >    
>
> anaconda does not honor any previous rpm setting. Partially, this is
> caused by rpm which makes it really difficultly to override paths of its
> configuration.
>  

Actually, I suspect the problem is that anaconda may be carrying a 
canned configuration
into an empty chroot that is difficult to configure. All paths in rpm 
are changeable through
appropriate configuration, difficulty is in the eye of the beholder.

73 de Jeff