Re: sparc32 and sparc64-only packages
* Jurij Smakov (email@example.com) [060713 04:39]:
> On Wed, 12 Jul 2006, Goswin von Brederlow wrote:
> >How about creating a sparc64 package (probably part of dpkg's internal
> >type-handling support) and depending on that?
> >That would at least make the package uninstallable on sparc32.
> Is there some mechanism to enforce it? I don't see anything which would
> prevent the installation of the proposed sparc64 package on sparc32 box.
> Anyway, before working on a solution I would like to hear the release team
> opinion on the matter.
Well, what do the porters think that our sparc port is? I think that's
basically a central part of the question. From the release team's point
of view, I think we have the following requirements:
- The current users of the port must not be left in the cold all of
sudden (i.e. document any changes, EOLs etc), and the almost all of
"practical" installations need to keep working;
- Upgrades from sarge to etch must work
I'm not too sure if that's all, and that's just my personal opinion now,
but basically the porters define what the arch looks like. Of course,
there is a natural point in life where the definition changes (e.g. we
EOLed 80386 with sarge), and that's ok if documented properly. Of
course, something like e.g. droppen support of all but the lastest
i386-compatible CPUs wouldn't have been acceptable.