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

Re: source dependencies - and recomndations



 Yann Dirson wrote
> Then, to reproduce a binary package, we need to specify *exactly* this
> set of packages used to build. 

yes, that's what we want.

> Further more, to *reproduce* a binary package, we might need to have
> dependencies on *exact versions*.

i don't think so. we use the latest stable version for stable releases
and the latest unstable version for unstable releases. exceptions (like
kernel 2.0.29) confirm this rule. 

the base for this is : new packages have closed bugs, so new versions
will fix bugs, and are welcome. if a new package does not fix bugs, we
still know, that the developer tested it, so it should work (and
unstable is the right place to test it). and if we don't know, if it
will still work - we use experimental.

stable versions are well tested, or fix bugs, so there is no reason not
to use the latest version. unstable version are to be tested, and should
work, so we use the latest unstable version to test them.

> This IMHO advocates the use, for reproductibility, of a specific field
> [let's call him Rebuilt-Deps: for discussion] (auto-generated on build
> ?), that would exactly list those packages from the source's
> {Depends,Recommends,Suggests}, with their versions, present on the
> system at binary built-time.

uh. no. we only want these dependencies (you call them "Rebuilt-Deps").
everything other is a nice thing, but that is not our goal.

we only create one version for debian, and we only support this version.
so we have to rebuild this version, and not something that is nearly the
same. 

if you want to build a differnt version for yourself - do you use debian
source for that ? most people use only the orig source or the orginal
source from sunsite and other archives, so i don't se where this can
help.

showing all alternatives how a source ban be build, that's a job for the
upstream authors, an of course we can help them with that goal. but it
simply doesn't make sence to implement this in debian, because we have
only one version of a package.

> Perhaps we should add support for those --with[out]-xxx stuff from
> autoconf, that would allow to make this latter type of dependencies a
> bit weeker when possible (ie. not having to uninstall a package just
> to allow rebuilt of another).

good idea. but not our job. that's for upstream maintainers. we want to
build a distribution, and not create a colelction of enhanced source.

>  > We could also list a Source-Alternatives: or so, to note that someone
>  > may use e.g. lex instead of flex or yacc instead of bison.
> 
> This would be made possible by my proposal without a
> Source-Alternatives field: alternatives would just be specified as
> they are for binary packages (ie. '|' operator or virtual packages),
> and the specific one used for build would be listed in the field I
> named Rebuilt-Deps. But that would make this field's auto-generation
> more difficult.

all these things are good ideas. but it's work to implement them, and
we will gain no profit. if we want this, we should do it independent
from debian and debian's source-dependencies, and implement it in
upstream source, so the whole linux community will profit.

> Then the Rebuilt-Deps field could be integrated in a binary package's
> control file (maybe as only Built-Deps), and inserted by 'bug' into
> bug-reports. This would at least speed up figuring-up this type of
> substitution.

we should only have "Source-Depend:" in the meaning of Rebuilt-Deps.
Everything other is a nice idea, but should be implemented in upstream
source. it's a different topic, here and now we only discuss what you
call "Rebuilt-Deps" (i call it Source-Dependencies).

so, can i get your vote for this form of "Source-Depend:" with
"Source-Depend-<arch>:", and without -Replaces, without -Alternative etc ?

andreas


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: