I'm wondering if it's worth creating a filesystems:ceph subproject, then moving ceph, ceph-deploy and any other ceph-only dependencies there, instead of in the base filesystems project?
Pros:
- People who only want Ceph can use the filesystems:ceph repo, and can ignore the ~100 other non-ceph packages in filesystems.
- It seems somehow cleaner to me to have all the pieces of ceph, and possibly supporting packages in a separate subproject, rather than in the grab-bag of filesystems.
Cons:
- ?
Comments? Complaints? A mailing list I should be taking this discussion to?
OK, I've created filesystems:ceph, and also filesystems:ceph:Unstable (the latter being where we can track bleeding edge upstream). I've granted maintenance rights to everyone who's a maintainer of filesystems who's ever accepted any requests against ceph or ceph-deploy. Hopefully I got the right bunch of people. If I missed anyone who wants to be up for ceph maintainership, please sing out.
I don't know why, but the web ui way will name it openSUSE_Leap_42.1 now. Possibly this was during some transition period when the codename hasn't been propagated everywhere. I'll change it.
In theory yes, a symlink in the published url, or duplicate Leap repository in the project, but both ways have drawbacks on our side and we'd have to keep them until the end of the product lifetime. I hope the inconvenience on the users' side is bearable.
I'm wondering if it's worth creating a filesystems:ceph subproject, then moving ceph, ceph-deploy and any other ceph-only dependencies there, instead of in the base filesystems project?
Pros: - People who only want Ceph can use the filesystems:ceph repo, and can ignore the ~100 other non-ceph packages in filesystems. - It seems somehow cleaner to me to have all the pieces of ceph, and possibly supporting packages in a separate subproject, rather than in the grab-bag of filesystems.
Cons: - ?
Comments? Complaints? A mailing list I should be taking this discussion to?
> Cons: - ?
The big "Con" here is that filesystems:ceph is not a Factory devel project, so we cannot submit to Factory from there :-(
I'm fine with that as well.
OK, I've created filesystems:ceph, and also filesystems:ceph:Unstable (the latter being where we can track bleeding edge upstream). I've granted maintenance rights to everyone who's a maintainer of filesystems who's ever accepted any requests against ceph or ceph-deploy. Hopefully I got the right bunch of people. If I missed anyone who wants to be up for ceph maintainership, please sing out.
Hi guys, seems the project should have openSUSE:XX.X:Update on it's build path to rebuild kernel-dependent packages in case kernel gets updated, eg.
`
Hi, is there a reason you are building against the custom name "openSUSE_42.1" instead of "openSUSE_Leap_42.1"?
I don't know why, but the web ui way will name it openSUSE_Leap_42.1 now. Possibly this was during some transition period when the codename hasn't been propagated everywhere. I'll change it.
Thank you very much!
This lead to zypper giving me: File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/filesystems/openSUSE_42.1/'
I edited /etc/zypp/repos.d/filesystems.repo and inserted the "Leap_". Now it works again.
Just out of curiosity: Isn't there a way to make such a transition without breaking the users repo-configs?
In theory yes, a symlink in the published url, or duplicate Leap repository in the project, but both ways have drawbacks on our side and we'd have to keep them until the end of the product lifetime. I hope the inconvenience on the users' side is bearable.
Key Expires: Wed 20 Jul 2016 05:34:19 PM MSK (expires in 12 days)
Any reaction? 1 day left…
Key has been extended, Key Expires: Thu 27 Sep 2018 04:36:42 PM CEST
Thank you!
And how does zypper get the new key?