Re: Seeking advice with rust packing guidelines
Hey Fabio, On 11/06/2021 15.38, Fabio Valentini wrote: On Fri, Jun 11, 2021 at 6:28 AM Fabio M. Di Nitto wrote: Hey everyone, I have been reading the current guideline here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ and for the most it´s pretty clear when packaging a standalone crate / rust generated binaries (given this is my very first step into understanding rust). I am currently facing a slightly different challenge as my upstream project, a bunch of C shared libraries (also available in Fedora), will soon grow rust bindings. The rust code will be part of the normal upstream tarball / etc. that will include at that point a mix of different languages. The upstream build system already takes care to call into cargo for example and I am wondering how the current rust rpm macros are going to work with it (or viceversa). Does anyone have experience in packaging mixed sources? Could you share your spec file please (or just the srpm name ;)) Hello, I think this depends on how the upstream project works. This is totally up for discussion and changes. So far the PR I have received includes the rust bindings and a basic integration to the build system. We can change it as needed to fit the best way to deal with Rust, that´s why I am seeking advice and to make sure upstream makes it super easy for downstream to deal with those bindings. The upstream build system already takes care to call into cargo for example and I am wondering how the current rust rpm macros are going to work with it (or viceversa). What toes "the upstream build system already takes care to call into cargo" mean? For Rust packages, we only package sources, but no compiled libraries / rlib files (since there is no stable ABI). At the moment we call into cargo build to build both the bindings and the test suite to test the bindings within the current build. Good to know about sources, that´s "easy" to package. Does running "make install" (or your buildsystem's equivalent) run "cargo install" as well? I'm not even sure that this works for "source-only" libraries. Not yet. This is the point when I stopped and asked myself: How should I install it and make it ready for packaging / shipping? Keep in mind that my knowledge of rust is close to 0 at this point. I am trying to understand and build some knowledge to do the right thing. As Rich points out, the easiest solution would probably be to publish the Rust bindings separately, preferably as a standalone crate on crates.io. Crates from crates.io can usualyl be packaged with an effort of a few minutes. Manually making sure that Rust bindings from a shared source tree get installed correctly would probably be a brittle solution that is prone to break with updates to kronosnet itself or changes to the Rust macros in Fedora. Understood I think... However, *if* you want to go the route of "install everything from the shared source tree", beware that the Rust macros were only intended to work on crate sources. gotcha. I am fine with whatever everyone else is doing and do it right. I have 0 opinion (based on my 0 knowledge) on what route to take :) There are a few things you need to keep in mind: - %cargo_prep needs to be called in %prep in the crate's root directory, and will override any existing .cargo/config files. This is used to set up /usr/share/cargo/registry as crates.io replacement. - %cargo_generate_buildrequires needs to be called in %generate_buildrequires, in each crate's root directory. This will automatically generate the necessary BuildRequires for crate dependencies. - %cargo_build will try to build your Rust bindings, usually you'd want that to happen in %build - %cargo_install will copy the crate's source tree(s) to the appropriate location in /usr/share/cargo/registry so other Rust crate packages can use them. - %cargo_test will compile and run all tests that are present in the crates (usually in %check) got it. The only Fedora package that successfully integrates something similar is python-cryptography, however, this package does not ship Rust bindings, but instead contains a binary Rust plugin that the python module calls into, so you'd have to modify what that package does for your needs as well. So, TL;DR: If possible, publish the Rust bindings separately as a crate on crates.io. It should be way easier to package and maintain that way. I think we can do that :) Thanks again Fabio Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not rep
Re: Seeking advice with rust packing guidelines
On 11/06/2021 12.23, Richard W.M. Jones wrote: On Fri, Jun 11, 2021 at 06:27:19AM +0200, Fabio M. Di Nitto wrote: Hey everyone, I have been reading the current guideline here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ and for the most it´s pretty clear when packaging a standalone crate / rust generated binaries (given this is my very first step into understanding rust). I am currently facing a slightly different challenge as my upstream project, a bunch of C shared libraries (also available in Fedora), will soon grow rust bindings. The rust code will be part of the normal upstream tarball / etc. that will include at that point a mix of different languages. I maintain two such projects with Rust bindings (https://src.fedoraproject.org/rpms/libguestfs https://src.fedoraproject.org/rpms/nbdkit). We don't package the bindings in Fedora, but instead distribute the source separately (eg. https://lib.rs/crates/nbdkit) Right, I was trying to be a good upstream and also package them :P Other programs that use the bindings bundle them. It's not ideal at all, but it was the path of least resistance given the way Rust stuff is built. I can understand. I guess we will try a similar approach for knet, unless we can have the Fedora policy shed lights with those situations. The upstream build system already takes care to call into cargo for example and I am wondering how the current rust rpm macros are going to work with it (or viceversa). Does anyone have experience in packaging mixed sources? Could you share your spec file please (or just the srpm name ;)) For an example of very very mixed sources, see the libguestfs link above, although it won't help for Rust or Golang. thanks for the pointer Rich, i will take a look! Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Seeking advice with rust packing guidelines
On 11/06/2021 07.57, Robert-André Mauchin wrote: On 6/11/21 6:27 AM, Fabio M. Di Nitto wrote: Hey everyone, I have been reading the current guideline here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ and for the most it´s pretty clear when packaging a standalone crate / rust generated binaries (given this is my very first step into understanding rust). I am currently facing a slightly different challenge as my upstream project, a bunch of C shared libraries (also available in Fedora), will soon grow rust bindings. The rust code will be part of the normal upstream tarball / etc. that will include at that point a mix of different languages. The upstream build system already takes care to call into cargo for example and I am wondering how the current rust rpm macros are going to work with it (or viceversa). Does anyone have experience in packaging mixed sources? Could you share your spec file please (or just the srpm name ;)) Thanks Fabio I can't really help you, but it would be helpful to link the upstream project your are trying to build. https://github.com/kronosnet/kronosnet https://github.com/kronosnet/kronosnet/pull/338 the PR would add the rust bindings to the project. Also CCing the other Fabio who is most up to date with Rust packages. thanks! appreciated. Cheers Fabio Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Seeking advice with rust packing guidelines
Hey everyone, I have been reading the current guideline here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ and for the most it´s pretty clear when packaging a standalone crate / rust generated binaries (given this is my very first step into understanding rust). I am currently facing a slightly different challenge as my upstream project, a bunch of C shared libraries (also available in Fedora), will soon grow rust bindings. The rust code will be part of the normal upstream tarball / etc. that will include at that point a mix of different languages. The upstream build system already takes care to call into cargo for example and I am wondering how the current rust rpm macros are going to work with it (or viceversa). Does anyone have experience in packaging mixed sources? Could you share your spec file please (or just the srpm name ;)) Thanks Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On 02/11/2020 12.27, Miro Hrončok wrote: On 11/2/20 12:13 PM, Fabio M. Di Nitto wrote: On 02/11/2020 12.03, Miro Hrončok wrote: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-02.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan fabbione: numad are you sure the script is running correctly? I have never touched numad in my whole life... :) Yes, I am sure. Ok cool thanks :) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On 02/11/2020 12.03, Miro Hrončok wrote: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-02.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan fabbione: numad are you sure the script is running correctly? I have never touched numad in my whole life... :) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
help updating sheepdog in F17
Hi all, with one of the latest updates of corosync, we had to break some API/ABI. All packages have been rebuilt and they are waiting for updates to be available. I also re-built sheepdog (http://koji.fedoraproject.org/koji/buildinfo?buildID=310076) but i don´t have super powers to push the update into F17 and I have been unable to get in touch with current sheepdog maintainer (in CC). Can somebody help please? I have no interest in sheepdog myself, but i also don´t like to leave transitions unfinished. Thanks Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help updating sheepdog in F17
On 4/4/2012 12:23 PM, Michael Schwendt wrote: On Wed, 04 Apr 2012 09:23:16 +0200, FMDN (Fabio) wrote: Hi all, with one of the latest updates of corosync, we had to break some API/ABI. All packages have been rebuilt and they are waiting for updates to be available. I also re-built sheepdog (http://koji.fedoraproject.org/koji/buildinfo?buildID=310076) but i don´t have super powers to push the update into F17 and I have been unable to get in touch with current sheepdog maintainer (in CC). Can somebody help please? I have no interest in sheepdog myself, but i also don´t like to leave transitions unfinished. Hard to help there, because you've created an update ticket already https://admin.fedoraproject.org/updates/FEDORA-2012-4877 missing just the sheepdog build. If you unpushed it, any provenpackager could create a new ticket containing all packages. Editing other's tickets needs special privileges (probably limited to bodhi admins). Sheepdog update can be done in a separate update. If provenpackager can make a ticket that would suffice. I don´t/didn´t test sheepdog. Also, voting +1 on your own updates is being frowned upon. Even more so, if the stable karma threshold is just 1. We assume the update submitter is happy with the submitted builds, so that it doesn't need an explicit vote. It´s a matter of perspective really. All upstreams involved have pre-ACK the update, the builds and relative tests. There is somehow little point to set a karma to 10K and have people login/vote on something that has been done already upfront. So the +1 is the simple formality to make bodhi happy, after 24/48 hours for propagation into updates-testing and nothing has been reported by different teams. Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help updating sheepdog in F17
On 4/4/2012 1:36 PM, Daniel P. Berrange wrote: On Wed, Apr 04, 2012 at 12:23:17PM +0200, Michael Schwendt wrote: On Wed, 04 Apr 2012 09:23:16 +0200, FMDN (Fabio) wrote: Hi all, with one of the latest updates of corosync, we had to break some API/ABI. All packages have been rebuilt and they are waiting for updates to be available. I also re-built sheepdog (http://koji.fedoraproject.org/koji/buildinfo?buildID=310076) but i don´t have super powers to push the update into F17 and I have been unable to get in touch with current sheepdog maintainer (in CC). Can somebody help please? I have no interest in sheepdog myself, but i also don´t like to leave transitions unfinished. Hard to help there, because you've created an update ticket already https://admin.fedoraproject.org/updates/FEDORA-2012-4877 missing just the sheepdog build. If you unpushed it, any provenpackager could create a new ticket containing all packages. Editing other's tickets needs special privileges (probably limited to bodhi admins). Also, voting +1 on your own updates is being frowned upon. Even more so, if the stable karma threshold is just 1. We assume the update submitter is happy with the submitted builds, so that it doesn't need an explicit vote. Indeed, what is the rationale for bohdi even allowing people to +1 their own updates. Seems like it should be blocked, surely ? Truth told, in our team(s), we use this loophole to save people time in paperwork. I can only speak for myself, but when we do updates of several packages at once, we _always_ coordinate/agree/pretest and all, way before the new stuff hits Fedora. While i understand the point of karma, i see very little use of going around asking people to login/find the update/votes, etc. when can all be coordinate and driven by one person. Then again, I am not here to start another thread. I would simply like to get a working version of sheepdog in F17 or somebody to retire the package if nobody uses it anymore. Thanks Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help updating sheepdog in F17
On 4/4/2012 2:24 PM, Daniel P. Berrange wrote: On Wed, Apr 04, 2012 at 02:09:07PM +0200, Fabio M. Di Nitto wrote: On 4/4/2012 1:36 PM, Daniel P. Berrange wrote: On Wed, Apr 04, 2012 at 12:23:17PM +0200, Michael Schwendt wrote: On Wed, 04 Apr 2012 09:23:16 +0200, FMDN (Fabio) wrote: Hi all, with one of the latest updates of corosync, we had to break some API/ABI. All packages have been rebuilt and they are waiting for updates to be available. I also re-built sheepdog (http://koji.fedoraproject.org/koji/buildinfo?buildID=310076) but i don´t have super powers to push the update into F17 and I have been unable to get in touch with current sheepdog maintainer (in CC). Can somebody help please? I have no interest in sheepdog myself, but i also don´t like to leave transitions unfinished. Hard to help there, because you've created an update ticket already https://admin.fedoraproject.org/updates/FEDORA-2012-4877 missing just the sheepdog build. If you unpushed it, any provenpackager could create a new ticket containing all packages. Editing other's tickets needs special privileges (probably limited to bodhi admins). Also, voting +1 on your own updates is being frowned upon. Even more so, if the stable karma threshold is just 1. We assume the update submitter is happy with the submitted builds, so that it doesn't need an explicit vote. Indeed, what is the rationale for bohdi even allowing people to +1 their own updates. Seems like it should be blocked, surely ? Truth told, in our team(s), we use this loophole to save people time in paperwork. I can only speak for myself, but when we do updates of several packages at once, we _always_ coordinate/agree/pretest and all, way before the new stuff hits Fedora. While i understand the point of karma, i see very little use of going around asking people to login/find the update/votes, etc. when can all be coordinate and driven by one person. Then again, I am not here to start another thread. I would simply like to get a working version of sheepdog in F17 or somebody to retire the package if nobody uses it anymore. In this case you added positive karma to your own update on 2012-03-30, days before starting this thread about Sheepdog being broken. Given that we're at F17 Beta, an ABI breaking change should not have been scheduled for push to stable while you knew the Sheepdog issue was not resolved. IMHO this is an abuse of the update process. That´s not entirely correct either. corosync API/ABI change happened a long time ago (before Alpha). Sheepdog has been broken since. With the last update, the corosync API/ABI have been marked stable. sheepdog maintainer did not take action, so I decided to port sheepdog to the new API/ABI to fix it. The time lapse between the last update and my request for help is simply the time i have been waiting for sheepdog maintainer to reply to my emails. Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help updating sheepdog in F17
On 4/4/2012 2:24 PM, Daniel P. Berrange wrote: On Wed, Apr 04, 2012 at 02:09:07PM +0200, Fabio M. Di Nitto wrote: On 4/4/2012 1:36 PM, Daniel P. Berrange wrote: On Wed, Apr 04, 2012 at 12:23:17PM +0200, Michael Schwendt wrote: On Wed, 04 Apr 2012 09:23:16 +0200, FMDN (Fabio) wrote: Hi all, with one of the latest updates of corosync, we had to break some API/ABI. All packages have been rebuilt and they are waiting for updates to be available. I also re-built sheepdog (http://koji.fedoraproject.org/koji/buildinfo?buildID=310076) but i don´t have super powers to push the update into F17 and I have been unable to get in touch with current sheepdog maintainer (in CC). Can somebody help please? I have no interest in sheepdog myself, but i also don´t like to leave transitions unfinished. Hard to help there, because you've created an update ticket already https://admin.fedoraproject.org/updates/FEDORA-2012-4877 missing just the sheepdog build. If you unpushed it, any provenpackager could create a new ticket containing all packages. Editing other's tickets needs special privileges (probably limited to bodhi admins). Also, voting +1 on your own updates is being frowned upon. Even more so, if the stable karma threshold is just 1. We assume the update submitter is happy with the submitted builds, so that it doesn't need an explicit vote. Indeed, what is the rationale for bohdi even allowing people to +1 their own updates. Seems like it should be blocked, surely ? Truth told, in our team(s), we use this loophole to save people time in paperwork. I can only speak for myself, but when we do updates of several packages at once, we _always_ coordinate/agree/pretest and all, way before the new stuff hits Fedora. While i understand the point of karma, i see very little use of going around asking people to login/find the update/votes, etc. when can all be coordinate and driven by one person. Then again, I am not here to start another thread. I would simply like to get a working version of sheepdog in F17 or somebody to retire the package if nobody uses it anymore. Given that we're at F17 Beta, an ABI breaking change should not have been scheduled for push to stable while you knew the Sheepdog issue was not resolved. IMHO this is an abuse of the update process. Also forgot to mention that all updates are still in updates-testing exactly because of Beta. They are not being pushed to -updates. So the API/ABI change is simply sitting there waiting. Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help updating sheepdog in F17
On 4/4/2012 6:17 PM, Michael Schwendt wrote: On Wed, 04 Apr 2012 13:32:39 +0200, FMDN (Fabio) wrote: Sheepdog update can be done in a separate update. If provenpackager can make a ticket that would suffice. I don´t/didn´t test sheepdog. https://admin.fedoraproject.org/updates/sheepdog-0.3.0-2.fc17 Thanks for the help, very much appreciated. Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LLVM 2.9 pre-releases
On 3/18/2011 6:39 PM, Michel Alexandre Salim wrote: Greetings, LLVM 2.9 is scheduled to be released on April 3rd, and is currently in the first of hopefully two testing periods (http://llvm.org/) I'm not sure if we should be pushing this for F-15 -- the first test release was not ready in time for our alpha -- but I'll be tracking the 2.9 pre-releases in Rawhide (f16). Here are the packages that should be affected, if you know of anything else, please let me know: $ repoquery --enablerepo=rawhide-source --repoid=rawhide-source --archlist=src --whatrequires llvm-devel OpenGTL-0:0.9.15-2.fc15.src ldc-0:0.9.2-31.20110115hg1832.fc15.src pure-0:0.45-4.fc15.src You also want to check for llvm-static. atleast mesa BR on it. Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Help to solve a possible circular Requires:
On 12/03/2010 05:20 PM, James Antill wrote: On Fri, 2010-12-03 at 10:24 +0100, Fabio M. Di Nitto wrote: Hi all, I am seeking some help here to solve a possible $subject. I have been trying to find a simple alternate solution, but I just can´t see it or it´s not obvious to me. This is the situation: srpm foo 1.0 ships 2 rpm´s bar and baz. bar has a daemon inside. due to upstream split: srpm foo 1.1 now ships only bar rpm without the daemon. srpm baz 1.1 now ships 2 rpm´s, baz (exactly as in version 1.0) and baz-something that contains the bar´s daemon from 1.0. In order to avoid upgrade issues, we need to make sure that bar 1.1 will pull in baz-something 1.1 (to retain functionality), at the same time baz-something requires bar 1.1 to operate at all. There is no requirement for a strictly versioned Requires: on both sides. baz-something Requires: bar = 1.1, and bar Requires: baz-something (no version need since it´s a new rpm). The above reads more complicated than I think it is. I assume you have two problems: 1. When moving from foo-1.0 = foo-1.1 and baz-1.1, you have a package split ... this implies using versioned Obsoletes (= 1.0) on bar from baz-something. 2. In baz-something-1.1 you have a normal requires on bar-1.1 ... so just add a versioned (= 1.1) require. Hey guys, thanks for the hint in the right direction! Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Help to solve a possible circular Requires:
Hi all, I am seeking some help here to solve a possible $subject. I have been trying to find a simple alternate solution, but I just can´t see it or it´s not obvious to me. This is the situation: srpm foo 1.0 ships 2 rpm´s bar and baz. bar has a daemon inside. due to upstream split: srpm foo 1.1 now ships only bar rpm without the daemon. srpm baz 1.1 now ships 2 rpm´s, baz (exactly as in version 1.0) and baz-something that contains the bar´s daemon from 1.0. In order to avoid upgrade issues, we need to make sure that bar 1.1 will pull in baz-something 1.1 (to retain functionality), at the same time baz-something requires bar 1.1 to operate at all. There is no requirement for a strictly versioned Requires: on both sides. baz-something Requires: bar = 1.1, and bar Requires: baz-something (no version need since it´s a new rpm). From local testing, the circular Requires works just fine, both in upgrades and clean install (tested with yum and manual rpm), but I don´t like it. Is there a better way to achieve this upgrade path? Thanks Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
