Hello, Very clear story. But can you tell by the output of .cook.sh if the
file-conflicts or build failures are too blame becausethe wrong version in
Foresighters is used or that a new version in devel is too blame. Or must you
look at the output when installing / updating a package ? Roelof
> Date: Tue, 16 Apr 2013 22:59:53 +0200
> From: [email protected]
> To: [email protected]
> Subject: [Foresight-devel] About groups, and how they work for developers
>
> Hello,
>
> this is written for group-foresighters,so I will write how that group
> works. As other groups can have other specialties that do other things.
>
> About groups and how they come in handy.
>
> A group contains several single packages and specifies 32bit,
> 64bitforpackages. As some might only be 32bit.
> The group makes sure packages gets rebuild together with buildreqs from
> same group.
>
> let's say we have these packages in foresighters:
> gtk3
> pango
> glib
>
> same packages in fl:2-devel.
>
> you have updated all 3 in foresighters repo and start to install glib,
> then pango, it will complain that glib has the wrong version when
> installing pango. as when you build pango it took the version of glib
> from fl:2-devel
>
> This is where groups make things little easier.
>
> we add glib in group-foresighters. then run: .cook.sh to get a binary
> from group-foresighters, so we know group-foresighters knows it's there.
> Then we just build pango and it will automatically take glib from
> foresighters group as buildreq and the rest of buildreqs from
> fl:2-devel. When it is done, we add pango to group-foresighters and
> commit the recipe, then run /.cook.sh
>
> Now we got pango and glib in group-foresighters. So now I can easily
> install both of them without getting a conflict that pango used glib
> from fl:2-devel when I got glib from foresighters repo.
>
> sudo conary install {glib,pango}=foresighters.rpath.org@fl:2-devel
> That will now work perfectlytoinstall. As pango now want glib from
> group-foresighters group and we want that one.
>
>
> We need to always run: cvc update
> inside group-foresighters folder, to see if someone else have done any
> changes first. Before we add or change anything inside it. And we always
> need to commit recipe if we make changes inside it.
>
>
> And we have thisin our .rmakerc file:
>
> resolveTroves group-world=foresighters.rpath.org@fl:2-devel
>
> That will tell rmake to always first grab buildreqs from group-world in
> foresighters repo. Group-world is created from group-foresighers recipe.
> And if it's not any buildreqs there, it will continue to look in
> fl:2-devel repo instead after buildreqs.
>
> And if a package is updated in fl:2-devel, then we only need to remove
> it inside group-foresighters (comment it out) and commit recipe, then
> ./cook.sh then it will no longer be available for our rmaketo grab it
> from foresighters repo, then it will take it from fl:2.devel instead.
>
>
> You don't have to add so much time to make sure they are built against
> the right version of packages.
>
>
> Starting with thisfor now.
>
>
> Probably some other can jump in and explain abit more, if needed.
>
> // Tomas Forsman
>
>
>
> _______________________________________________
> Foresight-devel mailing list
> [email protected]
> https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
>
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
