Make 'Origin' and 'Label' configurable for local repositories

[bracki]

Hi,

it would be great if Origin and Label would be configurable like in reprepro or freight.
This is quite useful for APT pinning.

Cheers,
Jan

[smira]

I think it's a good idea. Even though whole idea of aptly is to replace apt-pinning with predictable repository snapshots. You can pull from one snapshot into another to replace packages with the desired versions. If there are some other use cases I'm missing, I would be glad to hear from you.

[nightlyone]

if you have multiple package providers with even multiple incompatible major version for a package, then you need to pin. A good testcase of this behavior is at apt.puppetlabs.com. Try to get the 2.7.x version of puppet and run apt-get update; apt-get dist-upgrade to see why it is needed in the wild.

[smira]

For example, you're trying to pull version packet puppet from apt.puppetlabs.com into vanilla wheezy:

1. Create mirror of Debian wheezy
2. Create mirror of apt.puppetlabs.com
3. Create snapshots of both mirrors
4. Pull into wheezy snapshot from apt.puppetlabs.com packages you need:

aptly snapshots pull wheezy puppetlabs wheezy-with-puppet 'puppet (=2.7.5)'

Aptly would pull package puppet from snapshot puppetlabs along with dependencies that can't be satisfied in wheezy snapshot and create new snapshot wheezy-with-puppet. It would replace packages in wheezy if required. This snapshot would contain both Debian wheezy and version of puppet you need.

Would that help?

[nightlyone]

That would solve that specific use case. But lead to a lot of special repos conflicting with currently existing debian repository specific pinnings (e.g. take it from wheezy, but allow updates from wheezy-backports)

A bit more background:

Actually we (me and @bracki) are using already debmirror to get consistent snapshots + staged system package rollout from it. We are now trying to replace the tooling for various package sources and the tooling for generating custom package trees with aptly.

While iterating fast, we want to maintain a custom package source (maintained via aptly) and update from there. Later when the package is feature complete and becomes widely used, it moves into regular staged rollouts. So the custom package source (Origin in Debian terminology) should always be either prioritized up or down depending on the lifecycle stage of the package and its dependencies.

[smira]

Thanks for the explanation I'll put this to next release (0.5).

[smira]

Done in master.