Re: Data section (#38902)
On Mon, Jul 19, 1999 at 10:59:59PM -0600, Jason Gunthorpe wrote:
>
> On Mon, 19 Jul 1999, Darren O. Benham wrote:
>
> > No reason but "ease". If you, we, the ftpmasters want to do a
> > data/[main|contrib|non-free] on the same level as our current
> > [main|contrib|non-free] that's ok with me. That DOES give us trees like..
>
> Not to mention it looks like the non-us structure, I'd rather we
> didn't have huge permuations of the archive layout for no good reason.
>
> Jason
>
Hum... reading back in the BTS, there are some discussions on this
subject (also check in the Mailing List Archives). Data was intended
as an addendum to main, more like the way we used contrib. Is intended
to be an add-on to main, mostly to permit main to still be mirrored
by little ftp-sites and sold on less CD than currently if is feasible.
That's why the proposal mention that packages in data should be DFSG
compliant (I understand that sometimes is not what we want but that's
a bug against the DFSG to not included some exceptions for contents)
I also see no technical reason to consider that a stable/data
will be more difficult to mirror than data/stable which mess with the
current release scheme. I even find the data/{main|contrib|non-free}
more difficult to manage.
We should have:
stable/main
/data
/contrib
/non-free
Which is more easy to configure. It also permits us to distributed
the important part (binaries) of a package in main, and let optional
data in main (like the eterm backgrounds, some gimp plug-ins, etc).
It's also fit well with the current policy:
Packages in main is DFSG and don't have dependencies with any other
subtree
Packages in data is DFSG and can only have dependencies with data or
main.
Packages in contrib is DFSG compliant but can have dependencies with
any other subtree
Packages in non-free is not DFSG compliant and can have depencies with
any other subtree
[Is it me or... written this way, that's looks like non-free is the
the less restrictive subtree ;)]
Finally, we can easily add it to the non-us scheme who already
has a similar structure. So, no trouble with the encryptions circuits
schemes or a file containing the pi-number [Military people used
it to design missile, isn't? ;)].
The last question is why not already have a non-free-data and a
contrib-data? The reason is the same that's why we don't make an
Official non-free CD and even an Official contrib CD. The data section
will help us make both an Essential Debian Official CD and a Full
Debian Official CD (or Slim/Fat, or whatever you call them). Sorry, I
hope you got the idea because I can make me more explicit right now
(english is not my native language and I'm quite tired :-\). Read the
threads on the mailing list for more args.
BTW, I'm very happy to see this proposal now accept so don't consider
this mail as an objection. I will have no trouble with whatever the
ftp-maintainers/cd-team think is better for the mirrored sites/cd-vendors.
Just one question, however: Should we keep the same sections? Data will
surely have a different repartition of contains than main and maybe will
should think about the way we'll place things before they get too big
to move around.
--
------------------------------------------------------------------------
Fabien Ninoles Chevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail: fab@tzone.org
WebPage: http://www.callisto.si.usherb.ca/~94246757
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
------------------------------------------------------------------------
Reply to: