www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <steve.lough...@gmail.com>
Subject Re: Making Policy decisions on artifacts and how they look.
Date Wed, 13 Dec 2006 09:40:27 GMT
On 13/12/06, Carlos Sanchez <carlos@apache.org> wrote:
> On 12/12/06, Steve Loughran <steve.loughran@gmail.com> wrote:
> > Carlos, Wendy and others are actually so rigorous about not breaking
> > peoples builds they prefer to leave artifacts in the wrong place and
> > with bad metadata (eg. commons-logging 1.1.) rather than correct
> > obvious defects. That's why we need to lock down the transition of
> > artifacts from staging to live. IMO part of the problem is in the
> > clients which never invalidate their cache; they assume metadata is
> > always complete and perfect. This makes it hard to correct metadata
> > bugs because the changes only propagate to new machines.
> I think it's a matter of getting people used to it. Nobody thinks
> possible that an RPM changes it's dependencies, a new version is
> released. In the repo is the same case, just that some projects still
> don't care about it and don't help too much.

There's a couple of diffs with RPM/deb files. The main one is that
they are normally released by redistributors who have their own number

My desktops subscribe to their apt repositories and get
my server subscribes to the Suse repo and gets firefox-1.5.06-suse-8.rpm.

The numbering is unumportant to me, as long as it is consistent across
all artifacts in the different repositories. It is not ever included
in the makefiles to build things, as the versions of dependencies and
the means to build them are not defined at this point --there's
nothing that does the retrieval. You have to have the dependencies in
place as a prerequisite (exception. apt-get from source, which does
the download, build and install based on the metadata. even then, its
not the makefiles that care)

In the m1/m2 repo, we declare at compile time what versions of things
we want. If I want to run against the commons-logging 1.1 jar I say
so, and there is no way to push a later version at my app. We can't
force commons-logging to release a 1.1.1 just to fix the metadata, yet
its the only means we have today to fix the problem.


View raw message