Date: Mon, 27 Dec 2010 17:57:53 -0800 From: Doug Barton <dougb@FreeBSD.org> To: David Demelier <demelier.david@gmail.com> Cc: freebsd-ports@freebsd.org Subject: Re: portmaster: print /usr/ports/UPDATING on update Message-ID: <4D194421.9080304@FreeBSD.org> In-Reply-To: <4D15D275.6000308@gmail.com> References: <4D15D275.6000308@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 12/25/2010 03:16, David Demelier wrote:
| Hi,
|
| A lot of people always forget to read UPDATING (that's normal we'll are
| humans).
|
| Each entry in UPDATING is like "AFFECTS: users of net-mgmt/flowd" so if
| an update of net-mgmt/flowd is available and a *recent* entry in
| UPDATING talks about then print the message.
|
| This can prevent a lot of breakage and useless noise on lists. What do
| you think ?
I've caught up on this thread now, kicked it around with the cool cats
in #bsdports@efnet, and here is my opinion, to the extent I have
anything to say about it. :)
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. :)
This is not really as hard as it sounds, as the entries for UPDATING
would not have to be very complex xml-wise, and there is already
existing infrastructure that we can leverage to make things easy for the
committers. Also having this information in XML format will make it
easier for other programmatic solutions down the road.
~From the user side, we're not really losing anything by not having
"human readable" output readily available, since 99% of users will just
want to be able to know what entries are relevant to their installation
anyway. Of course one useful option for the portupdating script would be
"print all of the entries since X date" so that if someone had a purpose
for reading the plain text it could be dumped to a file, parsed, or what
have you. Meanwhile, all of the ports management tools could benefit
from having _a_ common tool to do this, similar to how we've all
benefited from portaudit.
But since that's not likely to happen tomorrow, what I do anticipate
adding to portmaster is a "thingy" to stat the update time on
$PORTSDIR/UPDATING and then notify you if you have not viewed the file
since the last time it was updated. The code to compare/store timestamps
I already have, but this also entails adding an option to turn off that
behavior, etc. etc. I'm currently debating whether to try to get this
into the version of portmaster I release soon'ish, or wait till after
the upcoming base releases.
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.
| Merry Christmas and happy holidays !
Same to you. :)
Doug
- --
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBCAAGBQJNGUQhAAoJEFzGhvEaGryEGDoIALiyBkd2PlfEnI/QpfkXXsg5
wGSMjkNoIAh3VJdWIIe48fLlI4V/Wb+958+Jss2BsHf7GyCY5EjBz5/dCYeGTyIG
fhHJk0bqxkPtWAawhzn9v1Hrk/WFWUu0Ccr2jqQ847tyoL+iWBuqR+BaT0H1jDQF
XgbP7YTYQ2CpYYcwNo4XiNNtrlAcbq8Wa/RCBw80YK/lMeUpMtgumbn94DdW+P0r
WxHgZG/JuDmaLp33+D08j+chufD6kbjjPyBI+HDChW2Z9xNweSvxrUP0QVW1q1nQ
wgqGgDrds8wXM3qiP/BF7owaV0+VaZHlwx3P4wlUib+oPOusMaum/z21TuzfJSQ=
=7+C9
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D194421.9080304>