Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Quoting Lev Lamberov (2020-06-07 08:31:12)
> Hi Jonas,
>
> Сб 06 июн 2020 @ 23:02 Jonas Smedegaard :
>
> > Quoting Lev Lamberov (2020-06-03 12:20:14)
> >> Пн 25 мая 2020 @ 12:32 Jonas Smedegaard :
> >>
> >> > Quoting Lev Lamberov (2020-05-25 12:19:07)
> >> >> I've just got some news from Jan Wielemaker. The next stable
> >> >> release of swi-prolog, branch 8.2, is almost ready. How are your
> >> >> experiments with depending on swi-prolog virtual packages going? I
> >> >> would like to package the current latest version and upload it into
> >> >> unstable for testing it with more installations, just to make sure
> >> >> there are no serious bugs and blockers for the release of 8.2
> >> >> branch.
> >> >
> >> > Sorry, I have not played with it at all, yet.
> >> >
> >> > Hope to find/make time for it later today. Will let you know when I
> >> > do!
> >>
> >> A couple days ago I uploaded new stable release of swi-prolog, 8.2.0,
> >> into unstable. This branch of swi-prolog will stay for a long period
> >> of time. Quite possible that it will be in Debian stable, since I
> >> don't think we'll see another stable release of swi-prolog before the
> >> coming freeze.
> >>
> >> Could you please upload eye rebuilt against swi-prolog 8.2.0?
> >> Currently swi-prolog are going to be removed from testing on June 22
> >> because of RC bug in 8.1.29, and there are some other packages
> >> depending on swi-prolog which are going to be removed too.
> >>
> >> Also, it would be nice if you can switch dependency on swi-prolog to
> >> one of its virtual packages. There are
> >> swi-prolog-abi-2-67-4369f15b-de23899e and swi-prolog-abi-foreign-2
> >> provided by swi-prolog-core. You may find more information about ABI
> >> versions in its NEWS.Debian and mentioned there upstream
> >> documentation.
> >
> > Eye updated now, using the new virtual ABI package, but unfortunately
> > couldn't move to lighter dependency than the -nox package as that has a
> > needed pcre module.
> >
> > I hope others will benefit from the package split. Speaking of which, I
> > suggest to have the core packages only suggest (not recommend) the -doc
> > package.
>
> Thanks!
>
> Guess we still need to ask for force migration, since as I can see eye
> is marked as migrating _after_ swi-prolog.
>
> Also, it would be nice to figure out which part of swi-prolog ABI
> version matters for eye. As Jan wrote there are
>
> > 2-67-792e14f8-de23899e
> >
> > - Backward compatibility version of the foreign interface is 2
> > - Saved state file format can be loaded when not older than 67
> > - 792e14f8 is a fingerprint for the C-defined foreign predicate
> > signatures.
> > - de23899e is a fingerprint of the VM instructions and their
> > signatures.
>
> IIRC this version are for 8.1.30, and for 8.2.0 (currently in Debian)
> the version is 2-67-4369f15b-de23899e, that is foreign predicate
> signatures were changed.
>
> IIRC eye contains some saved state files to make it run faster. So, does
> just saved state format matter for eye? If so, I'll make swi-prolog-core
> provide something like swi-prolog-abi-states-${...}. Cause the latter
> hashes are rather volatile, if I'm correct.
>
> Jos, Jan, could you give a hint on what matters for eye and which kind
> of Provides is better to have for it? The goal is to make swi-prolog
> updates possible without the need to rebuild eye each time, but rebuild
> still should be required in case there are some incompatible changes in
> swi-prolog (which should be reflected in its ABI).
I think one step towards generally more flexible packaging would be to
not offer 2 virtual ABI packages (foreing and all) but 5 (each component
and all). It would also help if you documented in README.Debian when
how to make use of those virtual packages (i.e. a more long-term
oriented place with all details, that you can point to from NEWS instead
of pointing to our bugtracker).
Thanks,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jonas,
Сб 06 июн 2020 @ 23:02 Jonas Smedegaard :
> Quoting Lev Lamberov (2020-06-03 12:20:14)
>> Пн 25 мая 2020 @ 12:32 Jonas Smedegaard :
>>
>> > Quoting Lev Lamberov (2020-05-25 12:19:07)
>> >> I've just got some news from Jan Wielemaker. The next stable
>> >> release of swi-prolog, branch 8.2, is almost ready. How are your
>> >> experiments with depending on swi-prolog virtual packages going? I
>> >> would like to package the current latest version and upload it into
>> >> unstable for testing it with more installations, just to make sure
>> >> there are no serious bugs and blockers for the release of 8.2
>> >> branch.
>> >
>> > Sorry, I have not played with it at all, yet.
>> >
>> > Hope to find/make time for it later today. Will let you know when I
>> > do!
>>
>> A couple days ago I uploaded new stable release of swi-prolog, 8.2.0,
>> into unstable. This branch of swi-prolog will stay for a long period
>> of time. Quite possible that it will be in Debian stable, since I
>> don't think we'll see another stable release of swi-prolog before the
>> coming freeze.
>>
>> Could you please upload eye rebuilt against swi-prolog 8.2.0?
>> Currently swi-prolog are going to be removed from testing on June 22
>> because of RC bug in 8.1.29, and there are some other packages
>> depending on swi-prolog which are going to be removed too.
>>
>> Also, it would be nice if you can switch dependency on swi-prolog to
>> one of its virtual packages. There are
>> swi-prolog-abi-2-67-4369f15b-de23899e and swi-prolog-abi-foreign-2
>> provided by swi-prolog-core. You may find more information about ABI
>> versions in its NEWS.Debian and mentioned there upstream
>> documentation.
>
> Eye updated now, using the new virtual ABI package, but unfortunately
> couldn't move to lighter dependency than the -nox package as that has a
> needed pcre module.
>
> I hope others will benefit from the package split. Speaking of which, I
> suggest to have the core packages only suggest (not recommend) the -doc
> package.
Thanks!
Guess we still need to ask for force migration, since as I can see eye
is marked as migrating _after_ swi-prolog.
Also, it would be nice to figure out which part of swi-prolog ABI
version matters for eye. As Jan wrote there are
> 2-67-792e14f8-de23899e
>
> - Backward compatibility version of the foreign interface is 2
> - Saved state file format can be loaded when not older than 67
> - 792e14f8 is a fingerprint for the C-defined foreign predicate
> signatures.
> - de23899e is a fingerprint of the VM instructions and their
> signatures.
IIRC this version are for 8.1.30, and for 8.2.0 (currently in Debian)
the version is 2-67-4369f15b-de23899e, that is foreign predicate
signatures were changed.
IIRC eye contains some saved state files to make it run faster. So, does
just saved state format matter for eye? If so, I'll make swi-prolog-core
provide something like swi-prolog-abi-states-${...}. Cause the latter
hashes are rather volatile, if I'm correct.
Jos, Jan, could you give a hint on what matters for eye and which kind
of Provides is better to have for it? The goal is to make swi-prolog
updates possible without the need to rebuild eye each time, but rebuild
still should be required in case there are some incompatible changes in
swi-prolog (which should be reflected in its ABI).
Cheers!
Lev
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Lev, Quoting Lev Lamberov (2020-06-03 12:20:14) > Пн 25 мая 2020 @ 12:32 Jonas Smedegaard : > > > Quoting Lev Lamberov (2020-05-25 12:19:07) > >> I've just got some news from Jan Wielemaker. The next stable > >> release of swi-prolog, branch 8.2, is almost ready. How are your > >> experiments with depending on swi-prolog virtual packages going? I > >> would like to package the current latest version and upload it into > >> unstable for testing it with more installations, just to make sure > >> there are no serious bugs and blockers for the release of 8.2 > >> branch. > > > > Sorry, I have not played with it at all, yet. > > > > Hope to find/make time for it later today. Will let you know when I > > do! > > A couple days ago I uploaded new stable release of swi-prolog, 8.2.0, > into unstable. This branch of swi-prolog will stay for a long period > of time. Quite possible that it will be in Debian stable, since I > don't think we'll see another stable release of swi-prolog before the > coming freeze. > > Could you please upload eye rebuilt against swi-prolog 8.2.0? > Currently swi-prolog are going to be removed from testing on June 22 > because of RC bug in 8.1.29, and there are some other packages > depending on swi-prolog which are going to be removed too. > > Also, it would be nice if you can switch dependency on swi-prolog to > one of its virtual packages. There are > swi-prolog-abi-2-67-4369f15b-de23899e and swi-prolog-abi-foreign-2 > provided by swi-prolog-core. You may find more information about ABI > versions in its NEWS.Debian and mentioned there upstream > documentation. Eye updated now, using the new virtual ABI package, but unfortunately couldn't move to lighter dependency than the -nox package as that has a needed pcre module. I hope others will benefit from the package split. Speaking of which, I suggest to have the core packages only suggest (not recommend) the -doc package. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jonas, Пн 25 мая 2020 @ 12:32 Jonas Smedegaard : > Quoting Lev Lamberov (2020-05-25 12:19:07) >> I've just got some news from Jan Wielemaker. The next stable release >> of swi-prolog, branch 8.2, is almost ready. How are your experiments >> with depending on swi-prolog virtual packages going? I would like to >> package the current latest version and upload it into unstable for >> testing it with more installations, just to make sure there are no >> serious bugs and blockers for the release of 8.2 branch. > > Sorry, I have not played with it at all, yet. > > Hope to find/make time for it later today. Will let you know when I do! A couple days ago I uploaded new stable release of swi-prolog, 8.2.0, into unstable. This branch of swi-prolog will stay for a long period of time. Quite possible that it will be in Debian stable, since I don't think we'll see another stable release of swi-prolog before the coming freeze. Could you please upload eye rebuilt against swi-prolog 8.2.0? Currently swi-prolog are going to be removed from testing on June 22 because of RC bug in 8.1.29, and there are some other packages depending on swi-prolog which are going to be removed too. Also, it would be nice if you can switch dependency on swi-prolog to one of its virtual packages. There are swi-prolog-abi-2-67-4369f15b-de23899e and swi-prolog-abi-foreign-2 provided by swi-prolog-core. You may find more information about ABI versions in its NEWS.Debian and mentioned there upstream documentation. Cheers! Lev
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Quoting Lev Lamberov (2020-05-25 12:19:07) > I've just got some news from Jan Wielemaker. The next stable release > of swi-prolog, branch 8.2, is almost ready. How are your experiments > with depending on swi-prolog virtual packages going? I would like to > package the current latest version and upload it into unstable for > testing it with more installations, just to make sure there are no > serious bugs and blockers for the release of 8.2 branch. Sorry, I have not played with it at all, yet. Hope to find/make time for it later today. Will let you know when I do! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jonas, I've just got some news from Jan Wielemaker. The next stable release of swi-prolog, branch 8.2, is almost ready. How are your experiments with depending on swi-prolog virtual packages going? I would like to package the current latest version and upload it into unstable for testing it with more installations, just to make sure there are no serious bugs and blockers for the release of 8.2 branch. Cheers! Lev
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
On 5/4/20 11:07 AM, Jonas Smedegaard wrote: > If perhaps your reason for fusing ABIs is that you are not a fan of > perl, then I would be happy to help write the perl code for a dh_* tool > which handles all 4 ABIs. It was a theoretical exercise. I'm not a fan of four virtual packages. One is already close to an overkill, surely at this point in time. There could be some point in two, one taking the first number and a second to join the rest or all four. The first is enough for packages that provide foreign extensions to SWI-Prolog. This allows creating Debian packages for most of the add-ons. The second is needed for saved states. Omitting the first number is possible for states that do not contain foreign extensions. It is very unlikely there will ever be a version update that changes the first number and leaves the others intact though: the stability goes down from left to right (which is why the last two are fingerprints rather than version numbers: I forgot to update them too often). Cheers --- Jan
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Lev,
On 5/3/20 6:32 PM, Lev Lamberov wrote:
Hi Jan and Jonas,
Чт 30 апр 2020 @ 20:36 Lev Lamberov :
So, my proposal is to have to following packages:
1. swi-prolog-core (with Core_system)
2. swi-prolog-core-packages (with Core_packages), depends on
swi-prolog-core
3. swi-prolog-nox (original swi-prolog-nox, but without
swi-prolog-{core,core-packages}), depends on
swi-prolog-{core,core-packages}
4. swi-prolog-x (without changes at the moment)
5. swi-prolog-java (without changes at the moment)
6. swi-prolog-bdb (without changes at the moment)
7. swi-prolog-odbc (without changes at the moment)
8. swi-prolog-doc (without changes at the moment)
9. swi-prolog-test (without changes at the moment)
10. swi-prolog, depends on swi-prolog-{nox,x} as we have now
11. swi-prolog-full, depends on swi-prolog and
swi-prolog-{java,odbc,bdb}, that is all swi-prolog packages (maybe
except swi-prolog-test)
I've just uploaded 8.1.30 to experimental. swi-prolog source package
builds 11 packages as in the quotation above. swi-prolog-core provides
virtual package swi-prolog-abi-$(swi-prolog:ABI), the value of
$(swi-prolog:ABI) is based on the output of swipl --abi_version and
massaged as follows:
$(shell LD_LIBRARY_PATH=debian/swi-prolog-core/usr/lib
debian/swi-prolog-core/usr/bin/swipl --abi-version | sed 's/swipl-abi//' | tr
-d '-')
I suggest 's/.*-abi-//' as the first part is basically flexible and may
vary with the name of SWI-Prolog. Personally I'd also be in favor of
not deleting the '-'. Jonas doesn't see the need for that either.
There is a logical structure in that. If you do it really correctly
you actually would have four virtual packages. eye, not relying on
foreign extensions (except bundled with SWI-Prolog) could than drop
dependency on this part. This is mostly theory though as this is
the most stable of the binary interfaces.
Cheers --- Jan
That is, for 8.1.30+dfsg-1 it gives 267792e14f8de23899e, since the
output of swipl --abi_version is swipl-abi-2-67-792e14f8-de23899e. So,
other packages may depend on swi-prolog-abi-267792e14f8de23899e in case
they need this particular version of ABI.
Jonas, I did some tweaks to dependencies, so this part should be cleaner
now.
Also, I looked into the eye package. It need pcre swi-prolog package,
which is in swi-prolog-nox (as before), so you still need to at least
Build-Depend on it.
Cheers!
Lev Lamberov
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jan and Jonas,
Пн 04 мая 2020 @ 11:07 Jonas Smedegaard :
> Quoting Jan Wielemaker (2020-05-04 09:32:52)
>> On 5/3/20 6:32 PM, Lev Lamberov wrote:
>> > Чт 30 апр 2020 @ 20:36 Lev Lamberov :
>> >
>> >> So, my proposal is to have to following packages:
>> >>
>> >> 1. swi-prolog-core (with Core_system)
>> >>
>> >> 2. swi-prolog-core-packages (with Core_packages), depends on
>> >> swi-prolog-core
>> >>
>> >> 3. swi-prolog-nox (original swi-prolog-nox, but without
>> >> swi-prolog-{core,core-packages}), depends on
>> >> swi-prolog-{core,core-packages}
>> >>
>> >> 4. swi-prolog-x (without changes at the moment)
>> >>
>> >> 5. swi-prolog-java (without changes at the moment)
>> >>
>> >> 6. swi-prolog-bdb (without changes at the moment)
>> >>
>> >> 7. swi-prolog-odbc (without changes at the moment)
>> >>
>> >> 8. swi-prolog-doc (without changes at the moment)
>> >>
>> >> 9. swi-prolog-test (without changes at the moment)
>> >>
>> >> 10. swi-prolog, depends on swi-prolog-{nox,x} as we have now
>> >>
>> >> 11. swi-prolog-full, depends on swi-prolog and
>> >> swi-prolog-{java,odbc,bdb}, that is all swi-prolog packages (maybe
>> >> except swi-prolog-test)
>> >
>> > I've just uploaded 8.1.30 to experimental. swi-prolog source package
>> > builds 11 packages as in the quotation above.
>
> Nice. When NEW processing (hopefully) succeeds, I will look further at
> making use of the restructed packages for eye.
>
>
>> > swi-prolog-core provides virtual package
>> > swi-prolog-abi-$(swi-prolog:ABI), the value of $(swi-prolog:ABI) is
>> > based on the output of swipl --abi_version and massaged as follows:
>> >
>> > $(shell LD_LIBRARY_PATH=debian/swi-prolog-core/usr/lib
>> > debian/swi-prolog-core/usr/bin/swipl --abi-version | sed 's/swipl-abi//' |
>> > tr -d '-')
>>
>> I suggest 's/.*-abi-//' as the first part is basically flexible and may
>> vary with the name of SWI-Prolog. Personally I'd also be in favor of
>> not deleting the '-'. Jonas doesn't see the need for that either.
>> There is a logical structure in that. If you do it really correctly
>> you actually would have four virtual packages. eye, not relying on
>> foreign extensions (except bundled with SWI-Prolog) could than drop
>> dependency on this part. This is mostly theory though as this is
>> the most stable of the binary interfaces.
>
> If Lev finds it easier to maintain all 4 ABIs fused together as one,
> then that's fine by me.
>
>
>> > That is, for 8.1.30+dfsg-1 it gives 267792e14f8de23899e, since the
>> > output of swipl --abi_version is swipl-abi-2-67-792e14f8-de23899e.
>
> ...I do worry, though, about the way you fuse them together. Virtual
> package names are permitted to contain dashes (single ones in the
> middle), and because not all ABI parts are fixed-length stripping dashes
> introduces a slight risk of different ABI combinations clashing.
>
> In other words, if you do want to have Debian packaging present only one
> ABI (not some or all of the 4 exposed individually,,,
4 different ABIs... Hmmm, it fact it sounds interesting. What do you
(both) think about swi-prolog-core providing the following virtual
packages:
- swi-prolog-abi-foreign-FABI (currently, 2),
- swi-prolog-abi-binary-BABI (currently, 67),
- swi-prolog-abi-qlf-QLF (currently, 792e14f8),
- swi-prolog-abi-states-SSTATES (currently, de23899e)?
Or maybe even 5 virtual packages, the listed above plus
swi-prolog-abi-ABI, where ABI is 2-67-792e14f8-de23899e (that is,
without dashes)?
Since all of the values for FABI, BABI, and so on are fetched
programmatically, it is not a problem at all to provide such packages.
So, I propose
$(swi-prolog:ABI) = $(shell LD_LIBRARY_PATH=debian/swi-prolog-core/usr/lib
debian/swi-prolog-core/usr/bin/swipl --abi-version | sed 's/.*-abi-//')
$(swi-prolog:FABI) = $(shell LD_LIBRARY_PATH=debian/swi-prolog-core/usr/lib
debian/swi-prolog-core/usr/bin/swipl --abi-version | sed 's/.*-abi-//' | cut
--delimiter=- -f 1)
And so on with '-f 1' to '-f 4'.
What do you think?
I can upload swi-prolog with these changes right after it is processed
in NEW. Anyway I should add Breaks and Replaces to make updating from
older versions smooth.
Cheers!
Lev
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Quoting Jan Wielemaker (2020-05-04 09:32:52)
> On 5/3/20 6:32 PM, Lev Lamberov wrote:
> > Чт 30 апр 2020 @ 20:36 Lev Lamberov :
> >
> >> So, my proposal is to have to following packages:
> >>
> >> 1. swi-prolog-core (with Core_system)
> >>
> >> 2. swi-prolog-core-packages (with Core_packages), depends on
> >> swi-prolog-core
> >>
> >> 3. swi-prolog-nox (original swi-prolog-nox, but without
> >> swi-prolog-{core,core-packages}), depends on
> >> swi-prolog-{core,core-packages}
> >>
> >> 4. swi-prolog-x (without changes at the moment)
> >>
> >> 5. swi-prolog-java (without changes at the moment)
> >>
> >> 6. swi-prolog-bdb (without changes at the moment)
> >>
> >> 7. swi-prolog-odbc (without changes at the moment)
> >>
> >> 8. swi-prolog-doc (without changes at the moment)
> >>
> >> 9. swi-prolog-test (without changes at the moment)
> >>
> >> 10. swi-prolog, depends on swi-prolog-{nox,x} as we have now
> >>
> >> 11. swi-prolog-full, depends on swi-prolog and
> >> swi-prolog-{java,odbc,bdb}, that is all swi-prolog packages (maybe
> >> except swi-prolog-test)
> >
> > I've just uploaded 8.1.30 to experimental. swi-prolog source package
> > builds 11 packages as in the quotation above.
Nice. When NEW processing (hopefully) succeeds, I will look further at
making use of the restructed packages for eye.
> > swi-prolog-core provides virtual package
> > swi-prolog-abi-$(swi-prolog:ABI), the value of $(swi-prolog:ABI) is
> > based on the output of swipl --abi_version and massaged as follows:
> >
> > $(shell LD_LIBRARY_PATH=debian/swi-prolog-core/usr/lib
> > debian/swi-prolog-core/usr/bin/swipl --abi-version | sed 's/swipl-abi//' |
> > tr -d '-')
>
> I suggest 's/.*-abi-//' as the first part is basically flexible and may
> vary with the name of SWI-Prolog. Personally I'd also be in favor of
> not deleting the '-'. Jonas doesn't see the need for that either.
> There is a logical structure in that. If you do it really correctly
> you actually would have four virtual packages. eye, not relying on
> foreign extensions (except bundled with SWI-Prolog) could than drop
> dependency on this part. This is mostly theory though as this is
> the most stable of the binary interfaces.
If Lev finds it easier to maintain all 4 ABIs fused together as one,
then that's fine by me.
> > That is, for 8.1.30+dfsg-1 it gives 267792e14f8de23899e, since the
> > output of swipl --abi_version is swipl-abi-2-67-792e14f8-de23899e.
...I do worry, though, about the way you fuse them together. Virtual
package names are permitted to contain dashes (single ones in the
middle), and because not all ABI parts are fixed-length stripping dashes
introduces a slight risk of different ABI combinations clashing.
In other words, if you do want to have Debian packaging present only one
ABI (not some or all of the 4 exposed individually), then I agree with
Jan that this is both simpler and safer:
$(shell LD_LIBRARY_PATH=debian/swi-prolog-core/usr/lib
debian/swi-prolog-core/usr/bin/swipl --abi-version | sed 's/.*-abi-//')
If perhaps your reason for fusing ABIs is that you are not a fan of
perl, then I would be happy to help write the perl code for a dh_* tool
which handles all 4 ABIs.
> So,
> > other packages may depend on swi-prolog-abi-267792e14f8de23899e in case
> > they need this particular version of ABI.
> >
> > Jonas, I did some tweaks to dependencies, so this part should be
> > cleaner now.
> >
> > Also, I looked into the eye package. It need pcre swi-prolog
> > package, which is in swi-prolog-nox (as before), so you still need
> > to at least Build-Depend on it.
Thanks for noticing that detail!
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jan and Jonas,
Чт 30 апр 2020 @ 20:36 Lev Lamberov :
> So, my proposal is to have to following packages:
>
> 1. swi-prolog-core (with Core_system)
>
> 2. swi-prolog-core-packages (with Core_packages), depends on
> swi-prolog-core
>
> 3. swi-prolog-nox (original swi-prolog-nox, but without
> swi-prolog-{core,core-packages}), depends on
> swi-prolog-{core,core-packages}
>
> 4. swi-prolog-x (without changes at the moment)
>
> 5. swi-prolog-java (without changes at the moment)
>
> 6. swi-prolog-bdb (without changes at the moment)
>
> 7. swi-prolog-odbc (without changes at the moment)
>
> 8. swi-prolog-doc (without changes at the moment)
>
> 9. swi-prolog-test (without changes at the moment)
>
> 10. swi-prolog, depends on swi-prolog-{nox,x} as we have now
>
> 11. swi-prolog-full, depends on swi-prolog and
> swi-prolog-{java,odbc,bdb}, that is all swi-prolog packages (maybe
> except swi-prolog-test)
I've just uploaded 8.1.30 to experimental. swi-prolog source package
builds 11 packages as in the quotation above. swi-prolog-core provides
virtual package swi-prolog-abi-$(swi-prolog:ABI), the value of
$(swi-prolog:ABI) is based on the output of swipl --abi_version and
massaged as follows:
$(shell LD_LIBRARY_PATH=debian/swi-prolog-core/usr/lib
debian/swi-prolog-core/usr/bin/swipl --abi-version | sed 's/swipl-abi//' | tr
-d '-')
That is, for 8.1.30+dfsg-1 it gives 267792e14f8de23899e, since the
output of swipl --abi_version is swipl-abi-2-67-792e14f8-de23899e. So,
other packages may depend on swi-prolog-abi-267792e14f8de23899e in case
they need this particular version of ABI.
Jonas, I did some tweaks to dependencies, so this part should be cleaner
now.
Also, I looked into the eye package. It need pcre swi-prolog package,
which is in swi-prolog-nox (as before), so you still need to at least
Build-Depend on it.
Cheers!
Lev Lamberov
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jan,
Чт 30 апр 2020 @ 15:33 Jan Wielemaker :
> On 4/30/20 3:10 PM, Lev Lamberov wrote:
> > Recently I was (again!) approached by some embedded developers who asked
> > to provide Core_system as a separate package and try to break
> > swi-prolog-nox into several smaller packages.
> >
> > Currently, I'm thinking about breaking it into swi-prolog-core
> > (containing Core_system), swi-prolog-core-packages (containing
> > Core_packagse; depends on swi-prolog-core) and swi-prolog-nox
> > (containing other components from the original swi-prolog-nox; depends
> > on swi-prolog-core and swi-prolog-core-packages). What do you think
> > about it?
>
> As long as swi-prolog-nox still provides a useable Prolog system I'm
> happy. I would go with Jonas in that case though and have yet another
> basic package that just contains the shared object and possibly the main
> executable and boot file (swipl.prc)
>
> Just the shared object is enough to create runtimes when using
> --stand-alone as this creates a file that starts with the swipl
> executable. Adding the swipl executable to the base package allows to
> start the state with some option and makes the state smaller (but not
> much, `swipl` is really short). Adding the boot.prc file adds only 90Kb
> and actually allows running Prolog. Without libraries, but you could
> distribute the essentials with some application as .pl or .qlf files.
>
> If we rethink from the start, my ideal is that "swi-prolog" creates a
> pretty much complete installation, including xpce (gui, ide). Yes, there
> are quit a few dependencies, but virtually every desktop installation
> has most of these installed anyway.
>
> Then we can have some hierarchy below that. Some parts are clear, but
> the real dependencies between the various packages is largely unknown
> and easily varies between versions. If you are interested I could come
> up with some meaningful splits.
>
> Bottom line should be just the real core (as above), which is enough to
> run saved states. You than have two options for saved states relying
> on foreign packages: include the package in the saved state or install
> the package.
So, my proposal is to have to following packages:
1. swi-prolog-core (with Core_system)
2. swi-prolog-core-packages (with Core_packages), depends on
swi-prolog-core
3. swi-prolog-nox (original swi-prolog-nox, but without
swi-prolog-{core,core-packages}), depends on
swi-prolog-{core,core-packages}
4. swi-prolog-x (without changes at the moment)
5. swi-prolog-java (without changes at the moment)
6. swi-prolog-bdb (without changes at the moment)
7. swi-prolog-odbc (without changes at the moment)
8. swi-prolog-doc (without changes at the moment)
9. swi-prolog-test (without changes at the moment)
10. swi-prolog, depends on swi-prolog-{nox,x} as we have now
11. swi-prolog-full, depends on swi-prolog and
swi-prolog-{java,odbc,bdb}, that is all swi-prolog packages (maybe
except swi-prolog-test)
Later we can break swi-prolog-nox into smaller parts, but I don't think
it is necessary to do this now. I'd prefer not to hurry with these
changes, let's have it as a goal for the next Debian release.
Another thing mentioned by Jonas is that swi-prolog-nox depends on -dev
packages (libedit-dev, libgmp-dev, libncurses-dev, libreadline-dev).
These are development libraries, that is they contain header files to
link against these libraries. This requires installing some other
development packages. Moreover, sometimes development packages are
somewhat large (say, installed size of libgmp10 is 579 KB, but installed
size of libgmp-dev is 1952 KB). So, one of the arguments of breaking
swi-prolog packages into smaller parts is that it will make possible to
install only what is needed also in terms of development packages.
Cheers!
Lev
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Lev, On 4/30/20 3:10 PM, Lev Lamberov wrote: > Recently I was (again!) approached by some embedded developers who asked > to provide Core_system as a separate package and try to break > swi-prolog-nox into several smaller packages. > > Currently, I'm thinking about breaking it into swi-prolog-core > (containing Core_system), swi-prolog-core-packages (containing > Core_packagse; depends on swi-prolog-core) and swi-prolog-nox > (containing other components from the original swi-prolog-nox; depends > on swi-prolog-core and swi-prolog-core-packages). What do you think > about it? As long as swi-prolog-nox still provides a useable Prolog system I'm happy. I would go with Jonas in that case though and have yet another basic package that just contains the shared object and possibly the main executable and boot file (swipl.prc) Just the shared object is enough to create runtimes when using --stand-alone as this creates a file that starts with the swipl executable. Adding the swipl executable to the base package allows to start the state with some option and makes the state smaller (but not much, `swipl` is really short). Adding the boot.prc file adds only 90Kb and actually allows running Prolog. Without libraries, but you could distribute the essentials with some application as .pl or .qlf files. If we rethink from the start, my ideal is that "swi-prolog" creates a pretty much complete installation, including xpce (gui, ide). Yes, there are quit a few dependencies, but virtually every desktop installation has most of these installed anyway. Then we can have some hierarchy below that. Some parts are clear, but the real dependencies between the various packages is largely unknown and easily varies between versions. If you are interested I could come up with some meaningful splits. Bottom line should be just the real core (as above), which is enough to run saved states. You than have two options for saved states relying on foreign packages: include the package in the saved state or install the package. Cheers --- Jan > > Cheers! > Lev >
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jan, Чт 30 апр 2020 @ 14:40 Jan Wielemaker : > In theory we could have a package that merely contains /usr/bin/swipl > and /usr/lib/libswipl.so.8.2.0. That is enough to run saved states > (provided they have been built such that no dependencies need to be > loaded at runtime) and is indeed a lot smaller than swi-prolog-nox. > Possibly bundle these two as swi-prolog-runtime and make swi-prolog-nox > depend on it? > > A small problem is that running `swipl` will result in a big ugly error > message that it cannot find its startup resources. One could add > boot.prc to the runtime package which would allow running Prolog (but > without any library). > > I'm pretty neutral in this. Eye is for the time being the only > use case, but who knows there will be more :) Recently I was (again!) approached by some embedded developers who asked to provide Core_system as a separate package and try to break swi-prolog-nox into several smaller packages. Currently, I'm thinking about breaking it into swi-prolog-core (containing Core_system), swi-prolog-core-packages (containing Core_packagse; depends on swi-prolog-core) and swi-prolog-nox (containing other components from the original swi-prolog-nox; depends on swi-prolog-core and swi-prolog-core-packages). What do you think about it? Cheers! Lev
