:: Re: [devuan-dev] RFC: Package and s…
Startseite
Nachricht löschen
Nachricht beantworten
Autor: Ivan J.
Datum:  
To: svante.signell, devuan developers internal list
Betreff: Re: [devuan-dev] RFC: Package and source naming, package building and lintian fixes document proposal
On Wed, 15 Nov 2017, Svante Signell wrote:

> Package naming (debian/changelog)
> ======================================
> Packages forked from Debian: 
> <source package> (<debian version>+<devuan version>)
>
> Devuan packages with an upstream (not forked from Debian):
> <source package> (<upstream version>+<devuan version>)
>
> Devuan native packages:
> <source package> (<package name>+<devuan version>)
>
> To be discussed: d1h version is 0.2+4


I agree with the former.

The second one, "Devuan packages with an upstream that is not Debian",
we will have to evaluate this per-package. It's a good thing that you
wrote the difference between Devuan natives and packages with an
upstream. For "Devuan native packages" I would only consider packages
like "jenkins-debian-glue-buildenv-devuan", "d1h", etc. - packages that
are very specific to Devuan. These do not need +<devuan version> as we
can be sure they will not be included in Debian. As for "Devuan packages
with an upstream", this would be eudev and such. In most cases we will
need +<devuan version> since we can not be sure if Debian will ever
package them or not. Saying this, we'll need a clear separation of what
is a Devuan native package and what is not.


> Package building
> ================
> Not yet completed: <TBW>


If this is about the process of building a package normally, it is
documented on the Debian wiki in a couple of places.

On the other hand, if it's about including and building it on ci.do,
yes, we will have to document this.

> debian/source/format: Z = 3.0 (quilt), 3.0 (native), 3.0 (git)
>
> <architecture> W = alpha, amd64, arm64, armel, armhf, hppa, i386, ia64, mips,
> mipsel, powerpc, ppc64el, s390x, sparc
> (are all these really supported?)


We are currently building amd64, i386, and arm*. Hopefully, as we get
more hardware in the future, we will start supporting the other
architectures as well. Keep in mind we are already merging all those
architectures in amprolla3, but we have not built our packages for them.

> gbp.conf content:
> <TBW>


In most cases it is the same and we should be able to be provide a
template. Though lately, Buster and Sid packages already have a gbp.conf
that might or might not work for us.

> Packages forked from Debian:
> <TBW>
>
> Devuan packages with an upstream:
> <TBW>


The above two should have the same procedure when it comes to building.
For forking, there is the option of forking it manually, or using d1h.
Also as mentioned, if this is about including on ci.do, it will need
documenting.

--
~ parazyd
GnuPG: 03337671FDE75BB6A85EC91FB876CB44FA1B0274
GnuPG: https://parazyd.cf/FA1B0274.asc