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 <[EMAIL PROTECTED]>, Adam Rex <[EMAIL PROTECTED]> > > * 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
