Forcing port reinstalls without rebuilding over and over again

[Polytropon]

On Wed, 12 Dec 2018 22:52:21 -0700, Gary Aitken wrote:
> On 12/12/18 4:14 PM, Paul Schmehl wrote:
> > --On December 12, 2018 at 2:42:00 PM -0700 Gary Aitken <freebsd at dreamchaser.org> wrote:
> > 
> >> On 12/12/18 1:47 PM, Polytropon wrote:
> >>
> >>> In my opinion, it's a little better to create your own
> >>> "top ports list" instead of saving the current state (or
> >>> at least have both lists at hand, but only use your own).
> >>> In that "top ports list", you list the things you actually
> >>> want to use, and you do not care about their depencencies,
> >>> simply because portmaster can resolve them on its own. So
> >>> first, your list is much more readable (as it will only
> >>> contain the software you are interested in, and nothing
> >>> of the software you might need to build or run them), and
> >>> second, your list will be much more portable and also deal
> >>> with the "port not needed, but still installed" problem
> >>> described above.
> >>
> >> That is the way I've done it in the past, using -R -d, and doing so
> >> does not rebuild dependencies.  I suspect the problem has something
> >> to do with -a.
> >>
> > Well, you kind of need that if you're going to rebuild all ports.
> 
> No, you don't.  All you need are the top level ports.  Right now I
> have 800 ports installed.  To get those, I only install 36.

Yes, that way my basic idea. :-)



> I agree
> it's a bit of a hassle to keep track of what you need.

The discussion has shown that there is a specific case where
you need something to be installed, but it's not a dependency
of something else. Still you sometimes don't remember to put
it on your "top ports" list. As it has been mentioned, creating
a meta-port or at least a custom port list is helpful here.



> On the other
> hand, it seems a bit lame to not know why you have the things you
> have installed actually installed.

And this is where additional work can occur: Let's say you
have installed something on your new system because it was
on the list of the old system - something that was a dependency
somewhere in the past, for something you don't remember. Now
that port is installed on the new system and will be subject
to security considerations (port audit). Result: You have to
deal with an important security update for something you
actually don't use.



> Keeping track is a good idea, as
> it forces you to review what you have installed and why; I find I quit
> installing some things after a while.

For example, this applies to creating environments in which
certain printers and scanners will work: You install certain
components independently to make it work. Later on, the
functionality of those little pieces becomes part of a
bigger piece, or maybe even part of CUPS or SANE by default.
If you make your "top ports" list and add comments for _why_
and _when_ you added something, or _which_ parts form some
functional conglomerate, it's quite easy to feed this into
tools like portmaster or even "pkg install".



> Keeping track also (unfortunately?), means you sometimes can cut down the
> top level list, as higher-level ports tend to drag in more stuff over the
> years.  e.g. I used to have to install cups and three or four other things,
> but (in my case) they come in automatically now.

Exactly my observation. :-)



> <off-topic>
> What I find particularly difficult, however, is keeping track of options.
> Some ports have NLS by default, some have EXAMPLES by default, some have
> various GUI options by default.  NLS is fairly easy to get rid of, but
> the gui options are not.  And the 5 word hint in the options dialog is
> usually totally inadequate to determine if you want (or need) the option
> enabled.  It would be really helpful if there was a button you could hit
> to give you more detailed info about what each option is for; kind of a
> pkg-descr for the option, explaining when you want it and when you don't.
> </off-topic>

And especially if you're building an environment for a non-US/UK
user, for example for a german user, you _want_ the NLS support
to be as good as possible, you _want_ the additional language
packages (which are of course not dependencies per se!).

However, I agree with your opinion that the configuration dialog
for package options is sometimes quite terrible. Especially the
idiotic naming of certain packages makes it hard to answer the
elementary question of "Do I need this?" Switching to another
terminal and checking pkg-descr files of the options doesn't
always help, as the description in some cases doesn't really
tell you what something is, what it does, or when / why you
will need to install it. So instead of "use this", the description
text should follow a "use this for" or "use this when" approach.

Many years ago, I made up this for illustration purposes:

+--------------------------------------------------------------------+
|                     Options for stupido 19.84                      |
| +----------------------------------------------------------------+ |
| | [X] CUPS         Enable support for printing (requires CUPS)   | |
| | [ ] GTK          Use GTK backend                               | |
| | [ ] KDE4         Use KDE4 backend in room 101                  | |
| | [ ] KLOMPATSH    Use Klompatsh                                 | |
| | [ ] RHUMBOIRE    Use RHUMBOIRE backend                         | |
| | [ ] QUEEKNARG    Enable QUEEKNARG support                      | |
| | [ ] ECK'N'POOT   Build with COM-POOTER module                  | |
| | [ ] SHMEER       Build bindings for SHMEER                     | |
| | [ ] SHLORTS      Enable support for SHLORTS (requires GNOOLFS) | |
| | [ ]              Use nothing, go away.                         | |
+-+----------------------------------------------------------------+-+
|                       [  OK  ]       Cancel                        |
+--------------------------------------------------------------------+

It's still out there in the ports tree, in other forms... ;-)


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...