On 01/07/2005, at 7:38 AM, Richard Rauch wrote:

> Hi, I have two thoughts I thought I'd share.
>
>
> The first is for packages that only get loaded as dependencies for  
> other
> packages.  I turned this over in my mind for the first time a while  
> back,
> and saw a post about it, but the response, I think, misunderstood  
> the key
> idea.
>
> The idea is this: When you build a package, mark whether it is built
> because it is required by some other package, or if it was built/ 
> installed
> *directly* by the user.  E.g., I build (or in any case, install)  
> the GIMP.
> Let us suppose that aalib is already installed.  This is handled  
> already
> by the package installation.  Let us suppose that fontconfig is *not*
> installed.

Better yet increment a value that says how many installed packages  
depend on it.

>
> In this case, fontconfig will be attempted to automatically install.
> After installing, add a tag to the /var/db/pkg database entry
> for fontconfig to indicate that "this package was installed  
> automatically
> to meet dependency requirements.
>
> Now, suppose that you delete the GIMP.
>
> When pkg_delete runs into fontconfig while cleaning up the dependency
> tree for the GIMP, it will see that fontconfig was only installed as a
> dependency for some other package (pkg_delete does *not* need to know
> that it was for the GIMP).  So, pkg_delete will try to delete  
> fontconfig.
> (Or rather, it will delete fontconfig, if fontconfig has nothing else
> still depending on it.)

If the above is done and the dependency count drops to 0 then the  
package can be removed.

>
> The upshot is that if you install, say, 10 packages manually, you may
> end up with more than 10 packages added to your system---but if you  
> then
> delete those 10 packages without adding anything else, then you'll  
> have
> all packages removed that weren't installed before those 10 were  
> added.
>
> I've never really sifted through the package install/delete support,
> but conceptually this sounds simple.
>
> The reason to want this is so that you don't get an accumulation of
> cruft packages just because you briefly install/remove some other
> packages.  Cruft packages can create security issues and can add
> overhead to updating packages.

I agree it would be more tidy if this happened.

>
> Updating packages is the second issue.
>
> I use "make update" and usually it's okay.  But then I also avoid
> some of the really *nasty* packages like KDE.
>
> How practical would it be to automate a kind of recursive "make  
> replace"?
> This may not be for everyone, since it creates a window during which
> arbitrary packages mail be broken in mysterious ways.  But the idea
> is to start at "back" end of the dependency tree and "make replace" on
> anything that needs to be replaced (and on anything that depends upon
> it as you roll forward).  In most cases, the ABI will be  
> compatible, or
> compatible enough, that you won't notice problems.
>
> If a package fails to be replaced, then instead of stopping (as
> "make update" does), record the failure somewhere where the process
> can be readily integrated into a fresh "recursive replace" after a
> pkgsrc update (or after a manual attempt to fix the broken package).

> This would seem to satisfy the complaints of those who believe that
> "make update" is inferior to "make replace", while also providing a
> mechanism for cleanly getting everything up to date.
>
> If something fails to build, everything else stays, but if
> it succeeds in building (or when a fresh pkgsrc update permits
> a new build), all dependencies can be updated.
>
> No, I'm not offering to do this.  I'm "happy enough" with make update.
> But maybe those debating ways to change pkgsrc will find this idea
> novel and useful.
>
Does sound better than current behavior.  I wonder how often the ABI  
would turn out not to be compatible.
>
> Just a couple of ideas.  Use them or not.  (^&
>
>
> -- 
>   "I probably don't know what I'm talking about."  http:// 
> www.olib.org/~rkr/
>