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

Re: kde and files location



Manoj Srivastava wrote:
> 
>                           We, collectively, are Debian. We do not
>  write most of the software we offer; we package it. We can't decide
>  when we are the distribution and when the software comes from the
>  author directly depending on whether we want it to go under /opt.

Well, I think we should.
Under the actual scheme, we put software "foo" inside the distribution
or under /opt only depending the fact that the package maintainer is a
debian developer or not. We should instead fix a clear and more
objective way to distinguish the cases.

Please note that we doesn't have a policy explayning third parties how
they should package their software in a .deb when they want to directly
distribute it. We should do this, firstly.

I think we should identify those packages that are "external" of the OS
( a good discriminant would be: the author wants to distribute it in
.deb format and asks us where in the fs should be program reside: we
would say "put in /opt") and, when packaging it by ourself, act as if we
were the author.
The fact that a package then goes or not in our CD or ftp site depends
ONLY from its licensing scheme (and from the trust we put on its
maintainer), not from the fact that the maintainer has an account on
master or not!

we are now only talking about "optional" programs that could be or not
in the distribution. But let's take the "bind" example. We all agree
that "bind" should be part of the OS, but its licensing scheme doesn't
permit us to put it even in non-free (if I remember well). Imagine we
could convince bind's people to package it in .deb format and distribute
it directly.
Should it, for that fact, go under /opt?
I think that we want bind be inside the OS, so we would like to tell
them to package it for /usr.

I would like to distinguish the difference from the OS and "external"
programs and the debian "distribution" and external distributions (means
not from our ftp site) of  packages.


>         Yes, it has come, except *We*, as the Debian project, the OS
>  distributor, do not populate it.

You are right: the Os vendor should not populate it.
But why then we are populating the /usr of all the programs we are able
to find out there that weren't yet in .deb format?

I'm not proposing that "debian" populate /opt .
I'm proposing that "optional" and "external" programs populate it, and I
ask you to recognise that a part of the programs we are now distributing
INSIDE the OS falls into that category, and therefore should be put
under /opt , without any consideration if the package maintainer is the
author or not, or if he is a debian developer or not.

I can imagine myself as wearing the "debian's hat" when maintaining
groff or man, and wearing a different hat when maintaining qweb. Qweb's
.deb is also distributed from his author's home page. Next version would
became commercial (sigh!) but his author has expressed the wish of
continuing to distribute a .deb from his home page. I could maintain it,
as a favour to a friend, not as a debian developer. But I'm a debian
developer, and I could also upload it to master, if the license permits
its inclusion in contrib or non-free.
So what? Do you see the confusion that could come from this? It could be
in /usr or must go in /opt depending on the accidental fact that the
author has a friend that is a debian developer.
This is pure silliness!

I think we should set a policy saying "when" and "why" a program should
be packaged for /opt and "when" and "why" for /usr. We should also set a
policy explaining third parties on how to do so.

Ciao,
Fabrizio
-- 
| fpolacco@icenet.fi    fpolacco@debian.org    fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: