Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 02:18:41AM +0300, Antti-Juhani Kaijanaho wrote:
> If this is not acceptable, the amendment
> should be marked as rejected.
Na, better not. Let's hammer this one in shape now :)
> * Are Build-Conflicts really necessary?
> - they appear to be, reading the current list
> of build-dependencies used by sbuild.
Agreed. They may be rare, but necessary. In an ideal world, every
source generation scheme would allow for unlimited customization, but
unfortunately, we are far away from that goal :-/
> * Do we need to conditionalize the build dependencies based
> on architectures?
> - Joel Klecker and Marcus Brinkmann seem to think so.
> I'm not convinced yet.
Yes, we definitely need this. There are already packages that require this,
and there will be more (for example, when we will tackle upstream sources to
support special Hurd features, the package may need special Hurd libraries
to compile that are only available under Hurd architectures).
Ignoring this feature now would serve no one, as it must come anyway. Let's
do it right from the very beginning. (Look at the mess that the current
architecture setup, linux makedev in binary-all for example, very annoying
for the Hurd port. We should learn from this experience and not repeat such
overseights).
> - This would complicate the syntax
Only for those packages that make use of it! Those will be only a few
compared with the complete distribution for some time.
This is also not hard to implement. You can make use of dpkg-architecture in
dpkg-dev! This does already give you Debian arch name, GNU CPU and GNU
system string ("linux" or "gnu" for hurd).
If you want, you can leave this out of the implementation and I will do it
when the other features are all supported. Then I add this later-on. Nothing
requires the implementation to be perfect from the beginning, but let's
not go through the policy proposal/amendment cycle again just for this
additional feature, because this will delay it by several weeks.
> * If so, what syntax should we use?
> - My choice would be the "package (>= 42 i386)" syntax,
> as it's the least intrusive choice.
allright. But allow a seperator between version number and arch, like
"(>= 42, i386)" that's a bit easier on the mind.
> * Should we use four fields or six fields?
> - In my opinion the four-field choice offers no real
> advantages (I've discussed my position in detail earlier)
I think the six fields don't offer a real advantage over the four, but I have
no string feelings about this and either is fine for me.
> * When are versioned dependencies necessary?
> - Ian Jackson wants to allow the "current stable" as
> the base where versioned dependencies are not
> necessary
As stable changes, we would end up adding and removing version information in
each release. I don't see this happen (read: nobody will care and the
version info will stay even when a new stable is released), so I think in
practice most people will end up doing it the other way anyway:
> - I've stated my position earlier: use versioned dependencies
> every time the non-versioned dependencies would introduce
> a possibility of a broken build, regardless of releases.
> I'd like us to reach a consensus on these points during the week we have
> left. If we can't, the proposal should be marked rejected. (And possibly
> a new, revised proposal sent out, if necessary.)
As you see above, the only point that I definitely have a strong opinion
about is the arch specific source dependency. Other things I have
preferences, but either way will be fine for me.
Thanks for caring about this proposal,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: