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

[Abou Al Montacir]

Hi All,

I've fixed and committed, can someone upload please?

Cheers,
On Sat, 2013-10-05 at 18:35 +0200, Abou Al Montacir wrote:

> [+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,
> _______________________________________________
> Pkg-pascal-devel mailing list
> Pkg-pascal-devel at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-pascal-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.alioth.debian.org/mailman/private/pkg-pascal-devel/attachments/20131007/c6d58d4c/attachment.html>
-------------- 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/20131007/c6d58d4c/attachment.sig>