(05:02:07 PM) hhorak: hi, scl fans..
(05:04:13 PM) jorton: hiya!
(05:05:04 PM) dustymabe: anyone know what the qcow2c image is on this page?
(05:05:07 PM) hhorak: a good news for beginning -- the scratch builds already work and it seems the things go quite well with tooling.. the missing part is now the lookaside cache connection..
(05:05:21 PM) dustymabe: http://cloud.centos.org/centos/7/images/
(05:06:40 PM) hhorak: we should also get some scripts to handle buildroots on our own, at least that's the plan according the discussions with centos gurus this week.. Thanks guys, btw.
(05:06:41 PM) bbankes [~bbankes@50-200-100-242-static.hfc.comcastbusiness.net] entered the room.
(05:06:42 PM) tmclaugh[work] [~tmclaugh@64.119.157.115] entered the room.
(05:06:42 PM) jorton: hhorak: I have been away so haven't had time to try my CentOS credentials... you have builds working?
(05:06:42 PM) rvokal [~radek@ip-78-45-36-249.net.upcbroadband.cz] entered the room.
(05:06:55 PM) jorton: I saw there are php56 & thermostat imports
(05:07:08 PM) alphacc: hhorak: we will need to discuss the git repo layout (to keep compatibility with centpkg)
(05:07:51 PM) RemiFedora: php56 ? not by me
(05:08:23 PM) hhorak: jorton: yes, I built mariadb100.. but what you saw was probably the downstream auto-synced packages..
(05:08:47 PM) hhorak: jorton: or maybe the empty git repos..
(05:08:53 PM) jorton: ah, might be that :)
(05:09:19 PM) hhorak: alphacc: ok, we may open it up here. is there an issue with the current approach?
(05:09:26 PM) chorrell left the room ("Textual IRC Client: www.textualapp.com").
(05:09:33 PM) straylen left the room (quit: Quit: Leaving.).
(05:10:21 PM) alphacc: hhorak: yes cause our approach is a bit different than fedora. We have a SPEC and SOURCES dir and metadata has a different naming convention
alefattorini alphacc 
(05:11:02 PM) alphacc: hhorak: you can check any rpm for teh exact layout on git.c.o
(05:11:18 PM) hhorak: alphacc: I saw that and hoped we'll be able to use the fedora-style, since the cherry-picking and merging would be easier
(05:12:01 PM) hhorak: alphacc: is it a hard requirement in centos?
(05:12:04 PM) alphacc: hhorak: ok then to be discussed, I have no strong opinion but we need to valiate few things with centpkg devs
(05:12:13 PM) mboeru left the room (quit: Remote host closed the connection).
(05:12:49 PM) MerlinTHP: There's a lot of packages in git.centos.org in the centos SCM style, so changing would be problematic.
(05:12:59 PM) MerlinTHP: All of the RHEL 7 sources, for example.
(05:13:09 PM) hhorak: alphacc: is it issue only for centpkg? or is there some other tool that could be problem as well?
(05:13:25 PM) MerlinTHP: And now that other RHEL rebuilds like SL are used to the current layout, making everyone change would be rude.
(05:14:09 PM) hhorak: MerlinTHP: but centpkg is based on pyrpkg that knows fedora-style, couldn't it be somehow universal?
(05:14:12 PM) alphacc: MerlinTHP: I was thinking about supporting also fedora layout, but we need to evaluate the impact, correct. At this time koji default to fedora layout if SOURCES dir doesn't exist.
(05:14:38 PM) bstinson: hhorak: not exactly, we had to rip chunks of rpkg out to support our layout
(05:14:58 PM) alphacc: hi bstinson ; ok it's what I thought
(05:15:04 PM) kbsingh: worth noting that you can do whatever you want in the upstreams repo
(05:15:21 PM) kbsingh: its the ones under /rpms that need to be centos layout
(05:15:26 PM) MerlinTHP: alphacc: hm, ok
(05:15:42 PM) kbsingh: its also the only place you can release rpms from
(05:15:48 PM) fabian_a [~fab@147.87.47.217] entered the room.
(05:15:55 PM) alphacc: MerlinTHP: I am happy to have one to rule them all, less administration.
(05:16:02 PM) kbsingh: so if you want to release stuff it needs to be in centos layout
(05:16:54 PM) sbonazzo left the room (quit: Quit: Leaving.).
(05:17:27 PM) hhorak: kbsingh: so we would be able to build rpms but not release them with the fedora layout?
(05:18:17 PM) hhorak: what actually means to release them?
(05:18:25 PM) hhorak: creating an official repo?
(05:18:40 PM) kbsingh: if koji supports it. looks like centpkg does not
(05:19:09 PM) kbsingh: i dont think we will spend any tome on making that format work
(05:19:09 PM) kbsingh: plus with non text you dont have a choice at all. the sources file will not get parsed
(05:20:00 PM) kbsingh: hhorak: signing and putting on mirror.centos.org
(05:20:12 PM) wolfy left the room (quit: Quit: wolfy).
(05:22:01 PM) gholms: Why the new layout, anyway?
(05:22:52 PM) hhorak: gholms: because it's important to be able to cherry-pick / merge with/from fedora-like repository if we want to do upstream development
(05:23:19 PM) gholms: No, I mean why does *centos* have a new layout.
(05:23:20 PM) ***hhorak may miss some git tricks how to cherry-pick & change path
(05:24:48 PM) drag00n [sid24865@pdpc/supporter/active/drag00n] entered the room.
(05:24:48 PM) Evolution: gholms: it's the way we've had it structured for a while. just public now.
(05:24:48 PM) gholms: I see.
(05:24:48 PM) Evolution: I'm not sure the fedora details were public/widely known when we started
alefattorini alphacc 
(05:26:08 PM) Evolution: one-layout-to-rule-them-all would be easier for cross-distro stuff certainly, but that means some fairly significant changes on our end iirc.
(05:26:08 PM) Evolution: that's more kbsingh's area
(05:26:08 PM) mbooth [~mbooth@redhat/mbooth] entered the room.
(05:26:52 PM) MerlinTHP: Including, now, every other RHEL-7-source-consuming-distro, and whatever releng magic inside Red Hat pushes RHEL 7 sources to g.c.o.
(05:27:14 PM) hhorak: Evolution: so, I understanding like making the tools universal is not doable.
(05:29:26 PM) Evolution: hhorak: it's *doable*, but with effort. and likely torches and pitchforks from the likes of SL and others.
evilissimo Evolution 
(05:30:11 PM) hhorak: Evolution: ok
(05:30:52 PM) ***alphacc has to run bbl
(05:31:09 PM) ***hhorak will discuss with maintainers (future users of this git) what it means to us and will follow-up on ML.
(05:31:58 PM) Evolution: hhorak: kbsingh and mikem are pretty much the masters of all things git for us, so they'd be able to answer and make decisions.
(05:32:25 PM) bstinson: hhorak: one workflow that might work is to cherry-pick in a repo outside /rpms/ and generate an SRPM, when you're ready to build and release in the CBS you can do `centpkg import` (feature coming soon) in the /rpms/ repo
(05:33:09 PM) hhorak: bstinson: that sounds interesting
(05:34:07 PM) Evolution: bstinson: I applaud your willingness to throw yourself under the bus like that
(05:34:14 PM) Evolution: ;-)
(05:34:26 PM) gholms: It also runs the risk of obliterating existing changes, so be careful.
(05:34:34 PM) bstinson: heh i should say, s/feature/feature unmasking/
(05:34:45 PM) gholms: We've run into that in Fedora a few times.
(05:35:09 PM) Evolution: yeah. we're going to have some growing pains as things open up
(05:35:11 PM) bstinson: it's already in rpkg but needs a lot of work (more sharp edges with the layout that need to be ironed out)
(05:35:18 PM) Evolution: and you guys are some of the first in the door, so...
(05:38:47 PM) jorton: is there something I can read to get up to speed on the current state of centpkg, bstinson ?
(05:39:34 PM) bstinson: jorton: the dev repo is here: https://git.centos.org/summary/centpkg.git
(05:40:05 PM) bstinson: i haven't had a chance to put up testing docs yet, but it's built and available for EL7 in koji
(05:43:48 PM) jorton: bstinson: ok thanks
(05:44:05 PM) ***RemiFedora we'll need a fedora build...
(05:44:07 PM) hhorak: so, there was also another thing I wanted to discuss here, the prefixes for the downstream and for the upstream collections.. hopefully langdon is already available since he might have some ideas..
redkilian reetp RemiFedora 
(05:44:26 PM) ***langdon waves
(05:44:54 PM) hhorak: langdon: let's wait a sec, RemiFedora seems to have something..
(05:45:20 PM) hhorak: RemiFedora: you mean building fedora builds from centos git?
(05:45:22 PM) RemiFedora: hhorak, no, just a feeling about centpkg for fedora users
(05:45:35 PM) hhorak: RemiFedora: ah, ok :)
(05:45:53 PM) hhorak: RemiFedora: I got el7 build running on my F20..
(05:46:03 PM) hhorak: without any issues..
(05:46:49 PM) hhorak: langdon: I think you can, sorry for stopping you :)
(05:49:14 PM) langdon: ok
(05:50:14 PM) langdon: so.. we have been discussing naming of scls to meet many needs .. 1) separate rh driven/shipped scls from other communities 2) not cause huge pain on people writing dependent collections 3) not stomping on existing (non-scl) package names
(05:50:25 PM) langdon: roughly..
(05:51:04 PM) mattgriffin left the room (quit: Quit: My MacBook Pro has gone to sleep. ZZZzzz…).
(05:52:17 PM) langdon: what we are thinking is "scls that ship with RHT products will have an 'rh-' in front of them, no matter what platform they are shipping on"
(05:52:31 PM) ***langdon also on another call.. so slow to type.. apologies..
(05:53:20 PM) langdon: so.. if the rh- is in front it solves the points above .. but also allows the wider community to make their own scls with their own prefixes..
(05:53:24 PM) langdon: does that make sense?/
(05:54:14 PM) fabian_a left the room (quit: Ping timeout: 250 seconds).
(05:56:01 PM) jfilak [~jfilak@176.74.128.58] entered the room.
(05:58:03 PM) hhorak: langdon: now I'm not sure if we made some decision about the upstream prefix -- that would be rh- as well for collections that will land in rhscl in the future, or something else? 
(05:58:25 PM) mattgriffin [~textual@99-181-54-51.lightspeed.rcsntx.sbcglobal.net] entered the room.
(05:58:34 PM) zeit_geist [~ip@p200300461D07FCB2F52883D854ACF8BA.dip0.t-ipconnect.de] entered the room.
(06:00:38 PM) langdon: hhorak, it would be for any scl that rhscl ships.. so in rhscl (on rhel) it would be called rh-python34 .. that rebuild of that collection for centos would also be rh-python34 .. but if "bob" wanted to do a better/lighter/different version of python34 for centos/rhel/and sci linux .. they would call it bob-python34 to distinguish..
(06:01:32 PM) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects.
(06:03:05 PM) The topic for #centos-devel is: CentOS Developers and Contributors room | If you have questions regarding CentOS please see #centos
(06:03:05 PM) Topic for #centos-devel set by z00dax!~kbsingh@chakra.karan.org at 09:26:30 AM on 12/11/2012
(06:03:18 PM) hhorak1: langdon: sorry, connection failure
(06:04:00 PM) RemiFedora left the room (quit: Remote host closed the connection).
(06:04:17 PM) langdon: hhorak1, did you see my last 2 lines
(06:04:18 PM) langdon: ?
(06:04:34 PM) hhorak1: langdon: I see one about bob..
(06:04:40 PM) hhorak left the room (quit: Ping timeout: 244 seconds).
(06:05:07 PM) ***langdon sending pm
(06:05:10 PM) You are now known as hhorak
(06:05:54 PM) RemiFedora [~remi@2a01:e35:2f18:2790:d63d:7eff:fee3:e1a6] entered the room.
(06:06:20 PM) RemiFedora: sorry
(06:06:36 PM) kbsingh: I dont see why we need a prefix to a collection name
(06:07:09 PM) Evolution: kbsingh: because there might be multiple 'ruby200' packages provided by different orgs.
(06:07:38 PM) langdon: kbsingh, and one that is native (vs scl)
(06:08:33 PM) Evolution: the install is already namespaced with /opt/rh  currently.
(06:08:41 PM) Evolution: this just makes the package reflect that a bit more cleanly.
(06:09:16 PM) Evolution: there are a couple scientific tools that use python27 pretty heavily, but with different build options.
(06:09:21 PM) kbsingh: isnt this what the dist tag solves
(06:09:26 PM) hhorak: the rh in /opt is also to correspond with FHS that requires vendor under /opt
(06:09:31 PM) dcantrell left the room (quit: Remote host closed the connection).
(06:10:04 PM) kbsingh: can that FHS req be abstracted away from the scl itself
(06:10:24 PM) Evolution: kbsingh: not really. dist tags don't let you install the same thing over and over.
(06:10:27 PM) Evolution: this would.
(06:10:54 PM) Evolution: so you'd have 'commercial-python27', rh-python27, etc.
(06:10:55 PM) kbsingh: if there is no common content in the rpm, dist tags would work too
(06:11:02 PM) blip [~dewey@unaffiliated/blip] entered the room.
(06:11:21 PM) kbsingh: and if there is common content in the files, even namespace overload wont work
(06:11:31 PM) BRLX left the room (quit: Quit: BRLX).
(06:12:36 PM) kbsingh: if we namespace overload the collection, every component in that collection goes the same way right ?
(06:12:37 PM) gsanchietti left the room (quit: Quit: Ex-Chat).
(06:13:22 PM) Evolution: well, it's not a 'we' as it's ultimately up to the sig, but yes.
(06:13:46 PM) kbsingh: so if a collection has 80 components, for a single binary link difference, we get 160
(06:14:24 PM) philwyett left the room (quit: Ping timeout: 245 seconds).
(06:14:31 PM) kbsingh: and bigdata-python27-boto will not work with biggerdata-python27
(06:15:17 PM) RemiFedora: right
(06:15:47 PM) langdon: kbsingh, i think the long term solution is to also do a better job with "provides".. but my rpm-fu is not great
(06:16:03 PM) langdon: which, i think, would solve that problem
(06:16:19 PM) lars_kurth [~lars_kurt@97e5a0c2.skybroadband.com] entered the room.
(06:16:52 PM) kbsingh: i think the better solution here is to overload the rpm infra under the hood, and abstract away the binary bits.
(06:17:17 PM) kbsingh: eg. have the python collection require a python-binary, and have multiple options in the collection provide that binary, with a sane default
(06:17:55 PM) kbsingh: that way folks can switch around if they want, then just pivot link the entire stack under /opt/<vendor>/this-python/ to /opt/<vendor>/that-python/
(06:18:02 PM) langdon: kbsingh, not to beat a dead horse.. but how is that different from a "provides"? unless you mean within one collection?
(06:18:21 PM) langdon: kbsingh, ohh.. or do you mean with both "providers" installed?
(06:18:28 PM) kbsingh: yeah
(06:18:37 PM) kbsingh: if the problem includes parallel installable
(06:18:41 PM) langdon: doesn't scl enable do that for you?
(06:18:50 PM) langdon: like wouldn't you do that at run time?
(06:18:57 PM) langdon: else you should uninstall the "bad" one
(06:19:26 PM) kbsingh: thats really a user story thing, do we need to deliver multiple build types installable at the same time.
(06:19:28 PM) langdon: cause at runtime you know which you want.. but there is no way the "box admin" knows which you want per application
(06:19:38 PM) kbsingh: if its a case of just one instance at a time, then we dont / wont need that
(06:20:19 PM) ***hhorak won't pretend he is following entirely.. got lost somewhere around 'overload the rpm infra' -- is that about changing the scl concept entirely to make it right?
(06:20:23 PM) kbsingh: yeah, but if you namespace them away then the developer will also need to know what he's going to use, since just python27 isnt good enough anymore.
(06:20:46 PM) kbsingh: hhorak: so, rpm infra as in the provides/conflicts/obsoletes etc that rpm already does
(06:21:35 PM) juergh left the room (quit: Quit: Leaving.).
(06:22:10 PM) RemiFedora: hhorak, I think I already file a bug about this (mostly dependency on foo-runtime which is broken as not aware of vendor / installation tree)
(06:22:23 PM) langdon: kbsingh, well.. the "application runner admin" (who might be a developer) needs to know which to use.. but.. he/she needs to know anyway.. the second you have multiple options on the machine to run an application with.. if the "box admin" wants to provide only one py27 "set" then they should kill the ones they don't want to provide
(06:23:41 PM) hhorak: kbsingh: RemiFedora: ah, ok.. I understand better now.
(06:24:10 PM) kbsingh: langdon: right
(06:24:30 PM) kbsingh: so someone somewhere needs to make a decision on what collection they want to run with and need to make that decision somewhere.
(06:24:39 PM) RemiFedora: which also means, each package which install something in /opt/foo tree should requires /opt/foo (which doesn't exist for base package, as we have "filesystem")
(06:24:55 PM) langdon: kbsingh, update-alts on steriods
(06:25:03 PM) kbsingh: and ideally the box admin plays ball and has the same collection on there
(06:25:21 PM) kbsingh: i.e you need to know what collection you are going to use and the specific variant of that collection before the box even gets provisioned
(06:25:46 PM) langdon: kbsingh, RemiFedora but.. that doesn't nec solve the problem of mult apps having different, conflicting requirements .. like you need "per app rpm db" or some such
(06:26:03 PM) kbsingh: ie. the namespace now needs to be established across the board, eg: everyone needs to agree they are going to use bigdata-python27
(06:26:15 PM) langdon: kbsingh, well.. arguably.. the dev and admin talk :)
(06:26:27 PM) kbsingh: langdon: thankfully they are the only people who matter.
(06:26:49 PM) langdon: kbsingh, ohhh.. i forgot .. im in a centos channel.. usually i think it is just dev ;)
(06:27:26 PM) kbsingh: well, hopefully users still matter to dev's as well. otherwise why bother.
(06:27:38 PM) jorton: I'm a bit worried about trying to re-invent SCL packaging entirely here.
(06:27:43 PM) RemiFedora: I think I have write a proposal to make scl command vendor agnostic, which mean "scl enable python45 ..." should allow to use foo-python45 or bar-python45...
(06:28:21 PM) langdon: kbsingh, development is more fun when there are no users or admins <facetious/> ;)
(06:28:24 PM) kbsingh: RemiFedora: the bit that i dont get is why the prefix ?
(06:28:56 PM) kbsingh: you are effectively forking the collection, and the entire downstream of it
(06:29:05 PM) langdon: RemiFedora, but i think the "app runner" needs to know if they want foo- or bar- variant
(06:29:06 PM) RemiFedora: kbsingh, also don't know, probably some to install both foo-python27 and bar-python27
(06:29:43 PM) RemiFedora: langdon, if only one collection installed, use it ;)  else fails
(06:29:48 PM) kbsingh: RemiFedora: but python27-foo can just be a different varient of the python27 rpm, with the single collection defaulting to python27
(06:30:01 PM) langdon: lets say this as an example.. app1 wants some experimental feature.. so they use foo-py27 and app-all-the-rest should use prod approved bar-py27..
(06:30:38 PM) kbsingh: then extend that, if in 80 rpms, you have 6 that have alternatives you now have 480 packages
(06:30:47 PM) kbsingh: and no clean way to communicate which is what
(06:30:58 PM) langdon: kbsingh, disk is cheap
(06:31:09 PM) kbsingh: eg: bigdata-smallendian-json2-foo-bar-xml3-libvirt3-openstackicehouse-python27
(06:31:31 PM) kbsingh: vs: bigdata-smallendian-json3-foo-bar-xml3-libvirt3-openstackjuno-python27
(06:31:31 PM) langdon: the point of this.. sort of .. is that it is cheap(er) to update than it ever has been ... so have copies is ok..
(06:32:39 PM) kbsingh: vs: bigdata-smallendian-json3-foo-bar-xml3-libvirt3-openstackjuno-builder23-multilibok-python27
(06:32:43 PM) RemiFedora: kbsingh, SCL can be layered (even if dependent SCL are a bit more complex than simple self-contained SCL)
(06:32:43 PM) langdon: kbsingh, i think you are arguing for the point of rpm itself (or pkging in general)... i dont think scl nec. replaces all pkging.. just special cases.. or the stacks.next needs to essentially be smarter about all reuse..
(06:32:49 PM) kbsingh: vs: bigdata-smallendian-json3-foo-bar-xml3-libvirt3-openstackjuno-builder23-multilibok-qemu-only-python27
(06:33:12 PM) kbsingh: RemiFedora: right, i agree - hence why the prefix to fork the collection for a single point of entry ?
(06:33:22 PM) kbsingh: surely making life harder is totally anti productive.
(06:33:53 PM) langdon: basically we really need rpm to say "skip if i have the exact same thing but branch if i don't" and allow an app to choose tree.. which scl is an early attempt at
(06:34:04 PM) kbsingh: langdon: scl still uses rpm under the hood, and rpm has a fairly well defined mechanism to deliver alternatives and varients for specific builds. why not use that
(06:34:32 PM) kbsingh: because at this point, you might as well call off SCL all together and use an overlay filesystem in instances with varients as layers on the instances.
(06:34:45 PM) langdon: kbsingh, or docker ;)
(06:34:52 PM) kbsingh: that is what docker is
(06:35:06 PM) langdon: kbsingh, or just chroot
(06:35:51 PM) langdon: kbsingh, i think the point of scl is that it is 1/2 way there.. so it is a "roadmap" to containerization (of whatever flavor)...
(06:35:56 PM) jorton: kbsingh: most of those arguments would apply to doing SCLs in the first place.  we could package everything in standard FHS locations, rather than /opt
(06:36:09 PM) jorton: I've always seen SCLs as a kind of compromise
(06:36:25 PM) langdon: and i thought that rpm branching/variants/etc was insufficient to meet the needs of the requirements that scl meets
(06:37:20 PM) alefattorini left the room (quit: Quit: Ex-Chat).
(06:38:25 PM) kbsingh: RemiFedora: so i missed that comment, yes - SCL's can be layered, and its that which i would have thought resolves the problem domain brought up here.
(06:39:35 PM) langdon: kbsingh, RemiFedora i think that the prefixing lets the layering happen distro-agnostically.. so you can specify which scl you are downstreaming from without worrying about which distro you land on..
(06:40:00 PM) langdon: the prefix is required to distinguish from "non-scl" and from "competitive" scls
(06:40:21 PM) kbsingh: use a dist tag at buildtime for that
(06:40:37 PM) kbsingh: and the Vendor metadata is already available in the same place the name/prefix would be
(06:41:06 PM) langdon: kbsingh, isn't that the opposite? like wouldn't that let me do a dependent colleciton for only centos?
(06:41:26 PM) kbsingh: no
(06:41:45 PM) kbsingh: whatever you can put in the prefix you can put in the tag
(06:42:04 PM) kbsingh: without having to fork the entire collection, repeatedly
(06:42:22 PM) avozza is now known as zz_avozza
(06:43:00 PM) hhorak: kbsingh: but whatever you put into tag you cannot make parallel install-able since yum/dnf would take it as update, not a different package. I guess this is not what langdon wants.
(06:43:16 PM) kbsingh: hhorak: not true, the kernel does installonly fine
(06:43:42 PM) langdon: kbsingh, so i could have "rh" dist tag and "bob" dist tag?
(06:43:58 PM) kbsingh: langdon: what do you get for : rpm -qa kernel | wc -l
(06:44:06 PM) hhorak: kbsingh: you can say keep 3 last copies of rpm, but cannot say "update 2.7 kernel to latest 2.7 and so on.."
(06:44:09 PM) kbsingh: ( ideally on an instll that has had a few kernel updates :D )
(06:45:30 PM) langdon: kbsingh, yeah.. i get that.. but i didn't think you ever had variants in there.. like i would never expect to see kernel.x.y.z.rh.x86_64 on fedora
(06:45:54 PM) langdon: or weirder kernel.x.y.z.bob.x86_64 on fedora
(06:46:02 PM) Nahual [~Nahual@unaffiliated/nahual] entered the room.
(06:46:34 PM) kbsingh: langdon: why not ?
(06:46:51 PM) kbsingh: hhorak: pretty sure you can. happy to do some demos at fosdem :)
(06:47:20 PM) kbsingh: langdon: if you exepct to see a bobs-python27, why not a python27.bobs
(06:47:22 PM) langdon: kbsingh, uhh.. no idea? :) just all my kernels say fc21 ...
(06:47:29 PM) jorton: kbsingh: we are really trying to avoid conflicts in package names here.  using dist tags is clearly not the right solution
(06:47:44 PM) langdon: because i would expect bobs-py27.fc21 and bob-py27.centos or whatever
(06:47:45 PM) jorton: it would be like saying, sure, we can have two packages named "X" in Fedora - just give them different dist tags, it'll be fine
(06:48:18 PM) hhorak: kbsingh: this is not the first time I hear that idea about more rpms of the same package, actually.. would love to see how it can be done..
(06:48:26 PM) davidep left the room (quit: Ping timeout: 256 seconds).
(06:48:29 PM) jorton: we have existing complaints from users that our naming of SCLs, like "httpd24" etc, is not sufficient to avoid conflicts with third-party/private naming schemes
(06:48:33 PM) kbsingh: jorton: it boils down to the user story and exectations you set and communicate in a wider audience. scl is already an antipattern to some extents in that area, and folks need to 'get it'
(06:48:52 PM) langdon: ahh i think thta is it.. wouldnt you need different build requires for fedora/centos/rhel/suse for the same bob-py27?
(06:49:00 PM) kbsingh: jorton: the bit i am asking around isnt so much disttag centrick, its more like 'given the name is the collection tag' why fork it for every different buildtime option people might want
(06:49:38 PM) kbsingh: jorton: so, thats a good example. http24 is'nt unique enough
(06:49:50 PM) tazz [~gaurav@triband-mum-120.60.165.178.mtnl.net.in] entered the room.
(06:50:12 PM) kbsingh: langdon: you already have different builtime requirements for all those platforms, given they dont even share a glibc.
(06:50:12 PM) eseyman left the room (quit: Quit: Quitte).
(06:51:00 PM) londo left the room (quit: Ping timeout: 250 seconds).
(06:51:07 PM) kbsingh: jorton: would you say a majority of all SCL users find httpd24 to not be suiteable ?
(06:51:16 PM) jorton: kbsingh: I don't think we care too much about that particular use case (different variants of build flags)
(06:51:22 PM) langdon: kbsingh, yeah.. exactly.. so wouldn't i need dist tags to reflect that.. so would it be py27.bob-fc21 vs py27.bob-centos?
(06:51:46 PM) jorton: kbsingh: no idea for that specific case.  we know of specific cases for python & mariadb I believe
(06:52:04 PM) kbsingh: langdon: ideally you would do that anyway, cause py27bob on centos isnt going to work on suse, so communicating that should be a nice thing
(06:52:27 PM) jorton: kbsingh: so we want a general solution to avoid such conflicts by making SCL names distinct
(06:53:11 PM) kbsingh: I am pretty sure that adding a prefix isnt it
(06:53:26 PM) kbsingh: let me explain this in a different way
(06:53:28 PM) langdon: kbsingh, jorton i think the problem we are addressing on that aspect is "late to the game" ... so lots of people have rpms that don't conflict with the distros already.. and we are finding the scls we are distrib'ing to conflict .. as this is optional stuff, we need to distinguish from normal naming conventions other people mmight be using
(06:53:31 PM) kbsingh: lots of folks make golf clubs
(06:53:37 PM) kbsingh: some are left handed, others are right handed.
(06:54:07 PM) kbsingh: but there are also those that are made for one eye blind, short sighted golfers who haveto play it like a mallet
(06:54:28 PM) kbsingh: now when you make golf clubs, how much sense does it make to assume everyone is malleting it ?
(06:54:29 PM) jorton: ookkkaaay :)
(06:54:40 PM) Nahual left the room.
(06:55:17 PM) kbsingh: so in the same sense, is forking and splitting up the entire scl setup complete end to end a good way to do this ? or create an option that allows folks to redo the handle if they hit that problem
(06:55:56 PM) mboeru [~mboeru@unaffiliated/mboeru] entered the room.
(06:56:00 PM) jorton: kbsingh: I'm not sure I get this golf club metaphor
(06:56:23 PM) jorton: I am an interfaces guy.  package names are a namespace which we don't "own" here
(06:56:33 PM) kbsingh: jorton: i thkn the problem domain of httpd24 not being unique enough is a very small minority - so why make everyone fork httpd24 all the time
(06:56:43 PM) jorton: RHEL/Fedora/CentOS effectively own the namespace
(06:56:49 PM) langdon: kbsingh, where is the forking coming from?
(06:57:01 PM) langdon: i am not seeing any forking.. if the names don't conflict
(06:57:05 PM) jorton: kbsingh: we're not planning to change existing SCLs here.
(06:57:15 PM) jorton: kbsingh: we want *new* SCLs to avoid future conflicts by using a consistent prefix
(06:57:32 PM) mbooth left the room ("Leaving").
(06:57:50 PM) langdon: like if you want to build your special handle.. make bobs-handle-py27 and make it depend on rh-py27... and it will work on rhel/centos/scilinux/etc
(06:57:52 PM) jorton: for existing SCLs, we already lost.  that's a done deal
(06:58:43 PM) langdon: only in the case where you think the base is broken (as in the club ITSELF is insufficient) do you need to fork..
(06:59:17 PM) langdon: yes.. you lose the py27 ecosystem.. but that is probably accurate anyway.. because you should test that dependent scls still work on your new club
(06:59:20 PM) RemiFedora: it seems there is 2 goal for the prefix. Namespace for scl (avoid conflicts with non SCL) and Namespace for vendor...
(06:59:33 PM) kbsingh: jorton: lost what ? thats the bit i am trying to quantify.
(07:00:21 PM) kbsingh: RemiFedora: i dont think so, the original example and usecase was to namespace overload to deliver varients for parallel installs.
(07:00:21 PM) jorton: kbsingh: lost the chance to avoid conflicts with existing packages
(07:00:28 PM) kbsingh: RemiFedora: what you are saying is very different
(07:00:51 PM) jorton: kbsingh: so, we shipped httpd24 and if anybody has a package named httpd24, likely they cannot use the httpd24 SCL
(07:01:58 PM) chorrell [~chorrell@unaffiliated/chorrell] entered the room.
(07:02:01 PM) RemiFedora: (what I call SCL vs non-SCL name conflicts)
(07:02:16 PM) jorton: kbsingh: but for future SCLs, we can avoid conflicts around python34 by not calling our SCL "python34", but instead, "rh-python34", or "fish-python34" or whatever
(07:02:28 PM) langdon: just to be clear.. we are proposing that the "rh-" prefix on a particular collection be the same on all distros... in other words.. it is rh-py27 on centos/sci-linux/fedora/rhel .. it only changes if someone wants to build a new base.. thereby, potentially, changing the API of the scl
(07:02:45 PM) kbsingh: how would scl-python24 not conflict with scl-python24 ?
(07:03:39 PM) kbsingh: i need to head off to dinner here, will be back later.
(07:03:42 PM) langdon: rh-py27 would not conflict with bob-py27 ..
(07:03:59 PM) kbsingh: but this whole prefix thing is still a solution trying really hard to find problems that keep changing context :)
(07:04:06 PM) langdon: lol
(07:04:10 PM) langdon: i have a headache
(07:04:20 PM) langdon: i still think we are mis-communicating somewhere
(07:04:33 PM) langdon: kbsingh, can we try voice at some point soon?
(07:05:28 PM) ***gholms just wants to be able to uee stuff that wants scls on the same box as stuff that doesn't
(07:05:41 PM) jorton: really, I am only fleshing out exactly what langdon's (3) was way above: avoiding conflicts with non-SCL packages
(07:10:37 PM) langdon: kbsingh, hhorak jorton RemiFedora (anyone else interested) so.. google hangout (or some such) at some point soon to discuss? I think we may be mis-communicating  ...
(07:11:00 PM) Nahual [~Nahual@unaffiliated/nahual] entered the room.
(07:11:09 PM) RemiFedora: langdon, should be ok for me
(07:11:23 PM) chorrell is now known as chorrell-away
(07:12:39 PM) hhorak: langdon: fine with me as well
(07:17:01 PM) filippoc left the room.
kbsingh kilted1 kkeithley kraft ksb_ kstange kushal 
(07:19:20 PM) mcclurmc left the room (quit: Remote host closed the connection).
(07:19:49 PM) ***jorton too
(07:20:19 PM) hhorak: langdon: I guess we need to catch up with kbsingh later to make up some time slot for the hangout, but if you guys find some suitable time, there is quite good chance I can join too..
(07:20:57 PM) langdon: hhorak, yeah.. figured when he cam back from dinner he might see this and propose some ideas..
(07:21:25 PM) Nahual left the room (quit: Quit: Leaving.).
(07:28:54 PM) RemiFedora: About the runtime dependency and scl prefix, I was talking of this bug => https://bugzilla.redhat.com/show_bug.cgi?id=1139209
(07:29:46 PM) RemiFedora: hhorak, ^^
(07:30:35 PM) pixelb left the room (quit: Ping timeout: 265 seconds).
(07:32:49 PM) hhorak: RemiFedora: thx, that makes sense to me too
(07:34:33 PM) RemiFedora: hhorak, FYI, for SCL in my repo I use a Requires: php54-runtime(remi)(x86-64)    but manually added
(07:35:34 PM) RemiFedora: so of course remi-php54-runtime will also be "mostly" ok (is added to all packages, and arched)
(07:36:19 PM) RemiFedora: "if"
redkilian reetp RemiFedora 
(07:36:54 PM) hhorak: RemiFedora: yeah, seems fine
(07:38:39 PM) drag00n left the room (quit: ).
(07:38:46 PM) RemiFedora: also diner time for me