Obsoletion procedures?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Obsoletion procedures?

Max O Bowsher
Three of my library packages are going to be becoming obsolete in the
medium-term future.

libapr0 and libaprutil0 and their development packages apr and apr-util
are already used only by [prev] software.

libneon24 is used solely by [curr] cadaver, and [prev] subversion.

I'm soliciting opinions on how long library packages should remain after
they no longer are required by any other software in the distro.

Max.


signature.asc (195 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Obsoletion procedures?

Christopher Faylor-2
On Sun, Jun 11, 2006 at 03:52:26PM +0100, Max Bowsher wrote:

>Three of my library packages are going to be becoming obsolete in the
>medium-term future.
>
>libapr0 and libaprutil0 and their development packages apr and apr-util
>are already used only by [prev] software.
>
>libneon24 is used solely by [curr] cadaver, and [prev] subversion.
>
>I'm soliciting opinions on how long library packages should remain after
>they no longer are required by any other software in the distro.

I don't think any opinions are required.  We have a procedure for this.
The package move into the _obsolete category/_obsolete directory, and the
latest package becomes an empty .tar.bz2 file.

I don't see any reason to remove packages from the _obsolete category
once they are put there.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: Obsoletion procedures?

Max O Bowsher
Christopher Faylor wrote:

> On Sun, Jun 11, 2006 at 03:52:26PM +0100, Max Bowsher wrote:
>> Three of my library packages are going to be becoming obsolete in the
>> medium-term future.
>>
>> libapr0 and libaprutil0 and their development packages apr and apr-util
>> are already used only by [prev] software.
>>
>> libneon24 is used solely by [curr] cadaver, and [prev] subversion.
>>
>> I'm soliciting opinions on how long library packages should remain after
>> they no longer are required by any other software in the distro.
>
> I don't think any opinions are required.  We have a procedure for this.
> The package move into the _obsolete category/_obsolete directory, and the
> latest package becomes an empty .tar.bz2 file.
>
> I don't see any reason to remove packages from the _obsolete category
> once they are put there.

Sorry, I could have been clearer. The issue is that these are all
library packages, which people could conceivably have self-compiled
stuff depending upon.

I'd like some opinions on how long a real (not empty .tar) version of a
library should persist, after nothing in the distribution requires it
any more.


Max.



signature.asc (195 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Obsoletion procedures?

Yaakov (Cygwin/X)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Max Bowsher wrote:
> Sorry, I could have been clearer. The issue is that these are all
> library packages, which people could conceivably have self-compiled
> stuff depending upon.
>
> I'd like some opinions on how long a real (not empty .tar) version of a
> library should persist, after nothing in the distribution requires it
> any more.

The precedent seems to be to keep them indefinitely, unless they are
affected by security issues or are otherwise hopelessly broken.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEjvUgpiWmPGlmQSMRAicLAJ4+fMc4Hh2o7S451Zto899WNHbppQCdG/tP
XMBlkleQxvezJ91wDzPqkdE=
=YcO0
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Obsoletion procedures?

Charles Wilson-2
Yaakov S (Cygwin Ports) wrote:

> The precedent seems to be to keep them indefinitely, unless they are
> affected by security issues or are otherwise hopelessly broken.

Yep.  Just dump 'em over in _obsolete, make a copy of
<PKG>-x.y.z-r-src.tar.bz2 named lib<PKG>N-x.y.z-r-src.tar.bz2, remove
the external-src: line in the lib's setup.hint, and let it rot.

--
Chuck