Deprecating (and deactivation) of an archive feature?!
  Home FAQ Contact Sign in
linux.debian.project only
 
Advanced search
POPULAR GROUPS

more...

linux.debian.project Profile…
 Up
Deprecating (and deactivation) of an archive feature?!         


Author: Joerg Jaspert
Date: Aug 6, 2008 11:50

Hi

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

Debian ALSA Maintainers lists.alioth.debian.org>
alsa-tools

Debian GNOME Maintainers lists.alioth.debian.org>
gnome-speech (U)

Debian Qt/KDE Maintainers lists.debian.org>
kdeaccessibility

Bdale Garbee gag.com>
gnuradio
Show full article (2.73Kb)
11 Comments
Re: Deprecating (and deactivation) of an archive feature?!         


Author: Julien Cristau
Date: Aug 6, 2008 12:40

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
no comments
Re: Deprecating (and deactivation) of an archive feature?!         


Author: Russ Allbery
Date: Aug 6, 2008 13:30

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.
Show full article (1.46Kb)
no comments
Re: Deprecating (and deactivation) of an archive feature?!         


Author: Robert Millan
Date: Aug 6, 2008 13:50

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
no comments
Re: Deprecating (and deactivation) of an archive feature?!         


Author: Adeodato Simó
Date: Aug 6, 2008 17:40

* 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
Show full article (1.05Kb)
no comments
Re: Deprecating (and deactivation) of an archive feature?!         


Author: Stefano Zacchiroli
Date: Aug 6, 2008 18:10

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.
Show full article (1.37Kb)
no comments
Re: Deprecating (and deactivation) of an archive feature?!         


Author: Charles Plessy
Date: Aug 6, 2008 19:20

Le Wed, Aug 06, 2008 at 10:07:01PM -0300, Stefano Zacchiroli a écrit :
>
> A user can be rightfully puzzled by such a situation: is the _source_
> package she is downloading part of Debian or not?

Hi Stefano, Jörg, and everybody.

In the end, the contrib category is free software, so why not simply
downgrade it as a priority level, lower than "extra"? This would solve
the problem for our puzzled users as well as for the developpers
packaging software that is partially dependant on things not available
in the main archive, and the consistency of the Debian operating system
would be:
- guaranteed for packages of priority optional or higher,
- possibly conflicutal for extra packages,
- defective by missing dependancies for contrib packages.

Have a nice day,

--
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan
Show full article (1.00Kb)
no comments
Re: Deprecating (and deactivation) of an archive feature?!         


Author: Russ Allbery
Date: Aug 6, 2008 19:40

Charles Plessy debian.org> writes:
> In the end, the contrib category is free software, so why not simply
> downgrade it as a priority level, lower than "extra"?

I'm assuming that you mean doing this instead of keeping it as a separate
distribution area.
> This would solve the problem for our puzzled users as well as for the
> developpers packaging software that is partially dependant on things not
> available in the main archive, and the consistency of the Debian
> operating system would be:
> - guaranteed for packages of priority optional or higher,
> - possibly conflicutal for extra packages,
> - defective by missing dependancies for contrib packages.

I think it would be very surprising to have installation of a package from
the main distribution area result in downloading non-free software from
elsewhere, which is a common case for contrib packages.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Show full article (1.11Kb)
no comments
Re: Deprecating (and deactivation) of an archive feature?!         


Date: Aug 6, 2008 20:10

Charles Plessy debian.org> writes:
> In the end, the contrib category is free software

The works in 'contrib' are free software. That's not enough for them
to be in 'main', because 'main' is defined as more than just an
arbitrary collection of free software. 'main' is the Debian operating
system, which must, when installed, be useable as a whole without
requiring non-free software on the system.

Hence, anything which can't satisfy 'main' (because, for example, it's
not useable without some non-free software) doesn't belong in 'main'.
Hence, the existence of 'contrib', to take works that are themselves
free software, but can't be part of the Debian operating system.

--
\ “Today, I was -- no, that wasn't me.” —Steven Wright |
`\ |
_o__) |
Ben Finney

--
To UNSUBSCRIBE, email to debian-project-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
no comments
Source packages in main building contrib binary packages.         


Author: Charles Plessy
Date: Aug 6, 2008 21:30

Le Wed, Aug 06, 2008 at 07:37:47PM -0700, Russ Allbery a écrit :
>
> I think it would be very surprising to have installation of a package from
> the main distribution area result in downloading non-free software from
> elsewhere, which is a common case for contrib packages.

Le Thu, Aug 07, 2008 at 01:07:11PM +1000, Ben Finney a écrit :
>
> The works in 'contrib' are free software. That's not enough for them
> to be in 'main', because 'main' is defined as more than just an
> arbitrary collection of free software. 'main' is the Debian operating
> system, which must, when installed, be useable as a whole without
> requiring non-free software on the system.

Hi again,

I think that if we were shipping a package whose description says
"Install this and you will have your 3D working" and which would
automatically download non-free software, we would indeed cheat our
users.
Show full article (2.57Kb)
no comments
1 2