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

Re: Shall we state on naming (again)?



On Thu, Oct 03, 2002 at 09:04:07PM +0200, Ralf Treinen wrote:
> On Thu, Oct 03, 2002 at 08:57:45PM +0200, Sven LUTHER wrote:
> 
> > > Should we really always restrict dependency to one particular
> > > upstream version of ocaml? That would be safest, I agree. On the
> > > other hand it will prevent a new upstream version of ocaml to go
> > > into testing unless all packages compiled into bytecode are
> > > ready to go with it.
> > 
> > And remember, if we have to choose between safety and some minor
> > inconvenience in the non released archive, what do you think we should
> > choose, given what debian stands for ?
> > 
> > And who will have to fix the bug reports we get when things break ?
> 
> OK OK I surrender :-) I will change my depencies to rigid dependencies
> on the particular ocaml upstream version.

:)))

> 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 ?

> since it would allow us to upgrade more easily the packages that
> are compiled to bytecode. 

Well, i remember now what i wanted to say more, i think.

If we go along with the bytecode package with arch: all and the native
code package when possible/needed, we would need to think about a naming
scheme to solve this.

Let's take the hevea package as an example.

We would build hevea as bytecode, without the -custom flag, and upload
it arch: all.

We then rebuild the same package as native code, and upload it arch:
i386 sparc powerpc ia64 arm alpha.

This will not work, since now hevea would be available two times on the
6 native arches, one time as bytecode, the other time as native code.
(Well it would be perfect if we could do it like that, but it is not
currently possible, and i don't think the archive managers will be happy
if we ask for something such) Mmm, this would be the nicest solution
though, let's see if there is still a manner of doing this ?

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.

There are many solutions for this :

  o chose one privileged code type, and have the other having another
  name.

  o have the native code version have the short name, and the bytecode
  version the long name, but providing the short name (will this work
  when you are on say hppa and do an apt-get install hevea).

  o have both package having long names, and using a provide to give the
  short name.

Mmm, maybe some variation of the second point would be the best idea.

Friendly,

Sven Luther



Reply to: