Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: phajdan.jr@g.o
Subject: Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)
Date: Wed, 08 Jun 2011 16:26:09
Message-Id: 20110608182540.15575fcd@pomiocik.lan
In Reply to: Re: [gentoo-dev] RFC: removal of by "Paweł Hajdan
On Wed, 08 Jun 2011 18:14:49 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote:

> On 6/8/11 4:17 PM, Michał Górny wrote: > > BTW if you'd like to create an eclass for that kind of live packages > > (which fetch packages from upstream), I could add smart rebuild > > possibility to start-live-rebuild [1]. This way, foo2zjs users > > would be able to upgrade their package whenever upstream tarball > > changes. > > > > [1]:https://github.com/mgorny/smart-live-rebuild > > Interesting, sounds like that could be useful. But I have no idea how > such an eclass would look like (rather trivial), and there are not > many packages that would use it (currently just one). > > How about PROPERTIES="live"? We could add "live" to possible values of > PROPERTIES...
That won't be enough. s-l-r has to get somehow the method of checking and the URL list. Right now, it is constructed in such a way that the method is based on VCS eclass being inherited, and then it grabs appropriate ebuild vars from environment.bz2. Such an eclass would have to take tarball URIs in some kind of envvar and export some kind of 'download timestamp'. Then the Python module in s-l-r would HEAD those URIs to get the current timestamp and compare that to the value exported in environment.bz2. -- Best regards, Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies