Opened 8 years ago

Last modified 8 years ago

#52981 new enhancement

Print custom warnings from Portfile with `port info`

Reported by: RJVB (René Bertin) Owned by:
Priority: Normal Milestone:
Component: base Version:
Keywords: Cc:
Port:

Description

I don't think there's currently anything that allows Portfiles to print out anything else in more detailed fashion when port info is being executed - apart from appending text to long_description, right?

What I'd like to be able to do is print (detailed) warnings when that is justified when port info is executed. Printing that information during one of the install phases is fine too but a bit late, but the information shouldn't be printed unconditionally because then it most certainly would show up at inappropriate times like when running portindex or at certain points during an elaborate upgrade run.

Think information that could be printed in the notes but that you'd want users to consider before they start installing a port (possibly a whole run of installs).

Possible enhancements include:

  • activate ui_info when port info is executed
  • an optional switch to notes that prints the notes also during port info.
  • pre-info and/or post-info contexts (possibly overkill for what I'd like to do).

I'd be happy to work up something, but with some form of guidance to remain on the same wavelength.

Some more elaborate context (as much in a (coco)nutshell as I managed):
My KF5 ports will be supported only with port:qt5-kde but they will work with a stock Qt5 too, with a varying amount of feature loss. That's particularly true for certain of the KF5 frameworks when the potential runtime feature loss is not an issue. My install approach is thus based on user choice: install a KF5 port from scratch (without Qt5 active) and you'll get the preferred port:qt5-kde in the bargain; install it with port:qt5 already active and that port will be used. This works just as with -devel ports, except that in this case a variant is set when you install a KF5 port against port:qt5.

I don't want to impose restrictions that make it impossible to use the unsupported stock Qt5 port if I can avoid it, and assuming users never change their Qt5 port there are no hard reasons to impose anything except for lack of support.
Dealing with mismatching KF5 framework variants is more elaborate potential issue. Chances are high again that this will just work (port:qt5-kde is a drop-in replacement for port:qt5) so if possible I only want to print a warning when a "mismatching" framework will be pulled in. I am currently doing this, but I get reports of false alarms that I think cannot easily be avoided without coupling the warning to a Portfile run context.

Attachments (1)

patch-ui_info-in-info.diff (1007 bytes) - added by RJVB (René Bertin) 8 years ago.
activating ui_info during port info is quite simple and doesn't appear to have side-effects

Download all attachments as: .zip

Change History (5)

Changed 8 years ago by RJVB (René Bertin)

Attachment: patch-ui_info-in-info.diff added

activating ui_info during port info is quite simple and doesn't appear to have side-effects

comment:1 in reply to:  description Changed 8 years ago by RJVB (René Bertin)

Replying to RJVB:

  • an optional switch to notes that prints the notes also during port info.

Or a new info_notes option which prints text after long_description for instance.

comment:2 Changed 8 years ago by raimue (Rainer Müller)

Summary: info phasePrint custom warnings from Portfile with `port info`

info is not actually a "phase" (or "target" in port1.0 terminology). Abusing and overriding the phase from the port client is a horrible hack. There is no connection between the "info" in ui_info and port info and there should not be any.

comment:3 in reply to:  2 Changed 8 years ago by RJVB (René Bertin)

Replying to raimue:

Abusing and overriding the phase from the port client is a horrible hack.

If you say so. I call it a proof-of-concept approach meant to evaluate the side-effects of activating ui_info during port info (something that at least has the merit of being simple and intuitive) and the most straightforward solution to explore.

comment:4 Changed 8 years ago by mf2k (Frank Schima)

Type: requestenhancement
Note: See TracTickets for help on using tickets.