Re: Cameleon packages almost done
On Wed, Oct 09, 2002 at 02:12:26PM +0200, Jérôme Marant wrote:
> En réponse à Sven LUTHER <luther@dpt-info.u-strasbg.fr>:
>
> > > Well, no. It is quite different here. I do build a
> > > libconfigwin-ocaml-dev package from the cameleon source
> > > and such a package already exist in the
> > > archive and is built from the configwin source.
> >
> > But if you don't release a newer version of configwin, then
> > there will be the older version of it compiled from configwin, and a
> > newer version of it compiled from cameleon.
> >
> > > I don't think you can have two packages with the same name
> > > but provided by different source package. Am I wrong?
> >
> > Well, my guessing, is that nothing in the pool itself will block it,
> > since it is not two package with the same version and the same name,
> > but
> > there may be a problem with the override file.
>
> I'm pretty sure that katie would reject it because the pool is
> managed through a database indexed by (at least) package name.
Not package source name ?
> > And what do you want to do, ask for its removal, and put it in a
> > staging
> > area while it is removed, and then only upload it ?
>
> Yes, that's what we planned.
But the point is that before it get even considered for inclusion in the
pool, it has to pass the scrutiny of whoever edits the override file, at
least that is how things worked in the past. I would do the 2 things at
the same time, if they get rejected, you get an interlocutor who has the
power to remove configwin.
Also doing it this way will have as result a time were there is no more
configwin in the archive, which i don't believe is a good thing.
Mmm, you could also reupload configwin, with new packages name or
something.
Maybe you could ask also someone responsible for this how you are
supposed to best solve this problem.
> > I would upload it and ask for the removal of the old configwin, and
> > let
> > the ftp-master (or whoever is in charge of that) do they work. No need
> > to muddle the water more with uploading to a staging area.
> >
> > (That said, you can do all that and upload to a staging area all the
> > same).
>
> I also want to ensure everything works fine before uploading: people
> will be able to test and report remaining bugs.
And we fall in the same trap the gnome2 folks are right now. But then,
for them it was justified, since a broken gnome may not be quickly
fixed, and can screw up many things and people. And even for gnome2, i
don't believe it was the best solution they choose.
But what are the dangers with a not perfect cameleon ? It will most
assuredly not break anything, and if you want proper feedback, put it in
unstable.
Friendly,
Sven Luther
Reply to: