Gentoo Archives: gentoo-dev

From: Bernd Steinhauser <gentoo@×××××××××××××××××.de>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] scm eclasses/ebuilds and revision logging
Date: Sat, 12 Jan 2008 03:10:13
1 Hi,
3 this is sth. that has been brought up in the KDE4 forums thread and on
4 irc. The thing is, that if you're using a live ebuild you might very
5 likely run into bugs, that have been introduced in a newer revision.
6 Now when you get in touch with upstream about that bug it might be very
7 useful if you can tell them, that you know, that a specific version in
8 the past worked. The idea was now to add the ability to the scm eclasses
9 to do this automatically.
10 So after installation then sth. like this
11 ${CAT}/${P} merged at revision (or commit) ${REVISION}
12 to a file like /var/log/portage/scm.log.
13 Now I'm sure there are a few dirty ways to achieve this, but I wonder if
14 there is an easy and clean way to do this?
16 The problem is (I think so), that you can't just write sth. to / because
17 of the sandbox, so there needs to be a way to get around that, and it
18 should also happen after installation (post_inst).
20 Now if anyone wonders if this might even be useful for the distributed
21 scm's, I do think so. Because of course if you merge sth. from another
22 tree, or your ebuild repo_uri fetches from a local dir, then you might
23 have _other_ commit hashes than upstream, but at least you can then look
24 into your own repo and tell them, when that was and what happened since
25 then.
27 I'm aware of the fact, that the revision of the currently installed
28 package is part of the environment and that is saved, but I'm not only
29 interested in the revision of the currently installed version, but also
30 in the revision of the previously installed version. Just wanted to
31 emphasize that again. ;)
33 Hope someone comes up with some good ideas. ;)
35 Greetings,
36 Bernd
37 --
38 gentoo-dev@l.g.o mailing list