https://github.com/ilbers/hello conflicts with upstream hello

https://github.com/ilbers/hello conflicts with upstream hello

[Henning Schild]

Hi,

i am building apt-get source support for Isar and am using "hello" as
an example application. Turn out that the upstream hello package
places /usr/bin/hello and example-hello from isar is doing the same.

I suggest to update example-hello to choose another binary name and
resolve the collision.

My series to Isar will just remove example-hello for now, it should be
re-added once the issue is solved.

Henning

Re: https://github.com/ilbers/hello conflicts with upstream hello

[Baurzhan Ismagulov]

On Thu, Jan 17, 2019 at 04:03:01PM +0100, Henning Schild wrote:
> i am building apt-get source support for Isar and am using "hello" as
> an example application. Turn out that the upstream hello package
> places /usr/bin/hello and example-hello from isar is doing the same.
> 
> I suggest to update example-hello to choose another binary name and
> resolve the collision.

Conflicting packages are explicitly allowed in Debian. How can we reproduce
your problem with /usr/bin/hello?


> My series to Isar will just remove example-hello for now, it should be
> re-added once the issue is solved.

I don't have anything against renaming the binary to e.g. hello-isar, but I
think the suggested approach is an unnecessary overkill.


With kind regards,
Baurzhan.

Re: https://github.com/ilbers/hello conflicts with upstream hello

[Henning Schild]

Am Thu, 17 Jan 2019 16:28:09 +0100
schrieb Baurzhan Ismagulov <ibr@radix50.net>:

> On Thu, Jan 17, 2019 at 04:03:01PM +0100, Henning Schild wrote:
> > i am building apt-get source support for Isar and am using "hello"
> > as an example application. Turn out that the upstream hello package
> > places /usr/bin/hello and example-hello from isar is doing the same.
> > 
> > I suggest to update example-hello to choose another binary name and
> > resolve the collision.  
> 
> Conflicting packages are explicitly allowed in Debian. How can we
> reproduce your problem with /usr/bin/hello?

Yes, but conflicts that are known are mentioned in the metadata.
(debian/control)
So apt sees it before dpkg unpacks it and finds it.

I just sent a series that shows the problem. You can also see it if you
IMAGE_INSTALL=example-hello and IMAGE_PREINSTALL=hello

> > My series to Isar will just remove example-hello for now, it should
> > be re-added once the issue is solved.  
> 
> I don't have anything against renaming the binary to e.g. hello-isar,
> but I think the suggested approach is an unnecessary overkill.

That or the metadata should know about the conflict. We can not change
upstream metadata, maybe one side is good enough.

One way or another. My series adds the feature to rebuild an upstream
package, and hello is a very good example for that. A conflict would
mean we could not test example-hello and hello in the same image, so
avoiding the conflict will be useful for that case and not overkill.

Henning

> 
> With kind regards,
> Baurzhan.
> 

Re: https://github.com/ilbers/hello conflicts with upstream hello

[Baurzhan Ismagulov]

On Thu, Jan 17, 2019 at 05:10:02PM +0100, Henning Schild wrote:
> Yes, but conflicts that are known are mentioned in the metadata.
> (debian/control)
> So apt sees it before dpkg unpacks it and finds it.

Conflicts: isn't the only way to handle various kinds of interoperability
problems that arise in a large distribution like Debian. There are also
diversions, which allow installing packages with conflicting files by renaming
them in a controlled way after installation.


> I just sent a series that shows the problem. You can also see it if you
> IMAGE_INSTALL=example-hello and IMAGE_PREINSTALL=hello

I see, thanks.

I think we should use this opportunity to also rename the source package to
hello-isar to avoid conflicts with apt-get source hello.


> That or the metadata should know about the conflict. We can not change
> upstream metadata, maybe one side is good enough.

Conflicts: on the Isar side would be enough to make the packages incompatible,
but apt-get installing example-hello after hello would fail.


> One way or another. My series adds the feature to rebuild an upstream
> package, and hello is a very good example for that. A conflict would
> mean we could not test example-hello and hello in the same image, so
> avoiding the conflict will be useful for that case and not overkill.

I agree that using upstream hello would be nice. An alternative could be
building e.g. arc for the time being. In parallel, Maxim has started fixing
example-hello. I'd prefer merging your code without breaking example-hello.


With kind regards,
Baurzhan.

Re: https://github.com/ilbers/hello conflicts with upstream hello

[Henning Schild]

Am Thu, 17 Jan 2019 17:54:40 +0100
schrieb Baurzhan Ismagulov <ibr@radix50.net>:

> On Thu, Jan 17, 2019 at 05:10:02PM +0100, Henning Schild wrote:
> > Yes, but conflicts that are known are mentioned in the metadata.
> > (debian/control)
> > So apt sees it before dpkg unpacks it and finds it.  
> 
> Conflicts: isn't the only way to handle various kinds of
> interoperability problems that arise in a large distribution like
> Debian. There are also diversions, which allow installing packages
> with conflicting files by renaming them in a controlled way after
> installation.
> 
> 
> > I just sent a series that shows the problem. You can also see it if
> > you IMAGE_INSTALL=example-hello and IMAGE_PREINSTALL=hello  
> 
> I see, thanks.
> 
> I think we should use this opportunity to also rename the source
> package to hello-isar to avoid conflicts with apt-get source hello.

In that case is might also be a good idea to align the PN with the
changed name. hello -> hello-isar and example-hello > hello-isar

> > That or the metadata should know about the conflict. We can not
> > change upstream metadata, maybe one side is good enough.  
> 
> Conflicts: on the Isar side would be enough to make the packages
> incompatible, but apt-get installing example-hello after hello would
> fail.
> 
> 
> > One way or another. My series adds the feature to rebuild an
> > upstream package, and hello is a very good example for that. A
> > conflict would mean we could not test example-hello and hello in
> > the same image, so avoiding the conflict will be useful for that
> > case and not overkill.  
> 
> I agree that using upstream hello would be nice. An alternative could
> be building e.g. arc for the time being. In parallel, Maxim has
> started fixing example-hello. I'd prefer merging your code without
> breaking example-hello.

I am not in a hurry with that being merged. We could just drop the
patch that currently removes example-hello from the build, after the
renaming is done.

Henning

> 
> With kind regards,
> Baurzhan.
>