Forum OpenACS Development: Versioning and other details in package .info files

(moving an email thread online)


We're not updating non-core modules to match the kernel - their version numbers change independently.  So if photo-album is at 4.0, and it requires acs-kernel 4.0, and then the acs-core collection goes to 5.0 so acs-kernel goes to 5.0 but photo-album is unchanged, photo-album stays at 4.0.


I just went through each of the core packages and updated their version in the APM.  Some notes I took along the way:

- The release date of each package is being updated to today when I save changes in the APM
- Some of the package info is very out of date
- There were a few packages that were missing the Primary Owner URL, and the package manager requires that info.  So I looked up the owner's email addresses at
- The list of core packages in CVS appears to be wrong:  it's notifications, not acs-notification
- For some reason,  acs-authentication/ got checked
out with no write perms.  It could be like that in CVS, too.

Now... I'm looking at a diff of my work and I see that the APM has made some unexpected changes.  Perhaps someone at Collaboraid can confirm that these are all desirable changes?  I'm not very familiar with the changes that have been made.  They are attached in a file called diff.out.

I realized while looking over the diffs that I didn't do anything with the Requires.  It looks like the APM has attempted to take care of that for me. For example, this is for acs-admin:

        •        Requires service acs-kernel, version 4.6.2 (remove)
        •        Provided by Kernel, version 5.0.0a4
        •          Provided by Kernel, version 5.0.0a5

It seems to be updating, rather than replacing, the reference to a package that has been updated.  Should I go through them all and remove and recreate these requires?


Posted by Janine Ohmer on
So the question here is, how far should I go in cleaning up these files?  And what constitutes cleaning up - do we want the multi-step requires to remain?
Posted by Don Baccus on
The multistep requires should not be there - did you generate these through the APM?  I've not seen this before.  Having them there will just slow down the resolution of dependencies when the APM goes to load the package on user sites and while I sped it up tremendously over the summer, there's no reason to needlessly slow it down!

The CVS problem (no write perms) crops up on occasion and I don't think any of us has figured out why.  It's annoying.

Posted by Jeff Davis on
The files which are checkout out without write permissions correspond to files that were watched (thats what I think anyway) you can look in the repository at the CVS/fileattr and you will find the filename in there. As for why any watches ever get created...I don't know. Oh, the CVS dir name is used since CVS could never exist in a CVS checkout except as a CVS control directory so is used in the repository as the magic state dir for watches.

In this case, it looks like simonc created a watch but I am not entirely sure of that.

$ls -l  packages/acs-authentication/CVS
total 4
-rw-rw-r--    1 simonc   cvs            47 Aug 22 06:55 fileattr

$ cat  packages/acs-authentication/CVS/fileattr        _watched=
D       _watched=
Anyway, I think we could nuke all these fileattr files and the problem would go away but I wish I knew why they got created in the first place.
Posted by Janine Ohmer on
Yes, I did these through the APM, so it must be putting in the extra requires.

I'll clean up the requires, and unless anyone objects I'll replace the more obviously bogus data (like the package owner being at Arsdigita) with generic ownership by the project;  I've seen that done in a few packages.  Then when we have maintainers for all the packages, someone can go through and update them again.

Posted by Janine Ohmer on
Ok, I have committed all my .info file edits.  I cleaned them up as best I could;  if anyone has updates, feel free to commit yourself or send them to me.
Posted by Jeff Davis on
was it intentional that the database-support bit was removed from a lot of these?  Is it not used anymore?


Posted by Janine Ohmer on
The APM removes that section when you edit the info file that way, so I removed it while editing by hand as well.

This was part of the "unexpected changes" mentioned above.

Posted by Lars Pind on
This was a change to the APM Peter made back in February or so.

His observation was valid, that this info was incorrect in most of the .info files (most packages claimed zero database-support, I believe).

So Peter figured we could infer DB-support from the existence of various data model scripts or .xql files.

However, this is in no way fool-proof, and doesn't say anything about whether the support for a given DB is complete or under development.

I'd suggest that we stick with not having database-support in those files for now, but resurrect it in 5.1.


I agree with Lars's analysis of the database support tags.