Launchpad logo and name.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index ][Thread Index ]

Re: My PPA experience



On 9/11/07, Michael Haas <laga@xxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I was asked to share my experiences with the new PPA feature. After a
> few rather large builds, I feel it's time to do that.
>
> I'm using a PPA to build MythTV from SVN trunk as part of the Mythbuntu
> project. We have a nifty build script which gets the latest MythTV code
> from their SVN server, grabs a debian/ directory from  bzr (hosted on
> Launchpad, thanks guys!) and creates four source packages: "mythtv"
> itself, "mythplugins" which link against the libmyth(-dev) package
> created by "mythtv" and two theme packages. Together, that's about 90M
> I'm uploading every time (theme packages are ~55M).
>
>
> After a few uploads, the status page reports: "Estimated archive size:
> 2.0 GiB" [1] which is twice as much as I'm allowed to use, AFAIK. Is
> there a hard quota? If yes, how big can a PPA get? If you look at [1],
> you'll find that old/superseded packages are still there. When are they
> removed? Maybe you should add an option to manually remove failed/old
> builds.

No, quota is not yet ensured, mostly because automatic removal of
superseded packages is not in place yet (see
https://bugs.launchpad.net/soyuz/+bug/128126). Once we start removing
superseded version I think your and other PPAs exceeding quota will
get back inside the allowed size limit.

'manual package removal UI' is also in our pipeline, see
https://bugs.launchpad.net/soyuz/+bug/128127.

> I had to rebuild quite often on the PPA to fix mistakes on my part and
> was actually afraid someone would yell at me for wasting ressources-
> what's the limit there?

No, but maybe we should think about it. I will raise this on "PPA 101"
next Thursday (you are welcome to join us).

(file a bug, please)

> Finally, the biggest problem I'm encountering:
> mythplugins needs to link against the libmyth packages created by the
> mythtv source package. However, sometimes the API version changes and
> the plugins built against an older version of the API don't work with a
> newer version of mythtv.
>
> Unfortunately, the PPA is not quite smart enough to wait for the mythtv
> package to be published before building mythplugins although mythplugins
> is listed as a build-dependency.
> While it is not *always* necessary to build against the lastest libmyth,
> it is *sometimes* necessary and TBH, re-uploading the package to kick
> off a new build is annoying.
> Even when I'm uploading them in the right order, eg uploading mythtv
> before mythplugins, it'll sometimes build mythplugins before mythtv.
> Could this be changed?
> Alternatively, the PPAs could have a smarter approach to resolving
> build-dependency. When two packages are upload, where one build-depends
> on the other one, build and publish the build-dependency first. Since my
> uploads are often queued for quite some time, this should be possible.

Well, this is an interesting question.
We do prioritize builds according their dependencies, but in your
case, you build-depend on *any* version of mythpluging and this is
obviously satisfied even when both new versions show up at the same
time.
My suggestion is to build-depended on specific version if that's what
you want, but I understand that it will require extra work on the
packaging side.

> Another thought: I'd be nice if I'd get an email once a build is finished.

We currently only notify users on build-failures, but I agree that
some people will be interested in successfully-built notifications
too.
Primary archive builds could also benefit of this, wider "package
subscription" feature, PPA is just pushing us to sort it quickly.

> OK, enough whining for today. You did a great job with the PPAs! Thanks!

Thank you, for using PPA and helping us to improve it.

[]
-- 
Celso Providelo <celso.providelo@xxxxxxxxx>




This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.

(Formatted by MHonArc.)