Re: Idea: Ability to define dependencies between coprs (correctly)
On 10/02/2014 05:48 PM, Honza Horak wrote:
On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:
On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using this
dependent repo link we are able to build packages in coprA with dependencies
in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are not
available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be available
during build, correct buildroots would be used (no need to specify variables
$releasever and in addition, we would be able to provide correct (all) RPMs
also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build as
part of this copr, but would include also packages from copr B. That means
that when running `dnf copr enable userA/coprA`, user would not need to
install userB/coprB repository and would have all packages available.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB gets
changed (on the server's side).
What about putting the definition of the coprA on the coprB, ie at:
https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
include the definition of the repo this copr depends on (ok bad example for
this
specific copr).
This way, it's rather clear to the user that the packages are coming from two
distinct copr, there no need to change dnf and we don't mix up in one repo
packages potentially built by different people.
That does imply that existing .repo file might have to be updated.
Yeah, I like that idea, that would remove some obstacles mentioned for
solution
1) above. I'm not sure though if the depended coprs can be called the same as
the original (we would have two similar repos enabled) or we would have to
call
them differently. Just quick test does not show any issues with more repos
with
the same name.
Honza
Different repos inside a single repo file will be still shown as different
repos when installing a packages from them. Therefore should not cause any
problems.
However in thins case it might be worth deciding if such .repo should be named
in a way to express it contains also a bundle of dependent repos.
Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Idea: Ability to define dependencies between coprs (correctly)
On 10/03/2014 08:24 AM, Bohuslav Kabrda wrote:
- Original Message -
Hi all,
I have a proposal that would change how dependencies are defined in copr:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using
this dependent repo link we are able to build packages in coprA with
dependencies in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are
not available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be
available during build, correct buildroots would be used (no need to
specify variables $releasever and in addition, we would be able to
provide correct (all) RPMs also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build
as part of this copr, but would include also packages from copr B. That
means that when running `dnf copr enable userA/coprA`, user would not
need to install userB/coprB repository and would have all packages
available.
3) (And I think that I've already heard this idea from someone) I think it'd
be better to:
- Put the copr repofiles into RPMs and put all these RPMs in a single repo.
- These repofile RPMs can depend on each other.
- dnf copr enable installs an RPM from this repo.
- When a dependency between repos change, repofile RPMs will be updated. When
user runs dnf update, he will get the new repofile RPM build, which will
have dependencies changed properly - so dnf will install these, too.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB
I think that 3) is ok from this POV. The problem here can be, that in 3), dnf
would on update technically enable other copr repos without explicit user
approval. I'm not sure whether this is a problem or not, though.
Well, dnf/yum should show you what will be installed/enabled as dependencies,
so the user is kind of informed what extra repos will be installed and enabled.
gets changed (on the server's side).
Let's discuss this a bit, I'm eager to hear your opinions.
Cheers,
Honza
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Idea: Ability to define dependencies between coprs (correctly)
- Original Message -
Hi all,
I have a proposal that would change how dependencies are defined in copr:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using
this dependent repo link we are able to build packages in coprA with
dependencies in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are
not available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be
available during build, correct buildroots would be used (no need to
specify variables $releasever and in addition, we would be able to
provide correct (all) RPMs also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build
as part of this copr, but would include also packages from copr B. That
means that when running `dnf copr enable userA/coprA`, user would not
need to install userB/coprB repository and would have all packages
available.
3) (And I think that I've already heard this idea from someone) I think it'd be
better to:
- Put the copr repofiles into RPMs and put all these RPMs in a single repo.
- These repofile RPMs can depend on each other.
- dnf copr enable installs an RPM from this repo.
- When a dependency between repos change, repofile RPMs will be updated. When
user runs dnf update, he will get the new repofile RPM build, which will have
dependencies changed properly - so dnf will install these, too.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB
I think that 3) is ok from this POV. The problem here can be, that in 3), dnf
would on update technically enable other copr repos without explicit user
approval. I'm not sure whether this is a problem or not, though.
gets changed (on the server's side).
Let's discuss this a bit, I'm eager to hear your opinions.
Cheers,
Honza
--
Regards,
Slavek Kabrda
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Idea: Ability to define dependencies between coprs (correctly)
Hi all,
I have a proposal that would change how dependencies are defined in copr:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using
this dependent repo link we are able to build packages in coprA with
dependencies in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are
not available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be
available during build, correct buildroots would be used (no need to
specify variables $releasever and in addition, we would be able to
provide correct (all) RPMs also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build
as part of this copr, but would include also packages from copr B. That
means that when running `dnf copr enable userA/coprA`, user would not
need to install userB/coprB repository and would have all packages
available.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB
gets changed (on the server's side).
Let's discuss this a bit, I'm eager to hear your opinions.
Cheers,
Honza
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Idea: Ability to define dependencies between coprs (correctly)
On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using this
dependent repo link we are able to build packages in coprA with dependencies
in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are not
available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be available
during build, correct buildroots would be used (no need to specify variables
$releasever and in addition, we would be able to provide correct (all) RPMs
also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build as
part of this copr, but would include also packages from copr B. That means
that when running `dnf copr enable userA/coprA`, user would not need to
install userB/coprB repository and would have all packages available.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB gets
changed (on the server's side).
What about putting the definition of the coprA on the coprB, ie at:
https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
include the definition of the repo this copr depends on (ok bad example for this
specific copr).
This way, it's rather clear to the user that the packages are coming from two
distinct copr, there no need to change dnf and we don't mix up in one repo
packages potentially built by different people.
That does imply that existing .repo file might have to be updated.
Just a thought,
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Idea: Ability to define dependencies between coprs (correctly)
On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:
On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using this
dependent repo link we are able to build packages in coprA with dependencies
in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are not
available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be available
during build, correct buildroots would be used (no need to specify variables
$releasever and in addition, we would be able to provide correct (all) RPMs
also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build as
part of this copr, but would include also packages from copr B. That means
that when running `dnf copr enable userA/coprA`, user would not need to
install userB/coprB repository and would have all packages available.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB gets
changed (on the server's side).
What about putting the definition of the coprA on the coprB, ie at:
https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
include the definition of the repo this copr depends on (ok bad example for this
specific copr).
This way, it's rather clear to the user that the packages are coming from two
distinct copr, there no need to change dnf and we don't mix up in one repo
packages potentially built by different people.
That does imply that existing .repo file might have to be updated.
Yeah, I like that idea, that would remove some obstacles mentioned for
solution 1) above. I'm not sure though if the depended coprs can be
called the same as the original (we would have two similar repos
enabled) or we would have to call them differently. Just quick test does
not show any issues with more repos with the same name.
Honza
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Idea: Ability to define dependencies between coprs (correctly)
On Thu, Oct 02, 2014 at 05:48:20PM +0200, Honza Horak wrote:
On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:
On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using this
dependent repo link we are able to build packages in coprA with dependencies
in another coprB.
However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are not
available since coprB is not enabled.
Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be available
during build, correct buildroots would be used (no need to specify variables
$releasever and in addition, we would be able to provide correct (all) RPMs
also when *installing* coprs.
There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.
2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build as
part of this copr, but would include also packages from copr B. That means
that when running `dnf copr enable userA/coprA`, user would not need to
install userB/coprB repository and would have all packages available.
Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB gets
changed (on the server's side).
What about putting the definition of the coprA on the coprB, ie at:
https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
include the definition of the repo this copr depends on (ok bad example for
this
specific copr).
This way, it's rather clear to the user that the packages are coming from two
distinct copr, there no need to change dnf and we don't mix up in one repo
packages potentially built by different people.
That does imply that existing .repo file might have to be updated.
Yeah, I like that idea, that would remove some obstacles mentioned for
solution 1) above. I'm not sure though if the depended coprs can be called
the same as the original (we would have two similar repos enabled) or we
would have to call them differently. Just quick test does not show any
issues with more repos with the same name.
As long as they point to the same url, I don't think having multiple definition
of the same repo is a problem :)
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
