Deprecating (and deactivation) of an archive feature?! - Debian

This is a discussion on Deprecating (and deactivation) of an archive feature?! - Debian ; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiZ8dYACgkQxmow1UmK9uo8/ACePqo3GYANuR7xGcQLxd2n1x7X +OsAnjc1Y4qKAcdinQgI7S8IZjpXbBhT =4Iui -----END PGP SIGNATURE-----...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Deprecating (and deactivation) of an archive feature?!

  1. Deprecating (and deactivation) of an archive feature?!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkiZ8dYACgkQxmow1UmK9uo8/ACePqo3GYANuR7xGcQLxd2n1x7X
    +OsAnjc1Y4qKAcdinQgI7S8IZjpXbBhT
    =4Iui
    -----END PGP SIGNATURE-----

  2. Re: Deprecating (and deactivation) of an archive feature?!

    On Wed, Aug 6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote:

    > Now, the idea would be to deprecate this feature, used by 8 packages in
    > unstable, dropping complications in the database backend and the pool
    > layout which we would want to avoid.
    >

    Maybe you could tell us what the benefit of dropping this would be (as
    in, what are the changes you allude to, and why can't they work with
    this feature).

    Cheers,
    Julien


    --
    To UNSUBSCRIBE, email to debian-project-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Deprecating (and deactivation) of an archive feature?!

    Joerg Jaspert writes:

    > Now, the idea would be to deprecate this feature, used by 8 packages in
    > unstable, dropping complications in the database backend and the pool
    > layout which we would want to avoid.
    >
    > Yes, it would require those packages to have a new (additional, maybe
    > stripped to be smaller) source tarball for the one package in the other
    > component. Well. 8 of them. A very tiny set compared to the whole
    > archive, and the question is there if that really means we have to keep
    > it.


    I have no opinion one way or the other on the change, but wanted to note
    that Lintian had previously warned about this and we removed the warning
    at the request of one of the maintainers of those packages. (Bdale, I
    think, although I'm not sure.) So this feature is being intentionally
    used at present.

    > [1] this would also work with non-free. And by policy the source has to
    > be in the more-free component.


    Lintian only allows the main to contrib cross; non-free will always get
    warnings. The relevant tag is section-category-mismatch. (lintian.d.o
    doesn't check contrib or non-free, so I don't know if that tag appears
    anywhere in the archive. It doesn't appear for any packages in main,
    though.)

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-project-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: Deprecating (and deactivation) of an archive feature?!

    On Wed, Aug 06, 2008 at 08:47:50PM +0200, Joerg Jaspert wrote:
    >
    > But before we take a final decision I want to hear more input on it. So
    > here are your 5 seconds, please give input.


    To me, this sounds like a step in the right direction to unfuzzy the
    distinction between Debian itself (main) and the other archives we provide
    /support as a supplement to Debian.

    --
    Robert Millan

    The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
    how) you may access your data; but nobody's threatening your freedom: we
    still allow you to remove your data and not access it at all."


    --
    To UNSUBSCRIBE, email to debian-project-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Deprecating (and deactivation) of an archive feature?!

    * Julien Cristau [Wed, 06 Aug 2008 21:38:00 +0200]:

    > On Wed, Aug 6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote:


    > > Now, the idea would be to deprecate this feature, used by 8 packages in
    > > unstable, dropping complications in the database backend and the pool
    > > layout which we would want to avoid.


    > Maybe you could tell us what the benefit of dropping this would be (as
    > in, what are the changes you allude to, and why can't they work with
    > this feature).


    I agree this would be useful.

    I do think that allowing packages in main to provide binaries in contrib
    is useful, so I'd like to hear what the benefits would be if we'd agree
    to lose it.

    Thanks,

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    Listening to: Luke Vibert - Harmonic


    --
    To UNSUBSCRIBE, email to debian-project-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Deprecating (and deactivation) of an archive feature?!

    On Thu, Aug 07, 2008 at 01:28:49AM +0100, Adeodato Simó wrote:
    > I do think that allowing packages in main to provide binaries in contrib
    > is useful, so I'd like to hear what the benefits would be if we'd agree
    > to lose it.


    I have no idea if there are technical benefits in dropping the support
    for this. However, I do see a conceptual problem with the current
    organization for such a border case.

    *If* the directory organization in our mirrors should reflect what is
    part of Debian and what is not (and note that recently this assumption
    has been challenged), then the current situation is weird at best. We
    have source packages located, say, under
    /debian/dists/unstable/main/source/ which can possibly generated
    binaries belonging to contrib/.

    A user can be rightfully puzzled by such a situation: is the _source_
    package she is downloading part of Debian or not?

    Cheers.

    --
    Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
    zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
    I'm still an SGML person,this newfangled /\ All one has to do is hit the
    XML stuff is so ... simplistic -- Manoj \/ right keys at the right time

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQFImkq11cqbBPLEI7wRAoX6AKDAWkE99jHOj0yTP5Ax6Z wSaYHcWQCfanon
    gjg2joyPUzDCujPhtFhuQOQ=
    =kn9u
    -----END PGP SIGNATURE-----


  7. Re: Deprecating (and deactivation) of an archive feature?!

    Hi Joerg,

    Joerg Jaspert wrote:
    > currently our archive has the feature(?) that a source package in component a
    > (like main) can build a binary package in component b (like contrib).[1]
    >
    > Now, this feature is blocking (or making it way harder) to do some
    > database re-designs we want to do for the central archive database, so
    > we looked if there are real users of it. Well, yes, there are (damnit ):
    >
    >
    > In unstable we have
    >
    > Christian Holm Christensen
    > root-system

    [snip]

    Speaking as Christian's sponsor, would it be possible to postpone this
    redesign until after the release of Lenny? Otherwise it makes life
    somewhat difficult for those (and their sponsors :-) who maintain such
    packages and want to keep them in a good release status for Lenny.

    best regards,

    --
    Kevin B. McCarty
    WWW: http://www.starplot.org/
    WWW: http://people.debian.org/~kmccarty/
    GPG: public key ID 4F83C751


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFIoPFwfYxAIk+Dx1ERAp+CAJ9dEjWFikSIADpSe2Svkj 5nZuSxjgCgz1m6
    SjLtXZ7eIP2DbMEvzBRDtWQ=
    =u/95
    -----END PGP SIGNATURE-----


+ Reply to Thread