Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de> wrote:
> On Sun, 21 Jul 2002, Jan Schaumann wrote:
> > plenty of room for improvement.  I'll be happy about all critique.
> 
>  * You rely on "pkg_info foo" being the same as "pkg_info foo-[0-9]*".
>    I'd suggest you change that to make things more obvious and similar
>    to DEPENDS.

So we'd want to actually check that the suggested version is the same as
the installed version, right?  I guess I overlooked that since I assumed
no versions would be given (which seems wrong).  I'll work on that.

>  * If a "suggestion" is accepted, it should be changed into a dependency
>     - to make sure binary pkgs pull in the proper pkgs
>     - to prevent deinstallation of the "suggestions" - things might break
>       else! (imagine a "suggested" lib is gone... boom!)

I disagree.  If a package 'suggests' a library, it *must* be fully
functional without it.  Otherwise the library would be a dependency, no?
Therefore, any package that is 'suggested' *must not* influence the
usability of the suggesting package.  That is why they are installed
_after_ the initial package is already installed.

The user should be free to install, remove and re-install suggestions as
they please.

Binary packages should remain unaffected from suggested packages.  I
guess I'd have to look more carefully at how binary packages are built,
but when building, TAKE_SUGGESTS should automatically be set to "NO".

>  * You do not mention or consider changed configure/build process at all.
>    Often, GNU configure needs additional switches to make use of
>    additional software. How do you intend to handle that?
>    Relying on smart configure scripts is not an option here.
>    (We already had this discussion quite some time ago... search the
>     archives!)

Hmmm, this may get hairy:  While the suggested package my be installed,
it is important to stress (again) that it is (from a purely functional
point of view) independent of the suggesting package.  It is, in a way,
just a convenient way to say "Here, this might be useful for you, if you
like it, install it.  If not, don't."

Given that any completely independant package has no way of knowing what
else is installed of other optional packages, I don't see how the
configure-paramters could be adjusted.  This would require that packages
dynamically look up what's installed and adjust their configuration
paramters accordingly.  Currently, this is left for the user:  if a user
knows that package A is installed and that package B can take advantage
of it, she has to make the necessary adjustments[1] herself.

"Suggested" packages should not be any different, I think.  The only
time we can adjust configuration (ie build-time) parameters for package
A is when we know for sure that package B is available - this
automatically turns B into a dependency for A, which is
counter-intuitive (and -productive) to the idea of suggestions.

Or did I misunderstand you?

Either way, thanks for your input!
-Jan


[1] Examples: mutt and MUTT_USE_NCURSES (the user needs to choose which
curses library to use); or links vs. links-gui (the user needs to choose
whether or not to install GUI support).

-- 
Wenn ich tot bin, mir soll mal Einer mit Auferstehung oder so
kommen, ich hau ihm eine rein! (Anonym)