portmaster: print /usr/ports/UPDATING on update

Tue Dec 28 08:28:08 UTC 2010

On Tue, Dec 28, 2010 at 10:07:18AM +0300, Eygene Ryabinkin wrote:
> Mon, Dec 27, 2010 at 05:57:53PM -0800, Doug Barton wrote:
> > The Real AnswerTM is that we need a tool with striking similarities to
> > portaudit. The basic idea would be that UPDATING entries would be done
> > in xml, and then the user can either run portupdating (or whatever the
> > name ends up being, that's a really bad name but I suck at naming tools)
> > either by default for their whole system, or vs. a specific port. I
> > would strongly recommend that the behavior, command line options, etc.
> > be consistent with portaudit. Download it and check the man page if
> > there are any questions. :)
> 
> There are two questions that arise with this approach:
> 
>  - we should find a way to keep an old UPDATING file in place;
>    obviously, it can be easily created from the XML file, but
>    currently UPDATING is delivered via CVS and it will be good
>    to allow this behaviour even with the XML'ized version;
>    but keeping the plain-text UPDATING in CVS while UPDATING.xml
>    will be used is a bad idea -- UPDATING will be non-master
>    file, so its history will be redundant.  From the other hand,
>    we have no XML tools in the base tree, so UPDATING can't be
>    easily created from the XML version at the user machine;

Two quick thoughts here:

- I personally would prefer a human-readable file (and yes, I *can*
  read XML; that doesn't mean it's easy or I *want* to :)
  ...so how about a JSON representation?  Human-readable, human-editable,
  but still capable of being formalized and validated

- ...and as for an implementation, there is a mini-JSON library in
  NetBSD's netpgp implementation -
  src/crypto/external/bsd/netpgp/dist/src/libmj/ in NetBSD CVS

>  - currently, UPDATING has only port names, but not their versions;
>    one takes the entry timestamp and if he had not yet upgraded
>    the relevant port(s) after this timestamp, then the corresponding
>    entry is for him.  I see there two cases:
>    a) there is a specific port version at which some crucial change
>       that demands the UPDATING entry had happened; if the version
>       specification will be included in UPDATING, then we won't
>       even need the timestamp -- one should just take the currently
>       installed version and the version to be installed; the the
>       entry's version lies between those two, user will surely need
>       to read the UPDATING entry;
>    b) there is a infrastructural changes that affect all or some ports
>       that will be built after some date; again, the logics of choosing
>       the entry to be presented is the same as above, but one should use
>       timestamps, not ports versions.
> 
> But having thinked about this a bit, now I am favoring another approach:
> one should not rely on the portmaster/portupgrade/OtherTool to present
> the UPDATING entries: the best place is the ports infrastructure itself
> (or pkg_install suite).  This way, any tool that will do upgrades will
> receive the UPDATING stuff for free.
> 
> Currently I am trying to figure out if it will be sufficient to have the
> appropriate machinery in the pkg_delete tool: the old port version and
> timestamp are already there; the new timestamp is more-or-less the
> current date; the only needed piece is the new port version.  It can be
> provided via the environment variable by the portmaster-like tool; such
> variable will trigger the processing of the UPDATING file.  This is
> rather rough plan, feel free to correct/criticize it or show why it is
> not doable using such approach.
> 
> > The other thing this entails is portmaster actually storing
> > information of its own completely aside from /var/db/{pkg|ports}. I'm
> > really sort of nauseous about that whole idea since it's a slippery
> > slope that I don't want to travel down. But I'm not seeing any other
> > way to accomplish the task of "make sure that the user knows that they
> > should read UPDATING" without doing something very much like this. Of
> > course, if someone else has a better idea, I'm all ears. :)
> > 
> > What I do _not_ want to do is write an "UPDATING text file parser"
> > myself. Not only do I think that's a bad idea generally, it's not a
> > project that I am at all interested in, and I don't see it as
> > something that should be part of portmaster to start with. I could be
> > talked into the UPDATING.xml project if someone were to come up with
> > funding for it, but (just being frank and honest) it's too big a
> > project for me to tackle on a volunteer basis atm.
> 
> I had shown the simple shell script that will parse the UPDATING and
> present the entries for the given port if the fall into the "last N
> days" category.  If you had missed it -- ping me, I'll show it to you
> once again.

G'luck,
Peter

-- 
Peter Pentchev	roam at space.bg    roam at ringlet.net    roam at FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This sentence claims to be an Epimenides paradox, but it is lying.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20101228/15fce1c6/attachment.pgp