[Pkg-pascal-devel] Lazarus packaging model

Abou Al Montacir abou.almontacir at sfr.fr
Wed May 7 20:51:33 UTC 2014


On Wed, 2014-05-07 at 21:18 +0200, Paul Gevers wrote:
> On 06-05-14 23:00, Abou Al Montacir wrote:
> > I found it a pity that Debian drops old packages from archive when
> > upgrading sources to a new version, even if other packages depend on
> > them.
> 
> I think I understand what you mean, but what you write is not true.
> Exactly as long as other packages depend on them, they are not dropped.
> You can see that now with fpc. There are now both *-2.6.2 and *-2.6.4
> packages in sid. fpc is not allowed to migrate to testing until all
> dependencies on *-2.6.2 packages are fixed.
Yes indeed, but the same could be done for testing while it is not.

> > Otherwise, this could be solved easily. The version-named RTL
> > packages will stay in the archive until all the dependencies are gone.
> 
> This is what happens, but only in sid.
Yes

> > This means that a package should stay in the archive as long as it
> > belongs to the last source version or it is in dependency or build
> > dependency of another package in that archive. But I don't want to write
> > this to dd list at least before I can figure out what are the impacts.
> 
> Well, I think this is properly implemented for fpc via the fpc-abi-##
> provides of fpc-rtl package. The "pain" is that we have to start a
> transition for every fpc upstream update. That is something that we will
> have to do. [On the other hand, but I prefer not to go that route unless
> really needed, we can start to version the source packages and then we
> can have multiple versions (in Debian usually two are allowed, see e.g.
> python and emacs).]
It could make sense, but if we can skip this it would be better.

> The best strategy for the next fpc upstream version will be to stage it
> in experimental. Verify that all unit building dependencies (currently
> lazarus and castle-game-engine) build properly against the new version
> and fix any issues in experimental (or sid if the fixes are backwards
> compatible). If all build failures are fixed, we can then upload to sid
> and ask for binNMU's (like I did for lazarus last time).
This is probably the way to go. Anyway we already agreed to do this for
RC so that we gain time for the NEW queue.

BTW, does it make sense to split the compiler and the RTL sources.
Currently upstream is differentiating the compiler, the RTL and the FCL,
but are just making one release for everything due to lack of manpower.
Compiler is normally independent from units.
RTL is the system unit + other low level like SysUtils, Linux ...
FCL is a LCL like set of non graphical components + binding units.

Cheers,
Abou Al Montacir
-------------- 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: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20140507/11369699/attachment.sig>


More information about the Pkg-pascal-devel mailing list