[Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Ythogtha]

Sorry for the double mail, I thought it still wasn't working with this email
address, but it seems I did something right...

	Arnaud.


> > On 06/11/16 03:51, Erik Hanson wrote:
> > > The goal is then that no one would
> > > ever have to look at the README file, they could just tick some boxes
> > > and be on their way.
> > 
> > No, that's not the point. At least not mine.
> > The point is to facilitate the process.
> > And you can't argue that for _educated_ user it is going to be.
> > 
> > But as you mentioned before, we might have problem with _education_ 
> 
> 
> 	My own use-case for an OPTIONAL field would be to alert me when there is
> an update available for an installed package, which happen to be an OPTIONAL
> dependency for another package I have installed.
> 	Quite the same as the actual REQUIRE : when a REQUIRED package has an
> update, I list the installed packages which depends on it.
> 	This allows me to decide if I want to rebuild the package for which the
> dependency changed, even if it hasn't changed itself.
> 
> 	It had happened to me on occasions that ffmpeg stopped working because I
> updated an OPTIONAL dependency, I was actually thinking about GREPing on the
> READMEs to find those OPTIONAL dependencies, because it sucks when ffmpeg is
> broken like that, and there is no easy way to know in advance in the general case
> (I could do something specific for ffmpeg, but that's not the point, and there
> are other packages with OPTIONAL dependencies, though none with as many as
> this one).
> 	It could even happen while we aren't even aware we had an OPTIONAL
> dependency, because some packages detects them automatically, and we could have
> an OPTIONAL package already installed, hence linked into a new one without being
> really aware of that : no step about it was taken, and we might not even need the
> OPTIONAL part, but it's there, therefore used.
> 
> 	For my own use-case, a simple list of possible OPTIONAL dependencies is
> clearly enough, because I will read the READMEs, and know what to do, but I have
> no direct way of automatically knowing what will be impacted by a package update.
> 
> 	I think this is something that could be useful to everybody. It doesn't
> change much, basically a tool would add OPTIONAL dependencies to REQUIRE ones
> when they are already installed, for the purpose of presenting to the user what
> might need rebuilding after an update, or even what packages might depend on
> another one if we want to remove it :
> « Hey, this package isn't REQUIREd by any of your installed packages, but is
> OPTIONAL for this one, are you sure you want to remove it ? »
> 	Or in my case a script "is_this_package_required PKGNAME" reporting when
> the package is REQUIRED and OPTIONAL.
> 
> 
> 	Those are thoughts about the usefulness of the OPTIONAL field completely
> out of an automatic building process with checkboxes and automatic dependencies
> checking and building.
> 
> -- 
> Arnaud <yth at ythogtha.org>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
> 


-- 
Arnaud <yth at ythogtha.org>