On 01/20/2018 06:53 PM, Stephen John Smoogen wrote: > On 19 January 2018 at 22:53, Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> >> >> On 01/19/2018 10:39 PM, Reindl Harald wrote: >>> >>> >>> [harry@srv-rhsoft:~]$ cat /etc/yum.repos.d/koji.repo >>> [koji] >>> name=Koji Repo >>> baseurl=https://koji.fedoraproject.org/repos/f$releasever-build/latest/$basearch/ >>> enabled=0 >>> skip_if_unavailable=1 >>> gpgcheck=0 >>> sslverify=0 >> >> Thanks! >> I didn't know about this, but it's not exactly what I'm looking for because that seems >> to includ everything that has been built. I'm looking more specifically for just a repo >> with a particular rpm in it. So for example. I currently want to test the new grub2 update >> for f27, but I only want to test that update and I want to compose a new ostree with it. If >> I use the repo you provided then I get all new latest built packages included. >> >> Another reason to have the feature I request is so that scratch builds can be easily tested. >> > > Reasons for not doing this in the past were: > 1. Extra load on koji for downloading for software to developers. Koji > has a complex caching system which is finicky. Making it more friendly > for builders makes it less friendly for users. Making it more friendly > for users makes it worse for builders. Weird. The caching problem sounds like something we should fix? Easier said than done, right? > 2. Extra software to break and needing support from admins to track > down. We already get a daily set of "why did my scratch build not show > up?" Every time createrepo blows up it is going to cause problems that > need to be dealt with. Is createrepo buggy? Wouldn't we see this in copr too if it was a big problem? > 3. Extra disk space on something which is running at 90+% of N TB most > of the time. You are looking at a repository for every package all the > time.. several hundred thousand repositories. The metadata is around 32K (although probably don't need both the xml and sqlite), but yes, several hundred thousand of them would add up. > 4. Tight release schedules on trying to deliver all the other things > which means we can't implement the cleanups we have put off for N > months because we needed one more thing added. This is a problem that I'm familiar with. I'm not saying we have to deliver a change like this, just that I'd like to discuss it. > 5. People wanting larger and larger sub repositories. One of the > reasons copr got built was because people thought they only needed 1 > package but it quickly became "I need these 12 packages to actually > test this 1 thing". You could have 12 repos activated with 12x the > load on the koji server.. or you could have 1 repo with those 12 > packages in it. And we'd have to download, import and build those 12 packages all over again in copr. There is still load, just moved around. > > I can only look at this and say "We already have a tool for this.. its > called copr" If copr does not have something that works for ostree, it > would be better to work on getting it there. This isn't really ostree specific. It was just an example I gave. This should apply for any time of release artifact that requires a yum repository as input (kickstart, lorax, ostree, live-media-creator, etc). Dusty _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
