Custom packages for different OS releases with identical (name, version, arch). Options?

[Andreas Ntaflos]

Hi,

How to best deal with custom packages that are built for different OS releases but are otherwise identical in name, version and architecture?

For example we build custom packages for Dovecot, the IMAP/POP3 server, for both Ubuntu 12.04 (precise) and Ubuntu 14.04 (trusty), but it is in both cases Dovecot 2.2.16 for amd64, i.e. the resulting package name is "dovecot_2.2.16-1custom1_amd64.deb" for both precise and trusty. The packages are of course different, as the software is compiled against different versions of libraries and the package has different dependencies on precise than it has on trusty.

As I understand it I can put the dovecot package for precise in one repo and the package for trusty in another repo, but I cannot publish both repositories under the same prefix. Is that correct?

The workflow thus far is this, which works fine:

$ aptly repo create -architectures="amd64,i386" -component=main -distribution=precise custom-packages-precise
$ aptly repo create -architectures="amd64,i386" -component=main -distribution=trusty custom-packages-trusty
$ aptly repo add custom-packages-precise ./precise-packages/dovecot_2.2.16-1custom1_amd64.deb
$ aptly repo add custom-packages-trusty ./trusty-packages/dovecot_2.2.16-1custom1_amd64.deb

Now for publishing (under the prefix "custom"):

$ aptly publish repo custom-packages-precise custom

The above works fine, but the following doesn't:

$ aptly publish repo custom-packages-trusty custom

Loading packages...

Generating metadata files and linking package files...

ERROR: unable to publish: unable to process packages: error linking file to /srv/aptly/public/custom/pool/main/d/dovecot/dovecot_2.2.16-1custom1_amd64.deb: file already exists and is different

So, if I wanted to publish both repos (custom-packages-precise and custom-packages-trusty) under the same prefix ("custom") I would have to name the packages differently, correct? For example "dovecot_2.2.16-1custom1~precise1_amd64.deb" and "dovecot_2.2.16-1custom1~trusty1_amd64.deb"?

Is this the idiomatic and canonical way to deal with packages of the same software built for different OS releases?

Thanks!

Andreas

[Andrey Smirnov]

Hi Andreas!

I believe this is the most frequently asked question about aptly :)

If I pretend to be Debian guy, I would say that you're doing it wrong, you should never produce different packages with identical name, version and architecture. One of the options is to include Ubuntu codename into version, as in the foreseeable future next version (precise, trusty) would be "greater" than previous one. So something like package_1.0.1~precise. 

If you still want to have the same (name, version, architecture), you should be prepared that dist-upgrade might be tricky. But for publishing you should publish under different prefixes to get separate pools.

--
You received this message because you are subscribed to the Google Groups "aptly-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aptly-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas Ntaflos]

Hi, thanks for the reply! Comments inline.

On 2015-05-14 00:36, Andrey Smirnov wrote:
> Hi Andreas!
>
> I believe this is the most frequently asked question about aptly :)

Maybe this topic should be a real FAQ entry on
http://www.aptly.info/doc/faq/ then? I know you discuss duplicate
packages in http://www.aptly.info/doc/feature/duplicate/ and partly in
http://www.aptly.info/doc/feature/multi-component/ but it couldn't hurt
to discuss this kind of use-case specifically.

> If I pretend to be Debian guy, I would say that you're doing it wrong,
> you should never produce different packages with identical name, version
> and architecture. One of the options is to include Ubuntu codename into
> version, as in the foreseeable future next version (precise, trusty)
> would be "greater" than previous one. So something like
> package_1.0.1~precise.

I know https://wiki.debian.org/RepositoryFormat#Duplicate_Packages says
(name, version, arch) must be unique in a repository but does that make
the use-case I describe invalid? Remember, that use-case is
custom-packaging software, such as Dovecot, for multiple Debian/Ubuntu
releases in the same version and arch. Many projects which provide
Debian packages also need to do this (e.g. PostgreSQL or Phusion Passenger).

Extending the version string is a workaround I can and probably will
use, and it seems repos such as apt.postgresql.org have a similar
approach (see
http://apt.postgresql.org/pub/repos/apt/pool/main/p/pgadmin3/ for
example). Passenger does it as well:
https://oss-binaries.phusionpassenger.com/apt/passenger/4/pool/main/p/passenger/

I would then probably name our Dovecot packages something like this:

dovecot_2.2.16-1custom1~12.04_amd64.deb
dovecot_2.2.16-1custom1~14.04_amd64.deb

Using the numeric release versions/identifiers (12.04 and 14.04) also
lends itself better to version comparison (14.04 is newer than 12.04).

I should probably re-read
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
to be safe.

> If you still want to have the same (name, version, architecture), you
> should be prepared that dist-upgrade might be tricky. But for publishing
> you should publish under different prefixes to get separate pools.

Dist-upgrading shouldn't be a problem when using the above approach of
appending the Ubuntu release version to the package version string,
should it?

I am not a fan of using different Aptly repo prefixes just to be able to
serve different Ubuntu releases.

For example this (in a machine's /etc/apt/sources.list):

deb http://apt.example.com/custom trusty main
deb http://apt.example.com/custom trusty release

deb http://apt.example.com/custom precise main
deb http://apt.example.com/custom precise devel

makes more sense to me than this:

deb http://apt.example.com/custom-trusty trusty main
deb http://apt.example.com/custom-trusty trusty release

deb http://apt.example.com/custom-precise precise main
deb http://apt.example.com/custom-precise precise devel

N.B.: here we also use components (main, release, devel, ...) which add
another layer of complexity.

Anyway, thanks for the feedback and pointers, I think I've got it now.

Andreas