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

Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages



(Note: I wrote my second reply before polling my mail, so it is a bit out of
sync to this mail :)

On Sat, Aug 07, 1999 at 05:33:32PM +0300, Antti-Juhani Kaijanaho wrote:
> On Sat, Aug 07, 1999 at 04:08:56PM +0200, Marcus Brinkmann wrote:
> > Are you actually involved in any of our porting efforts?
> 
> No, as I don't have the required hardware.

Then please trust the experience of porters like Joel, Roman and me in this
one point at least.

> > or at least check one of the mailing lists frequently, to learn what
> > is involved.
> 
> I lurk on several Hurd lists, including debian-hurd.
> 
> > Don't forget that Debian is not Linux anymore
> 
> I'm not forgetting that.  But there is another point of trying to
> make sure Debian is as same as possible in its all incarnations, in
> one release.

This is another story. It is definitely something to consider for the user
interface (same package management, same over-all design), but definitely
not at system level. Especially not at the level where you compile parts of
the low level operating system!

> Architecture-dependent build dependencies can lead into
> forgetting that goal.  (Could we agree on a phrase in policy in the style
> of "don't use the architecture-dependent build dependencies unless you
> really have to"?)

There are two things here. Of course, I don't want architecture specific
dependencies where a bug or source incompatibility is preventing compilation
of the package with a certain set of packages.

But for additional features only some supported operating systems can provide
I think it is a good idea to enable them and suck in further dependencies if
required.

For example, if a Hurd specific addition to the tar program (support for
translators) would make it necessary to link tar with the hurd libraries,
we need those libraries on the Hurd only.

I can understand your concern of "bad" use of arch specific source
dependencies, but I think I have two reasons why they won't be a big deal:

. The porter and the maintainer are often different persons. This raises the
barrier to add unnecessary source-dependencies and will make sure that more
than two eyes watch over it.
. In my experience, different source dependencies can hardly solve any
incompatibility problems on the user level.

Especially the first argument is very strong. Then, it is in everybodies
interest that the source dependencies are clean.

To answer your question: I think we can agree on such a phrase, but not in
the way you said it. There is no need to "discourage" proper use of arch
specific source dependencies. I am currently lacking some imagination. Can
anybody come up with a good wording?

Something like: "General source dependencies are preferred over architecture
specific dependencies". (to make it sound positive and not negative).

However, as we can't specify *when* arch specific source dependencies are
required, it doesn't matter much. I doubt that any such a phrase would have a
huge impact on the way arch specific source dependencies can be used. But it
does not harm to mention it either. So just do it :)

> > Are you converted now? :)
> 
> Possibly.  I see your point and I trust that you wouldn't put this much
> effort to convince me if you didn't believe in what you're saying ;-)

Definitely :) The real reason I am putting this pressure on you is that I am
leaving for holidays next tuesday, and won't come back in the discussion
time of this proposal.

Thanks,
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: