2009/7/8 Eric Smith eric@trueblade.com:

[Any reason you didn't respond to the list? I'd like to continue the discussion there. But I'm currently replying just to you.]

No, I just clicked the wrong button. Sorry. Redirecting back to the list.

Paul Moore wrote:

...

2009/7/8 Eric Smith eric@trueblade.com:

...

I agree with this. For RPM's, there's a whole other database of what files were installed. Is it really the intent that a file will be managed by multiple different installers? That I can install with RPM but remove with some python-installer (or other) tool? That way lies madness. In fact, I see RECORD as an installer-specific detail that doesn't need to be standardized at all.

I thought RECORD was to ensure that you can install with RPM, and *not* have any other random uninstaller remove your files (because you populate RECORD, and the other uninstaller uses pkgutil.get_file_users(path) to find out that you care about the file, and hence avoid deleting it).

I really don't think this is a use case worth supporting. A single file managed by multiple installers is a mess waiting to happen. RPM won't let you do it. About the only use case I can think of is namespace packages, and that can be handled by factoring out the __init__.py file into it's own install package.

Personally, I think you're right. But I have essentially zero experience with the non-Windows use cases, so I don't feel qualified to judge.

It seems to me that a lot of the fancy detecting what other people do stuff is motivated by setuptools. I'm not going to comment on that, other than to say that it may be that setuptools is generating more problems than it's solving...

...

Basically, other install methods can't read your (RPM) database, and you can't read their database. RECORD is a simple common format, providing just enough information for everyone to communicate the message "I manage this file".

The RPM uninstaller won't look at the RECORD file. I think the best we can say is that _if_ an installer wants to share state about what's installed with other installers, this is how it's done.

OK. I'd be stunned if bdist_wininst or bdist_msi ends up checking RECORD.

So that's 3 "not interested" votes.

Who's going to use the APIs based around the RECORD file? Anyone?

Seriously - who is actually going to USE any of the APIs being proposed in PEP 376? If no-one's interested, we should stop right now. Do any of the people from the summit read this list? If not, can anyone contact them and get some feedback?

Paul.