Still having trouble with package upgrades

[David Jackson]

On Wed, Mar 7, 2012 at 2:12 PM, Benjamin Tovar <ben at robotoloco.com> wrote:

> On Wed, Mar 07, 2012 at 12:57:46PM -0500, David Jackson wrote:
> >
> > So it seems like a happy compromise here. You will get what you need
> > and us newbies and other users who really dont want the extra
> > trouble of compiling will get our binaries. Everyone gets what they
> > want and is happy, it seems.
> >
>
> Yes, this sounds awfully good, except that I think it is much harder
> than you think. First, some options are mutually exclusive
> (i.e. ncurses vs slang)... so, maybe there are two, or three versions
> of the same package... and again, this sounds awfully good, except for
> the limited and volunteered time of a port maintainer. A happy
> compromise might be then to have binary packages of popular ports,
> which is how we have it now.
>
>
its really not that difficult and this is not an issue tht cannot be dealt
with in the default binary package configuration. Both slang and ncurses
could be installed and applications could be linked to one or the other. If
ncurses is a better choice for instance, it couild be by default linked to
that.

So if a package has a choice oif being linked to ncurses or slang, then one
package will be built, linked to ncurses or whatever is the generally best
option and that build of the application will be the binary package.

The point i would like to make is, for us to have good binary packages, we
dont need to create a different package for every combination of compile
time options, but instead compile with the best default set of options. If
a user wants more flexibility than that, they are free to compile with
ports. the availability of a binary package in no way whatsoever limits the
availability of the option to compile a port if the user wants to do that.
its not an either or thing.

Where two options are mutually exclusive, the best option should be chosen.
Where the two options are not mutually exclusive and add a feature or
capability to the software, the option can be included. run time
configuration settigns should be set to the most reasonable values.



> Second, and I think this the most important reason, ports put the
> responsibility of the system on the user. They force you to make
> decisions on exactly what software is installed. You want the
> stability and freedom of FreeBSD without this responsibility, and this
> seems very hard to compromise (e.g., macosx and most linux
> distributions remove the responsibility by making all these choices
> for you).
>
> Is this newbie friendly? Probably not. Does it need to be? Well, it
> would be nice if more people use it, but if we remove the
> responsibility from the user, then it would not be FreeBSD, it would
> be something else. (Like Debian GNU/kFreeBSD, which sounds like what
> you are looking for.)
>
>
The fact is, again, allowing the user to not go into that kind of detail
and not mess around with compile time options, does not prevent in any way
you from doing so. the OS should be about freedom, Not YOU forcing your
ideas about how the system should be used on everyone else.


as I repeatedly said, you are free to configure your applications compile
to your hearts content, i support you having that freedom.You are the one
in fact who has been trying to take away my freedom of not having to mess
around with compile options if I dont want to.

> --
>

 just let users decide if they want to compile port or use pre compiled
package for themselves

> Benjamin Tovar
>
>