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

1: Versioning and other details in package .info files

Posted by Joel Aufrecht on 11/03/03 07:30 PM

(moving an email thread online)

Joel:

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.

Janine:

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 openacs.org
- The list of core packages in CVS appears to be wrong: it's notifications, not acs-notification
- For some reason, acs-authentication/acs-authentication.info 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?

(https://openacs.org/doc/openacs-HEAD/packages.html)

2: Re: Versioning and other details in package .info files (response to 1)

Posted by Janine Ohmer on 11/06/03 09:17 PM

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?

3: Re: Versioning and other details in package .info files (response to 1)

Posted by Don Baccus on 11/07/03 12:24 AM

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.

4: Re: Versioning and other details in package .info files (response to 3)

Posted by Jeff Davis on 11/07/03 01:08 AM

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
Facs-authentication.info        _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.

5: Re: Versioning and other details in package .info files (response to 1)

Posted by Janine Ohmer on 11/07/03 03:59 PM

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.

6: Re: Versioning and other details in package .info files (response to 1)

Posted by Janine Ohmer on 11/10/03 05:40 PM

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.

7: Re: Versioning and other details in package .info files (response to 6)

Posted by Jeff Davis on 11/10/03 06:15 PM

was it intentional that the database-support bit was removed from a lot of these? Is it not used anymore?

cf http://cvs.openacs.org/cvs/openacs-4/packages/news-aggregator/news-aggregator.info?r1=1.5&r2=1.4

8: Re: Versioning and other details in package .info files (response to 1)

Posted by Janine Ohmer on 11/10/03 06:57 PM

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.

9: Re: Versioning and other details in package .info files (response to 1)

Posted by Lars Pind on 11/11/03 09:40 AM

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.

/Lars

10: Re: Versioning and other details in package .info files (response to 1)

Posted by Peter Marklund on 11/11/03 10:55 AM

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