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;
- 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.
--
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
