Date: Tue, 28 Dec 2010 08:53:52 -0500 From: jhell <jhell@DataIX.net> To: Doug Barton <dougb@freebsd.org> Cc: David Demelier <demelier.david@gmail.com>, freebsd-ports@freebsd.org Subject: Re: portmaster: print /usr/ports/UPDATING on update Message-ID: <4D19EBF0.4060405@DataIX.net> In-Reply-To: <4D194421.9080304@FreeBSD.org> References: <4D15D275.6000308@gmail.com> <4D194421.9080304@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/27/2010 20:57, Doug Barton wrote:
> 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
>
In a way I sort of agree with this but on the other hand I look at it in
this way.
1). The only time UPDATING affects you is if you are building from
ports, in a sense
2). When upgrading a port you only need the entry that effects that port
and the ports that depend on it.
3). Also when upgrading a port you only need the entries that is only
relevant up-to that version of the port you would be upgrading to.
4). Also UPDATING is only useful if you have a ports tree installed and
will be upgrading using the ports tree.
So with the above said,
1). Why should there be a tool in user-land(world) if this matter deals
directly with upgrading ports via a ports tree.
2-3). If the entry is only relevant to the version of port being
upgraded to and the ports it depends on then there should be something
available that is more local to the port being developed rather than an
outside tool.
4). If this is only relevant to when a ports tree is available and
binary packages are not being used then there is no sense in injecting
user-land tools into the world.
Conclusion & with all due respect XML & JSON along with user-land tools
are a lame temporary solution to a longer standing problem and there is
a lack of framework that allows a developer to properly inform the user
of changes that might effect an upgrade.
``bsd.updating.mk'' might be a better longer term solution that would
allow a maintainer to alert the user with a simple "All done reading ?"
and a spill of output that effects that port up-to version being
upgraded. And yes XML and-or JSON could surely play a part in this as well.
JST
Regards,
- --
jhell,v
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJNGevwAAoJEJBXh4mJ2FR+r08H+wfNRp8Ks0VfZEbUqDbuvea+
kUPYSe1xvYkoC5CBiA3bBjEmAb7YIShMGemS3sU+Jc3FoZjAS3irbsQahpCEsooj
3gt1p72vaaKwE5L1yQUoiXH+gPxCobMS7fwn1hDz1lbZqSMb75jn/MZZ+8qcvXWw
N8APAeFGNbs4xA94FTa39xzo5yZjF73lrEzHc+9NdbrknN21/EBE3p5DgMNS+aX1
Z9uaDqERKPFf+19hCb+VcVBxoaRYv1P7UVeAz+GnNa/EtccPK0iIww1TNX9n+qnS
EaO58vgQDcAOePjBYrWXoUDbN+lkUYIvtZSrxCTwBdOdxOCRHEp9lNihYyDuiEQ=
=EsqM
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D19EBF0.4060405>