| 1 |
On Wed, 08 Jun 2011 18:14:49 +0200 |
| 2 |
""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
| 3 |
|
| 4 |
> On 6/8/11 4:17 PM, Michał Górny wrote: |
| 5 |
> > BTW if you'd like to create an eclass for that kind of live packages |
| 6 |
> > (which fetch packages from upstream), I could add smart rebuild |
| 7 |
> > possibility to start-live-rebuild [1]. This way, foo2zjs users |
| 8 |
> > would be able to upgrade their package whenever upstream tarball |
| 9 |
> > changes. |
| 10 |
> > |
| 11 |
> > [1]:https://github.com/mgorny/smart-live-rebuild |
| 12 |
> |
| 13 |
> Interesting, sounds like that could be useful. But I have no idea how |
| 14 |
> such an eclass would look like (rather trivial), and there are not |
| 15 |
> many packages that would use it (currently just one). |
| 16 |
> |
| 17 |
> How about PROPERTIES="live"? We could add "live" to possible values of |
| 18 |
> PROPERTIES... |
| 19 |
|
| 20 |
That won't be enough. s-l-r has to get somehow the method of checking |
| 21 |
and the URL list. Right now, it is constructed in such a way that |
| 22 |
the method is based on VCS eclass being inherited, and then it grabs |
| 23 |
appropriate ebuild vars from environment.bz2. |
| 24 |
|
| 25 |
Such an eclass would have to take tarball URIs in some kind of envvar |
| 26 |
and export some kind of 'download timestamp'. Then the Python module in |
| 27 |
s-l-r would HEAD those URIs to get the current timestamp and compare |
| 28 |
that to the value exported in environment.bz2. |
| 29 |
|
| 30 |
-- |
| 31 |
Best regards, |
| 32 |
Michał Górny |
Archives