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

Re: Subpackaging (Was: Potato now stable)



Decklin Foster <decklin@red-bean.com> wrote:
> I like the plan a lot. some thoughts:

Glade to hear it.

> I wonder if the default docs should not go in a locale/ subdir for the
> proper language (English for most of what exists now). I know very
> little about i18b so I won't comment on the implementation. This does
> have this advantages of:
> 
>  (a) not appearing to be English-centric
>  (b) allowing for a package whose upstream docs are entirely in a
>      different language (while most non-English-speaking authors also
>      know some English or are fluent in it, many may not).

Yes, this could work.

> > We are breaking the rules on copyright at the moment. We distribute
> > binaries licensed under the GPL without a copy of the GPL.
> 
> I disagree. We distribute base-files on the same server.

You are right, I am probably trying to fix a problem that is not there. Feel
free to ignore the bit of copyrights.

> > Packages that provide the same documentation in different formats do not
> > always include the same documents in the different formats, but instead
> > different documents are included in different formats. An example might be
> > useful:
> > 
> > Not: README, README.html and README.ps
> > 
> > But: README, manual.html and specification.ps
> 
> IMHO, doc-$FORMAT should only apply if the same documentation is built
> in different formats. There should be one 'doc' tarball for
> documentation which comes in a single format, and 'doc-*' or 'doc/*'
> for the multiple case (and then none of those files should be in the
> base 'doc'.)

That was about what I was thinking.

> > What happens when a user selects to install binary-i386 and binary-m68k
> > packages?
> 
> I don't see a reason to allow this; is there one?

No probably not. I was thinking it would be cool to build a server on an i386,
and then decide to upgrade to Alpha. You can get ATX Alpha boards these days,
in terms of hardware you just need to replace the m/b and chip; it would be
cool if you could take a debian install, tell apt that you were about to
change the processor from i386 to alpha and it automatically changed all the
binaries. This is probably not very likely to happen, and if it could be
written to be supported by my suggested layout, then it could probably be
handled by the current layout. Just remove all the binary packages and install
the new ones from the new arch. This is all a bit side tracked, and does not
give a reason for wanting binaries from two archs installed at once.

Oh! I have thought of a reason! Something to do with a network server that
supplies /usr/bin for a load of machines, and they are different archs.
Probably far-fetched, and the package management system should not be used for
something this complicated.

-- 
Don't worry  --  shop.



Reply to: