[Pkg-pascal-devel] units and library dependencies in Debian [WAS: Please remove svgalib support]

Abou Al Montacir abou.almontacir at sfr.fr
Sat Oct 5 16:35:27 UTC 2013


[+Peter as not yet subscribed to Pkg-pascal-devel]

On Sat, 2013-10-05 at 09:06 +0200, Paul Gevers wrote:
> Hi all,
> 
> On 04-10-13 19:51, Abou Al Montacir wrote:
> > I've removed bug address in order to discuss this in the list. I think
> > we should all agree on a resolution before adding it to the bug tracker.
Fine
> > On Fri, 2013-10-04 at 07:08 +0200, Paul Gevers wrote:
> >> On 03-10-13 22:38, peter green wrote:
> >>> Moritz Muehlenhoff wrote:
> >>> The practice adopted by the fpc package so-far has been to let the
> >>> upstream build process build these import units regardless of whether or
> >>> not debian supplies the corresponding libraries. If the libraries are in
> > That's right, it was always that way
> 
> Good. But lets agree that whatever we do doesn't mean we have to keep
> doing that just for that reason. My aim is to get the best solution.
I agree with you, what used to be is not the best and we can improve

> >>> debian we depend on them to make things work out of the box but if the
> >>> libraries aren't present in debian we just leave it up to the users to
> > However we should not depend on that, only recommend them as agreed
> > before
> 
> I still fully agree with this. I could also agree with suggests though.
> 
> > We only provide interfaces, not implementations. User should be able to
> > use his own libs especially when Debian do not provide them.
> 
> Sure, but we need to make this very clear. Especially if we want
> packages to be build in Debian in the future. It should be clear from
> the beginning that some things don't work. How about the following:
> 
> We keep shipping all the interfaces of upstream, but we put the
> interfaces for libraries that are not provided by Debian in a separate
> package called fp-units-no-debian-support or something like that. And
> have the package description state very clearly that the units provide
> interfaces for libraries that are not (yet/anymore) available in Debian.
Currently units are split by functional packages, if we do this, we may
need to mix units of different kinds, but this is fine if theses units
are in limited number

> >> Well, *I* don't like that. As discussed not so long ago, I consider it
> >> the task of the maintainer (and I start to consider myself fpc
> >> maintainer as well) to make sure the package works in Debian. That
> > I agree that we need to make sure the package work, but the definition
> > of how it works could depend on the person speaking.
> 
> Agree. But that is where the difference for depends/recommends/suggests
> comes into view.
> 
> > Yes of course, we need to ensure newbe could install and use fpc out of
> > the box, but keep in mind people with specific constraints like embedded
> > systems and low disk systems or low bandwidth. For this I think that
> > most of the libraries are not needed for most newbe programs
> 
> Same as above. I would say, libraries that are likely needed for an
> unit, than it should be recommends, else it can be a suggests.
> 
> >> Anyway, either way we go, I really think we should document these ideas
> >> really clearly in the README.Debian. I myself was surprised to find this
> >> out recently when I packaged view3dscene.
> > You are right, we need to document this. Also maybe we can add a small
> > piece of code asking to install what ever package is needed if the link
> > fails.
> 
> You mean to extend the link failure message, right? I like the idea. The
> message of missing units could use the same upgrade. I could easily find
> my way around, but I am unsure if it is clear that a units package is
We can provide with shipped units that are not supported by debian a
link error message that is used by the compiler/linker.
> missing. See also the latest question from an other pascal packager on
> this list.
For example?

Cheers,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <https://lists.alioth.debian.org/mailman/private/pkg-pascal-devel/attachments/20131005/e14e9a04/attachment.sig>


More information about the Pkg-pascal-devel mailing list