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_Ownership

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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?
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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

--
Kalev
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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


--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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 -
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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,

--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email: salimma@fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net

() ascii ribbon campaign - against html e-mail
/ www.asciiribbon.org - against proprietary attachments
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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 mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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


--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

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


--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging