1 |
On Tue, 26 Aug 2008 15:25:16 -0700 |
2 |
"Robin H. Johnson" <robbat2@g.o> wrote: |
3 |
|
4 |
> On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote: |
5 |
> > > Why do you need to identify the changes? Considering that the |
6 |
> > > checksum changes as well, is detecting change not sufficient? (or |
7 |
> > > asking the VCS for what files have changed since your last check |
8 |
> > > time). |
9 |
> > I am writing a tool that creates deb (as in Debian package format) |
10 |
> > based distributions from gentoo packages and that tool encodes the |
11 |
> > CVS revision as part of "debian revision" of the packages. So I |
12 |
> > need this part to be chronologically ordered, as opposed to have |
13 |
> > only the knowledge of whenever the file has changed or not. |
14 |
> I'd call that critically dangerous in missing some changes. |
15 |
> If I have a file in $FILESDIR, and change it, but it has the same |
16 |
> name, there is no commit to the ebuild, and your .debs won't pick up |
17 |
> changes at all. This is usually for cases with compile fixes that |
18 |
> don't need revision bumps at all, but sometimes there are also |
19 |
> changes to scripts. |
20 |
|
21 |
Yes, I know that this will not protect me against changes in a file from |
22 |
${FILESDIR} nor a change in a file in ${A}, but that was the best way I |
23 |
could think of to make debian source packages (I create as well) as |
24 |
reproducible as possible. |
25 |
|
26 |
For the source packages I create a debian/rules[1] file that basically |
27 |
calls ebuild foo.ebuild with the right options and to compile and then |
28 |
install to a temporary directory and then call some debhelper scripts |
29 |
to turn that directory into a proper .deb package. So from my |
30 |
perspective the .ebuild file can be considered part of the debian/rules |
31 |
files and because of that I really need to keep track of changes in it. |
32 |
|
33 |
And for the rest of files, I bump ( :-D ) another revision counter with |
34 |
each rebuild of the same debian source package version, so until I find |
35 |
some better way to catch changes in any bit of the source (be it the |
36 |
ebuild, files from ${A} or files from ${FILESDIR)/) I still don't have |
37 |
conflicts. |
38 |
|
39 |
> If you're making binary package .debs, I gather that you are grabbing |
40 |
> the (pre|post)(inst|rm) and setup blocks for inclusion? |
41 |
|
42 |
Yes, I certainly do. |
43 |
|
44 |
> That is an interesting use case, and would that would present a |
45 |
> problem with any VCS migration. |
46 |
> - Under SVN, you'd only have the global revision, which might not |
47 |
> uniquely identify the file. |
48 |
> - Bzr doesn't support keyword expansion in any released version. There |
49 |
> are/were plans for it in 1.7, but I haven't seen anything since the |
50 |
> first prototype. |
51 |
> - Hg supports it with an extension: |
52 |
> http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension |
53 |
> But has warnings about why it sucks |
54 |
> http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan |
55 |
> See the 'keyword update intervals' item (mainly having to touch |
56 |
> every file in the repo sometimes). |
57 |
> - Git supports only the $Id$ keyword, and expands it to the SHA1 of |
58 |
> the file, which ends up being a duplicate of the information we have |
59 |
> in the Manifest. |
60 |
|
61 |
I am aware about this problem, and unless this is explicitly taken into |
62 |
consideration on migration, I guess I'll have to keep a local database |
63 |
of "order" of ebuilds as part of the metadata associated with each |
64 |
distribution my tool creates. |
65 |
|
66 |
[1] debian/rules files is a make file that provides the right targets |
67 |
for debian tools call it and generate deb binary packages. So it |
68 |
is kind of the equivalent of .ebuild scripts for debian. |