Re: Shall we state on naming (again)?
On Thu, Oct 03, 2002 at 09:40:44PM +0200, Ralf Treinen wrote:
> On Thu, Oct 03, 2002 at 09:29:04PM +0200, Sven LUTHER wrote:
>
> > > I remember that there were plans for allowing for additional
> > > "uploaders" of packages. That would be helpful for ocaml packages,
> >
> > Err, what do you mean by additional "uploaders", and from who were those
> > plans ?
>
> I'm glad that I am not the only one who missed it:
A, ok, it is not so much that i missed it (well i missed it anyway) bnut
that the context was not really clear.
> Developers Reference, Section 5.4: Collaborative maintenance
>
>
> Collaborative maintenance" is a term describing the sharing of Debian
> package maintenance duties by several people. This collaboration is
> almost a good idea, since it generally results in higher quality and
> faster bug fix turnaround time. It is strongly recommended that packages
> in which a priority of Standard or which are part of the base set have
> co-maintainers.
>
> Generally there is a primary maintainer and one or more co-maintainers.
> The primary maintainer is the whose name is listed in the Maintainer
> field of the debian/control file. Co-maintainers are all the other
> maintainers.
>
> [...]
>
> * Add the co-maintainer's correct maintainer name and address to the
> Uploaders field in the global part of the debian/control file.
>
> Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
>
> * Using the PTS (The Package Tracking System, Section 4.11), the
> co-maintainers should subscribe themselves to the appropriate
> source package.
Mmm, this is nice.
BTW, as the number of packaged ocaml stuff expand, we could also imagine
a system of common maintainership or something such. This may eventually
augment the number of stuff we can package.
Mmm, i am not being clear. (early morning and all that)
What i mean is that we could have some package that are maintained by a
group of maintainers (well all of us), with some work sharing scheme of
the kind that when there is work needing done (in a sort of todo list or
something such) then if someone has time, he says it and does the job.
Sure this would need a rather verbose changelog and other such
discipline, but it could be worth it.
> > So we will need to rename hevea as hevea-native and hevea-bytecode or
> > some other such thing, which will be a problem for users waiting for
> > hevea, and not something else.
>
> I don't think that we should create both bytecode and native
> vesions of a package, unless there is a real need of our users
> to have both available. If it is just for the ease of upgrade
> than we should rather search for other solutions.
No, you don't understand.
The plan is to create the bytecode package as arch: all. The bytecode
package is needed for the 5 arches or so not supporting the native code
compiler (m68k, hppa, mips, mipsel, s390, hurd-i386, ...). There is no
need to have these arch all build their own version of the package, and
there is no reason to have so many copies of the same thing in the
archive. As an example, look at the ledit package.
Now, there is no way we can stop the native code supporting arches from
seeing these arch: all package, and we most definitively want to have
the native code version available for those arches, do we not ?
So ideally, we name hevea the bytecode one, and hevea-native or
hevea-optimized or whatever, the native code one when it is available.
(Or the other way around, like i said).
But then the user don't want to know about that, and wants to do an
apt-get install hevea, and get the best version available. The same
thing as we did with ocaml-best-compilers could be done here. But then
it did work best with dependencies, but i don't really know well apt-get
install will handle this.
We could have an hevea-native and a hevea-bytecode, and have the hevea
virtual package placed on the package depending on the arch we are
building, ... Mmm ... No, this would not even work, since we build the
hevea-bytecode only once.
So The only thing we can do, is have hevea be the bytecode version, and
call hevea-native the optimized version, and have hevea-native provide
hevea.
But what happens here if we do an apt-get install hevea, we will get the
arch: all package, and not the other.
So you see, the problem is not that much about wheter we will ship an
bytecode version or no (we already ship 6 copies or so of them), but how
to handle it so that it will be transparent for our users.
And then, there is this problem with versioned provides which could byte
us.
Friendly,
Sven Luther
Reply to: