I have DilOS - http://www.dilos.org
i abd try to do update to stretch versions, but i have no found tag 1.4.7 for apt what i can see on stretch release.
could you please help me identify changeset for 1.4.7 release?
i do apt mirror for my changes for DilOS on branch 'dilos' on separate repo:
it helps to me update version with changes related to builds on DilOS env.
also, additiona question: how can i tyr to upstream of my chnages to be more flexible with next APT updates?
On Sun, Aug 13, 2017 at 01:32:02AM +0300, Igor Kozhukhov wrote:
> could you please help me identify changeset for 1.4.7 release?
Sorry about that, the tag wasn't pushed, but it is now so here you go. :)
(And thanks for notifying us!)
> also, additiona question: how can i tyr to upstream of my chnages to be more flexible with next APT updates?
I had a quick look over the changes, but they aren't individual commits,
so that is a bit hard to deceiver what is changed and why. Some comments,
but you should really split the changes up so we can discuss them
individually (I am commenting mostly to give you an idea of what should
be individual, needs explaining & so on).
Some of them look like we could move them to the vendor/ system (like
the variable setting in apt-key.in as it was intended).
Other I don't understand like /bin/sh -> /bin/bash – are you telling me
that dilos has no shell in /bin/sh? Wouldn't that be really hard
compatibility wise as Debian packages assume left and right that /bin/sh
is a shell with the features required by Debian policy.
Removing systemd/symbolsfile/cron seems a bit overkill, we could just
not install them, couldn't we?
debian/apt.conf.autoremove we could either include by default or include
in a vendor/ specific configuration file.
Not creating and using _apt is a bit sad, is there a deeper reason this
doesn't work on dilos?
Re-enabling SHA1 is something we wont be very happy with.
The std::locale changes I don't understand – do those not work on dilos
or what is happening here?
The developer-java-jdk thingy we can do with some changes to the vendor/
system similar to how the keyring package name is vendored. For Debian
we don't need those dependencies anymore, but I can envision more
platform still having this deprecated java "annotation processing tool".
The zone feature I don't quite understand. It does look a bit like
a more user-friendly way of "install .debs in ~", something people
talked about recently in debian-devel@. Your BASEDIR also looks a bit
like what we since recently call DPKG_ROOT.
The "actual" porting things have some overlap with Julians previous
attempts at portability to Fink, MacOS and Freebsd , with some
commits merged some not. I e.g. see commits in there autodetecting
versionscript usage while you are removing it, so with some additional
work here we can probably merge those and benefit porting not just to
Dilos but other platforms as well.
I would be very happy if we can reach a "no source differences" stage between
Debian and Dilos, just like we have it with e.g. Ubuntu.
So long story short, feel free to contact us about these or other changes
here on the list and/or join our IRC channel #debian-apt for more impromptu
 branches in https://github.com/julian-klode/apt
signature.asc (849 bytes) Download Attachment
thanks for your reply.
please find my comments below inline.
thanks - will check it again soon.
one big update for better understanding - how much changes i did fro builds on DilOS :)
and yes - i have plans try to split it and try to upstream what will be possible for better upgrades in next time :)
let me explain here.
original OpenSolaris, like illumos, have default shell as /bin/sh -> /bin/ksh
KSH93 incompatible with BASH/DASH - we can’t use scripts from APT as is if we have system shell as KSH
it is why you can see my changes to use /bin/bash
i try to move to use /bin/sh -> /bin/dash on DilOS - as original Debian, but this work still in progress.
right now - i have DASH as deafult shell on my DilOS, but, i think, for better portability with others platforms, will be better to use /bin/bash as default shell for APT scripts - to avoid issues with others system shell.
on DilOS, as illumos platform, we have no systemd - we are using SMF Service Management Facility (SMF)
like this introduction:
it is why you can see removals of systemd definitions on my update.
well, i have plans put it back :)
right now - 'useradd' incompatible with Linux/FreeBSD platforms - and i’m working on 'adduser' updates, but it is still in progress
well, i’ll move to use your scheme when i’ll be ready for update of my repo - we can ignore these changes right now.
we have big issues with gcc libstdc++ and locales on illumos platforms - if we try to do the same - we have application crash to core dump.
i can see it on SPARC more time.
these changes here right now as workaround.
i don’t know where is issue - on gcc side or on illumos side - need a time for investigate it much more better for undertanding,
well, this dependency here as workaround - because this old package has been provided /usr/bin/apt file and i need replace it by APT package - please ignore it.
DPKG_ROOT and BASEDIR are slitly different.
are you familiar with solaris zones?
i have implemented it for bootstrap to another ROOT, like:
apt -R <PATH> install mypkg
where is: <PATH> = /zones/myzone/root
also, it is working fine with new ISO bootstrap like:
apt-get -R /path/to/my/new/iso install <list of packages>
it will install new packages to new directory where i can do next manupulations for ISO
it is working fine if i have list of repos defined at /etc/apt/sources.list - not only one repo as for debootstrap, but i can use list of repos.
my changes based on ideas/implementaion of IPS pkg5 package manager:
similar to this introduction.
it is working like: pkg -R <path> install <list of packages>
i have inplemented my changes to be more friendly for guys who wants to try to sue DPKG/APT on DilOS :)
well. Ubuntu = Linux, like Debian on Linux, but DilOS = illumos fork of OpenSolaris) - solaris based platform.
and yes - i’d like minimize my own changes in APT for better portability for better upgrades :)
and - i’m working on it.
right now i try to find solution - how to better detect DilOS as platform.
it is NOT solaris, like illumos, but i have additional changes on DilOS what are not available on illumos because they are wants to stay with his own opinion about primary shell and others tools - want are not applicable for Debian.
It is why i have my own illumos fork = DilOS - illumos kernel + some tools, but with more Debian userland friendly tools.
i want to have DilOS as platform for easy ports of userland applications from Debian upstream and i do updates on platform side for it too, what illumos do not want to do.
I hope on cooperation :)
also, you are welcome on FreeNode IRC #dilos with questions/updates.
also, i can provide DilOS bulid zone if needed - on Intel and SPARC - i try to support 2 platforms.
|Free forum by Nabble||Edit this page|