Date: Tue, 28 Dec 2010 10:27:55 +0200 From: Peter Pentchev <roam@ringlet.net> To: Eygene Ryabinkin <rea@freebsd.org> Cc: David Demelier <demelier.david@gmail.com>, Doug Barton <dougb@FreeBSD.org>, freebsd-ports@freebsd.org Subject: Re: portmaster: print /usr/ports/UPDATING on update Message-ID: <20101228082755.GA4381@straylight.ringlet.net> In-Reply-To: <SaPpQ%2B%2BiANujx2z50Bs5SbHA8lc@QsmfhJNucgI88DfvPJdT1/nyboE> References: <4D15D275.6000308@gmail.com> <4D194421.9080304@FreeBSD.org> <SaPpQ%2B%2BiANujx2z50Bs5SbHA8lc@QsmfhJNucgI88DfvPJdT1/nyboE>
next in thread | previous in thread | raw e-mail | index | archive | help
--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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. :)
>=20
> There are two questions that arise with this approach:
>=20
> - 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.
>=20
> 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.
>=20
> 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.
>=20
> > 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. :)
> >=20
> > 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.
>=20
> 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
--=20
Peter Pentchev roam@space.bg roam@ringlet.net roam@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.
--8t9RHnE3ZwKMSgU+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJNGZ+GAAoJEGUe77AlJ98TqrIP/26VStwjBGhUIBwEbok3gtU+
ivrS1Hdak6GX926HCaiPS1jDYUpMpyt7OTX68AVCTDEBH5E6dEoSfhWaVpmLmsi4
hsjxsBbjrlzqTSZXNQCGJcp7q3EbGF8OoFohZT2a0bzn2+H9+Er0n5WfODkgmC3j
IGYLLtolRZCnj7nJhtJwfJr2u5/ptD27EKMkpq+Bdnh21BDUKp001GzrnEnp9Ssp
cuzAoCkHEasUgBKhN/Hc2aKT5DiYuLaoFflGmWIt7jnfJ3xJ1Jm/G6MvO4riAhGN
WbXLq2lDKJfIye95YEuKpyXTq947HExxneR9z3HfPD29Rv5J3rszhJkG5qTANw8a
SxR+uBv+ZWXDYQf6hNo8EW6hj7nPSrvsZjOvfij2zkquKi67fY/dbGr1nFUxsEO+
ASzyQqpKUzJYIpXWrbI719TxQwfTyuN/FKgmOI68UyezkfYf1gXmyBEZdZ6vMJuD
g9jZWJPGkTtyPoFidB3RjYo1wBd++Lb5nlhygHlO6C3jIef2pN3+hRki5dVF5Shx
uX/NSuijFlZwjEU48Obj3JXmRPB+Km3HvG+aK2fs41tX3nmWr/Gy80zkfUrLEjq9
m8Uk6EgumA2VoaLVu7gJkmTaVtAKXCurMVHmHM6aijdSwjdNpclNF8Mx+HDuyi9j
rMCVQvpBDy0suvvEy/0g
=ksA3
-----END PGP SIGNATURE-----
--8t9RHnE3ZwKMSgU+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101228082755.GA4381>