[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Please rebuild your packages in the development tree of Fedora Extras



On Tue, 2006-02-14 at 11:25 -0500, Jeff Spaleta wrote:
> On 2/14/06, Ralf Corsepius <rc040203 freenet de> wrote:
> > >  Package maintainers need to learn
> > > about their dependencies within Extras/Core and coordinate required
> > > rebuilds with eachother.
> > I would not be opposed to this, if the infrastructure was in place - it
> > is not.
> 
> the repoquery isn't enough to provide the necessary information to
> learn about dependancy chains to allow for maintainer coordination?
No.

[Personal side-note: I hate repoquery. It's way less useable than its
apt-get counterparts]

> What exactly do you feel is needed in terms of infrastructure with
> regard to dependancy discovery?

Some issues:
* How to check if packages are subject of ABI changes?
I don't know. 

* How to check if updates/upgrades break APIs?
I don't know.

* Repo inconsistencies can be silent: E.g. changes to perl/python vendor
dirs - They are invisible to repoquery.

* Why are packages which obviously _break_ deps pushed into the repos,
instead of being hold back? (IMO, a must for FE < rawhide)

* Buildsystem issues: There is no means to withdraw a package from a
repo, should run time issues with an update/upgraded package in devel
show up. 

* Lack of automation: Why isn't repoquery and other repo checks run
periodically at a centralized site to issue automated alerts?

* There doesn't exist a package dep tracking system which would allow
packagers who know they are going to break other packages, to notify
other packagers (E.g. to allow maintainers to notify maintainers of
packages using these packages on certain issues). 

I could continue this list with nitpicks, ...

IMO, most of these issues would be non-issues, if an extended build
system would exist which automatically recompiles all packages when on
of its build time deps changes. Admitted, this would be a very radical
approach, but I think it is feasible for FCN+1, if it is automated.

Ralf



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]