Re: new release process (package pool) being proposed
On Mon, Oct 25, 1999 at 04:06:27PM +1000, Anthony Towns wrote:
> On Mon, Oct 25, 1999 at 03:18:47AM -0200, Lalo Martins wrote:
> > Also, could you people please stop for a moment and really evaluate
> > the ammount of code needed? Get real: this is _trivial_.
>
> We'd need code to:
>
> * make life easy for the mirrors (either a working package pool,
> or the hard links thing). I've tried writing code to create a
> package pool, it's not that tricky, but it's a pain. I haven't
> looked at dinstall at all ever, so I've no idea how hard it'd
> be to modify dinstall to cope with it. Dealing with hard links
> sounds much more reasonable, but it gets rid of all the
Jason informs me this is already done by rsync, and we're
moving our mirrors to rsync, so, this is already solved
regardless of whether we want to use the Incremental process or
not.
> * do `installability checking'. I've done some code (see my
> previous mail) that checks depends/conflicts within main.
> It's about 2000 LOC, bits of which are incredibly horrible
> and complicated.
Have you tried using apt code?
> * work out how to choose subsets of packages that don't make
> hundreds of others uninstallable --- so that you don't
> install the new lesstif unless you also update all the other
> programs that the new lesstif will make uninstallable. This
> alone is non-trivial.
This is the hardest part.
As a temporary measure, I imagined the promotion checker like
that initially:
1: if there is a ``batch'' command pending, test if promoting
the whole batch would work, and if it would, do it
2: if all candidate packages can be promoted as a whole, do it
3: otherwise check each candidate individually
So yes, more complicated things like the recent perl problem
would require manual intervention; this intervention would have
the form of someone issuing a ``batch'' command, like:
batch perl-5005 perl libfoo-perl etc etc
> * interface with the BTS. Note that working out which bugs belong
> to a package has been something of a hack until today, even.
> Really, having the BTS be able to tell you which bugs apply to
> which versions of a package would be desirable to implement this
> properly.
Desirable, but not necessary. Making the BTS more version-aware
is a longstanding dream. But if this isn't _necessary_, let's
not make it a requirement, or we will never get things done. If
we go for the incremental process, then we can tackle the BTS
_once_ the incremental process is working.
> > Please make a list of the code we would need.
> > Please make a list of the added burdens on the ftpmasters.
>
> Erm. As proposer, this is really /your/ job.
No, because I made a ``political'' proposal - if we _want_ this
new system. If this was a ``technical'' proposal it would have
gone privately to the ftp team.
Anyway I made a (very incomplete) list somewhere in the proposal.
What I meant is: I'm telling you this is not a lot of work.
You (plural)'re telling me otherwise. So please show me facts.
Which you just did, thanks.
> > > Third, voting on `this is what these people will spend their time on in
> > > future' is completely inappropriate. If it's really a better way, they'll
> > > spend their time on it because they want to. If it's a bit ambiguous,
> > > you can spend your time on it if you want to.
>
> > No, nobody could just go and implement this radical change in
> > the way we work without consulting the other developers.
>
> Of course they could. In exactly the same way Debconf appeared. People
> discussed it, someone went off and implemented it, and now that we've
> got an implementation, we're ready to start using it, and consider adding
> it to policy.
No, it's very different. Debconf is a much less touchy subject
politically. Variations on the ``package pool'' theme have been
around for more than one year, and every time it's brought up
there are strong objections. So I felt we should vote this once
and for all and shut up, then if we know it's ``official'' then
the techs who want it done will implement it just like happened
with debconf.
Or in other words: When debconf was brought up, there was
consensus. If there hadn't been, it would have to be voted on
first. Even if it wasn't voted on, anyone could just have gone
and coded it, because testing debconf wouldn't mean _screw up
the whole archive_. But we can't just ``test'' a new release
process, can we? Either we do it, or we don't.
> Here, we ought to be discussing what we need (which we've done for over
> a year now), implementing it, and /then/ working out whether we want to
> actually use it or not.
Think of it as ``motivation''. A long ago we decided we wanted
apt (no vote was necessary IIRC), then people went off to
implement it. They could work with a lot of motivation because
they knew that the project wanted apt.
If I sit to work on a piece of software, I have a lot of
motivation because I know that if ``the project'' doesn't want
it (assuming it's something useful for the project) then it'll
have other uses elsewhere.
But if I sit to work on an implementation of the incremental
release process, and the project decides not to use it, I will
have completely lost some weeks of my life (one, I say, but you
swear it's more). So you see my point now?
[]s,
|alo
+----
--
I am Lalo of deB-org. You will be freed.
Resistance is futile.
http://www.webcom.com/lalo mailto:lalo@webcom.com
pgp key in the web page
Debian GNU/Linux --- http://www.debian.org
Brazil of Darkness - http://www.webcom.com/lalo/BroDar
Reply to: