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

Re: How to handle updates to bo?



I'm still waiting on a response to my last email on the subject.  I
will implement my original proposal tomorrow unless I hear otherwise.

There's this major issue that I've been guiltily silent about - I'm
going to be totally unavailable for one month starting on 6/12.  But I
plan to devote lots of time this week to getting my packages and the
ftp site in order.  That's one reason to favor simple solutions.

I'm appending my email, with some clarifications, below, and I'm
hoping for a wider response.

Guy


Brian White <bcwhite@verisim.com> writes:
 
> It would be great if dinstall would also check dependancies for this.  I
> know this is already somewhere on your list of things to do.

Yes, I'm hoping to use Manoj's pkg-order library (once it's less
buggy).  At best I can only give warnings and not outright rejections.
For example if A depends on B, but both are packages waiting in
Incoming, I should not reject A simply because its dependencies are
unfulfilled (this can actually be solved with multiple passes over
Incoming.)  Another example is if an arch all package depends on an
arch any package, but the depended on package is not yet available for
a specific arch.

> This is acceptable, but I'd prefer one additional thing:  I'd like to
> install those proposed packages to "frozen" so that anybody can try out
> the package on their system instead of just limiting it to the testing
> group and those that can steal it from Incoming.
 
That could potentially be much more work for me and carry few obvious
benefits.
 
Are you suggesting this so that there will be a simple distribution to
point people at (made up of mostly symlinks and some files?)  Or are
you suggesting this so that proposed patches to stable get wider
circulation?

Would dinstall install stable programs automatically to this
distribution, and then the testing group would allow them in to stable
or reject them?  Or are you suggesting two approval steps - first to
this frozen, then to the actual stable?
 
Symlinked distributions (such as rex-fixed) or such a frozen are very
fragile.  The frozen that you suggest would be even more difficult to
maintain if it's necessary to remove programs from there - reverting
back to the symlink.


Guy


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: