> First, I need to find location of proper dependency versions > to build for luna, kepler and juno (we have N-1 compatibility policy). > Second, I need a way to know if these dependency repositories go > stale and need to be updated.
It's actually not that difficult once you get setup doing this. For Sapphire, we are currently building against 12 different targets (Indigo through Luna, including all SR levels and separately for 3.8 and 4.2 variants of Juno). Once a target definition references released binaries, you don't have to ever touch it again, so for instance, now I am only updating Kepler SR1 and Luna targets. > This still does not solve the problem of reproducible builds, but > I don't it's possible to have reproducible builds and build against > latest versions of dependencies at the same time, i.e. these two > requirements are mutually exclusive. Not mutually exclusive at all, but you do have to take explicit steps to move up to newer builds of your dependencies. For Sapphire, the first step in producing the milestone contribution is to update the target to milestone contributions of the dependencies. That triggers a build and we test that build. Thanks, - Konstantin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Igor Fedorenko Sent: Wednesday, August 21, 2013 10:46 AM To: [email protected] Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Again, I am not arguing against building with individual dependency repositories. All I am saying there is currently no convenient way to do this and I don't have the time&resources to maintain such fine-grained dependency configuration. I am particularly concerned about two problems. First, I need to find location of proper dependency versions to build for luna, kepler and juno (we have N-1 compatibility policy). Second, I need a way to know if these dependency repositories go stale and need to be updated. One way to address these is to require each participating project provide separate repository URL they recommend for use as build target for each yearly release and make list of these URLs documented somewhere. This still does not solve the problem of reproducible builds, but I don't it's possible to have reproducible builds and build against latest versions of dependencies at the same time, i.e. these two requirements are mutually exclusive. -- Regards, Igor On 2013-08-21 12:51 PM, Konstantin Komissarchik wrote: > Note that due to Equinox changes in Luna M1, this is a particularly > dangerous time to not be building with Luna components when > contributing to Luna. > > One of the primary reasons that it is bad to build against Luna simrel > repo as opposed to particular builds of all dependencies is that an > in-progress simrel repo is a moving target. This breaks a fundamental > releng tenet by making builds not reproducible and requires the > project team to remember to manually trigger a build just before > contributing or risk contributing something built with stale > dependencies. Note that these issue can be fixed quite easily by producing versioned simrel repos that are never modified... > Doing this will not address all issues with using simrel repo as a > build target, but it will make such strategy less fraught with problems. > > - Konstantin > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Igor Fedorenko > Sent: Wednesday, August 21, 2013 8:36 AM > To: [email protected] > Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository > > Theoretically, yes, it does open possibility for bad things to happen. > In practice, however, this worked for us for last three releases. If > there was an easy way to consume current simrel dependencies from the > build, I'd certainly do it, but I am not willing to spend any time on > this when building against previous simrel repo works good enough. > > -- > Regards, > Igor > > On 2013-08-21 10:08 AM, Doug Schaefer wrote: >> I'm with David on this one. The simrel repo is supposed to be the >> aggregation of all the project builds. If you are building against an >> old simrel repo, chances are you aren't building against the bits >> that will appear with your bits in this round's simrel repo. Doesn't >> that open up the potential for bad things? >> >> Doug. >> >> On 13-08-21 7:29 AM, "Igor Fedorenko" <[email protected]> wrote: >> >>> I did the same, too. I simply don't have the time needed to maintain >>> list of project-level repositories and will build against kepler >>> until I can switch to luna simrel repo. >>> >>> -- >>> Regards, >>> Igor >>> >>> On 2013-08-21 4:05 AM, Marcel Bruch wrote: >>>> Maybe it would help if project could publish a (stable) URL of >>>> their latest Luna artifacts on a common wiki page? I had trouble to >>>> find all dependencies and features to set up our target platform >>>> accordingly two weeks ago. So decided to build the software against > Kepler instead. >>>> >>>> Best, >>>> Marcel >>>> >>>> On Aug 21, 2013, at 9:57 AM, David M Williams >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> Yes, has been discussed before, and I said "bad idea", because >>>>> anyone building for the Luna repository, should not be building >>>>> against the Luna repository. >>>>> >>>>> >>>>> >>>>> >>>>> From: Eike Stepper <[email protected] >>>>> <mailto:[email protected]>> >>>>> To: [email protected] >>>>> <mailto:[email protected]>, >>>>> Date: 08/21/2013 03:49 AM >>>>> Subject: [cross-project-issues-dev] Pre-M1 Aggregation Repository >>>>> Sent by: [email protected] >>>>> <mailto:[email protected]> >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> ----- >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I noticed that an empty Luna repository had been created some time >>>>> after the release of Kepler. An empty repository is not really >>>>> useful as a source for build dependencies and I wondered if it >>>>> would make sense in the future to seed the new repository with the >>>>> old content. Would it? Has it been discussed already? >>>>> >>>>> Cheers >>>>> /Eike >>>>> >>>>> ---- >>>>> http://www.esc-net.de <http://www.esc-net.de/> >>>>> http://thegordian.blogspot.com <http://thegordian.blogspot.com/> >>>>> http://twitter.com/eikestepper >>>>> >>>>> >>>>> _______________________________________________ >>>>> cross-project-issues-dev mailing list >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> cross-project-issues-dev mailing list >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
