My package gtkhash can now build both against gtk2 and gtk3. I am about to package the two versions as gtkhash and gtkhash3, but both packages would share one file, /usr/share/gtkhash/gtkhash.xml.
You can install both packages at the same time, at least here on F15 it works fine. However it is not allowed by the packaging guidelines: "Packages must not own files already owned by other packages." [1]
I wonder if this rule is still needed. I know I'd loose backward compatibility with older rpm versions, but I don't want make a gtkhash-common package for only a single file. Can we allow multiple file ownership, at least when a file comes from the same srpm?
Regards, Christoph
[1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Owner...
On Sun, Jan 29, 2012 at 8:04 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
I wonder if this rule is still needed. I know I'd loose backward compatibility with older rpm versions, but I don't want make a
I agree that a -common subpackage is silly for this, but are any of the RPM versions that this *wouldn't* work with still in supported releases? (I think not, I thought that problem was solved in ancient times - well ancient as far as Fedora timelines!)
The only one I'd be concerned with is RHEL5, but I think even that works right, no?
Am Sonntag, den 29.01.2012, 23:38 -0500 schrieb Jon Stanley:
On Sun, Jan 29, 2012 at 8:04 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
I wonder if this rule is still needed. I know I'd loose backward compatibility with older rpm versions, but I don't want make a
I agree that a -common subpackage is silly for this, but are any of the RPM versions that this *wouldn't* work with still in supported releases?
Not in Fedora.
The only one I'd be concerned with is RHEL5, but I think even that works right, no?
I haven't tested it, but based on my experience with multi-arch file conflicts I *guess* it will not work on RHEL 5.
Regards, Christoph
On 01/30/2012 02:31 PM, Christoph Wickert wrote:
Am Sonntag, den 29.01.2012, 23:38 -0500 schrieb Jon Stanley:
On Sun, Jan 29, 2012 at 8:04 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
I wonder if this rule is still needed. I know I'd loose backward compatibility with older rpm versions, but I don't want make a
I agree that a -common subpackage is silly for this, but are any of the RPM versions that this *wouldn't* work with still in supported releases?
Not in Fedora.
The only one I'd be concerned with is RHEL5, but I think even that works right, no?
I haven't tested it, but based on my experience with multi-arch file conflicts I *guess* it will not work on RHEL 5.
Sharing identical files between packages has always been allowed in rpm, that's not an issue.
The bugs in RHEL 5 (and older) have to do with conflicts NOT getting reported in some situations, notably on multilib systems when packages with conflicting files get installed in a single transaction the conflicts go ignored, but when installed in separate transactions conflicts are raised on the same files.
- Panu -
Am Montag, den 30.01.2012, 15:06 +0200 schrieb Panu Matilainen:
On 01/30/2012 02:31 PM, Christoph Wickert wrote:
Am Sonntag, den 29.01.2012, 23:38 -0500 schrieb Jon Stanley:
On Sun, Jan 29, 2012 at 8:04 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
I wonder if this rule is still needed. I know I'd loose backward compatibility with older rpm versions, but I don't want make a
I agree that a -common subpackage is silly for this, but are any of the RPM versions that this *wouldn't* work with still in supported releases?
Not in Fedora.
The only one I'd be concerned with is RHEL5, but I think even that works right, no?
I haven't tested it, but based on my experience with multi-arch file conflicts I *guess* it will not work on RHEL 5.
Sharing identical files between packages has always been allowed in rpm, that's not an issue.
Thanks for this clarification, Panu.
Before I go ahead and commit my changes, can I have an 'official' statement from the packaging committee? Should I file a trac ticket?
Regards, Christoph
On Mon, Jan 30, 2012 at 10:05:33PM +0100, Christoph Wickert wrote:
Am Montag, den 30.01.2012, 15:06 +0200 schrieb Panu Matilainen:
On 01/30/2012 02:31 PM, Christoph Wickert wrote:
Am Sonntag, den 29.01.2012, 23:38 -0500 schrieb Jon Stanley:
On Sun, Jan 29, 2012 at 8:04 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
I wonder if this rule is still needed. I know I'd loose backward compatibility with older rpm versions, but I don't want make a
I agree that a -common subpackage is silly for this, but are any of the RPM versions that this *wouldn't* work with still in supported releases?
Not in Fedora.
The only one I'd be concerned with is RHEL5, but I think even that works right, no?
I haven't tested it, but based on my experience with multi-arch file conflicts I *guess* it will not work on RHEL 5.
Sharing identical files between packages has always been allowed in rpm, that's not an issue.
Thanks for this clarification, Panu.
Before I go ahead and commit my changes, can I have an 'official' statement from the packaging committee? Should I file a trac ticket?
Yes, please do -- I can't think of a reason we wouldn't update the guidelines to allow this usage but I'm not the only FPC member and someone else on the Committee may remember some other problem thatI don't.
-Toshio
Am Montag, den 30.01.2012, 13:34 -0800 schrieb Toshio Kuratomi:
On Mon, Jan 30, 2012 at 10:05:33PM +0100, Christoph Wickert wrote:
Should I file a trac ticket?
Yes, please do --
Done. https://fedorahosted.org/fpc/ticket/138
Regards, Christoph
On 01/30/2012 01:31 PM, Christoph Wickert wrote:
Am Sonntag, den 29.01.2012, 23:38 -0500 schrieb Jon Stanley:
On Sun, Jan 29, 2012 at 8:04 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
I wonder if this rule is still needed. I know I'd loose backward compatibility with older rpm versions, but I don't want make a
I agree that a -common subpackage is silly for this, but are any of the RPM versions that this *wouldn't* work with still in supported releases?
Not in Fedora.
The only one I'd be concerned with is RHEL5, but I think even that works right, no?
I haven't tested it, but based on my experience with multi-arch file conflicts I *guess* it will not work on RHEL 5.
But RHEL 5 shouldn't really get gtk3 packages anyway, right?
Regards,
Am Montag, den 30.01.2012, 21:46 +0100 schrieb Michel Alexandre Salim:
On 01/30/2012 01:31 PM, Christoph Wickert wrote:
Am Sonntag, den 29.01.2012, 23:38 -0500 schrieb Jon Stanley:
The only one I'd be concerned with is RHEL5, but I think even that works right, no?
I haven't tested it, but based on my experience with multi-arch file conflicts I *guess* it will not work on RHEL 5.
But RHEL 5 shouldn't really get gtk3 packages anyway, right?
Good point. ;)
Regards, Christoph
On 01/30/2012 03:04 AM, Christoph Wickert wrote:
My package gtkhash can now build both against gtk2 and gtk3. I am about to package the two versions as gtkhash and gtkhash3, but both packages would share one file, /usr/share/gtkhash/gtkhash.xml.
The question about multiple file ownership is interesting and certainly useful for people who want to ship parallel installable gtk2 and gtk3 versions of a library, but ...
... gtkhash is an application. Why would an user want two copies of the same app, compiled against different versions of GTK+?
For Python, we even have a guideline to avoid packaging Python 2 and Python 3 versions of the same executable, leaving it up to the maintainers to decide when to migrate apps over: https://fedoraproject.org/wiki/Packaging:Python#Guidelines
Am Montag, den 30.01.2012, 10:29 +0200 schrieb Kalev Lember:
... gtkhash is an application. Why would an user want two copies of the same app, compiled against different versions of GTK+?
I agree there hardly is any reason, yet though we cannot prevent it and therefor it needs to be sane packaging-wise.
Regards, Christoph
Kalev Lember (kalevlember@gmail.com) said:
On 01/30/2012 03:04 AM, Christoph Wickert wrote:
My package gtkhash can now build both against gtk2 and gtk3. I am about to package the two versions as gtkhash and gtkhash3, but both packages would share one file, /usr/share/gtkhash/gtkhash.xml.
The question about multiple file ownership is interesting and certainly useful for people who want to ship parallel installable gtk2 and gtk3 versions of a library, but ...
... gtkhash is an application. Why would an user want two copies of the same app, compiled against different versions of GTK+?
We wouldn't. Although we have apps that build separate GTK and QT frontends, so I suppose there's some precedence. But it's still a bad idea.
Bill
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Christoph Wickert -
Jon Stanley -
Kalev Lember -
Michel Alexandre Salim -
Panu Matilainen -
Toshio Kuratomi