version of packages from debian
There are already many packages coming from debian in our gitlab.
most of the have just one branch, the master one: which version of packages are in the master branch referring to debian? jessie? unstable? upstream/git versions?
We should probably re-import those packages where, for any single packages, we will import:
- upstraem / unrelased version to the master branch
- eventual pristine-tar branch from debian git repos to pristine-tar branch in our repo
- unstable source to unstable branch in our repo
- jessie source to jessie branch in our repo
This is needed as i'm setting up the package lifecycle buildflow to avoid later issues
I'm assigning this issue to jaromil cause i think he has done the first import of packages, but feel free to change assignation
-
Look at util-linux package, this is the basic schema to import as branches, except for experimental all other branches should be created on the first import of the package, where the upstream sources from debian are on the master branch, upstram-2.25 is the source only branch, pristine-tar is an empty branch used by pristinetar utility on build on jenkins hosts.
Anyway, in util-linux we have only master and not unstable/jessie branches cause the first import is from jessie package, but this is wrong, we should import from debian git head to master, and then one branch for every debian suite version.
Also, we need to choose how to rebase our sources to remain up-to-date, as, for example, debian is already on util-linux 2.25.2-5, we are on 2.25.2-4
-
ACK.
up-to-date sources: the SDK
version latest; import
command fetches new stable packages and creates new branches for them, which somehow simplifies the process. The present system was designed explicitly to not follow Debian's git and reduce the noise by concentrating on the package releases and merging them when required.I understand your point, I just prefer to keep the internal git flow in Debian opaque to my workflow.
Look at what Jude did in dbus, importing Debian's git in the SDK import. Is that ok?
-
Also a question regarding pinning and versioning:
In the current build Devuan has util-linux 2.25.2-4+devuan1
If Debian publishes 2.25.2-4 then are we sure that Devuan is not going to upgrade to it?
Is there a way to keep packages installed with a +devuan suffix only update from new packages that keep that suffix?
-
For pinning, we actually pin our repository to 700 against the debian origin pinned at 500 ( https://git.devuan.org/packages-base/devuan-baseconf/blob/master/data/etc/apt/preferences.d/devuan-repository )
This should be enough, it has to be tested anyway, and eventually raising up our pinning in the preference apt file
-
For how dbus is imported, it's ok but not needed to import all tags in debian, more important is to import the pristine-tar branch when present, and eventually the upstream branch.
Anyway, for me it's ok to create our own pristine-tar when needed, or to just import from debian and continue with our own workflow, but we need to choose which line to follow...
The main idea is that if we have to be 1:1 compatible with debian, at least for jessie, we need to match 1:1 the same versions, so, we also need to remain up-to-date with them.
Or, we can just get a package and continue referring to upstream wihout even care about what debian does?
It's ok both ways, but we need to choose one, and in any case we need to have in our repository the (possibily) not last upstream version for jessie, but also the last upstream for experimental/unstable and so on.
Having the jessie version in the master branch seems that we will be "old" even in unstable and experimental, isn't it?
-
For how dbus is imported, it's ok but not needed to import all tags in debian, more important is to import the pristine-tar branch > when present, and eventually the upstream branch.
I can take them out, if you'd prefer. I added them in just in case some Devuan users wanted to grab a particular version of dbus.
-
Jude no, that's ok
-
OK I like what Franco says here, hope you can put it down in a general guideline, where it can be specified the minimum necessary action to be taken (what branches are necessary). Jude's approach is a more complete import and I'd leave that to the discretion of maintainers.
What I'm really worried about is the package versioning, since if the
X
in-X+devuanY
is higher in debian repositories then I suspect that the package will be upgraded and overwritten by that from Debian. This must be avoided.I don't see many good solutions for this, but then my knowledge of apt and dpkg is limited. We need to know if there are solutions that can be built in, something like "upgrade +devuan packages only with other +devuan packages". Also adding this into the upstream apt code may be a solution.
-
There's another solution - we can offer a full repo and drop debian.org from sources.list. We can create a repo that has Debian's packages, plus our modified packages. Each time a Debian package gets updated, we push the update to our repos as well.
-
Fork package versioning, our pinning should be enough to avoid that, anyway, it's easy to be tested, and in case we will just need to raise up our pinning for devuan or to take down the debian repos pin precedence.
The Dima suggestion is another option, but i don't think will be necessary, at least for the moment
-
I'm starting to write down some docs about on how to import sources and how we will manage git repos schemas.
It's incomplete (yet), but still a start
https://git.devuan.org/devuan/devuan-maintainers/wikis/GitPackages
-
Great. OK lets try first partial mirror option, fiddle with pinning if it doesn't works and at last resort to full mirroring. I also thought about full mirroring but have doubts about it since I'm sure for a reason or another people will add debian repositories and then they may break Devuan - so better learn to resist their presence in any case.
-
Maybe we can fork apt and force to ignore debian repositories in case of full mirror? ( just joking, i'm not serious! )
-
This is fixed by using amprolla
-
Status changed to closed
-
Title changed from **version of packages from debian ** to version of packages from debian
-
Removed awaiting feedback label