Re: Going ahead with non-free-firmware
Hi, On Sun, 24 Feb 2019 16:44:39 +0100 Ansgar wrote: > Sadly no; I think some later discussion made me doubt that there was > indeed consensus about having non-free-firmware (and only that and not > non-free-doc, non-free-drivers, non-free-*). Nor about how it would > work. > > I don't think we should add a new component without having that > (component meaning main, contrib, non-free, non-free-firmware here). > They are not nice to handle on the archive side. Thanks for your reply. Well, then is there any proposal to improve setting non-free firmware in installer now? -- Hideki Yamane
Re: Going ahead with non-free-firmware
Hi, Hideki Yamane writes: > Is there any progress about non-free-firmware section? Sadly no; I think some later discussion made me doubt that there was indeed consensus about having non-free-firmware (and only that and not non-free-doc, non-free-drivers, non-free-*). Nor about how it would work. I don't think we should add a new component without having that (component meaning main, contrib, non-free, non-free-firmware here). They are not nice to handle on the archive side. Ansgar >> Hi, >> >> I think there was consensus to introduce the non-free-firmware section >> and move the non-free firmware blobs there. I'm wondering what we need >> to do next? >> >> Besides the ftp team setting the new section up, I expect the installer >> would need changes to enable it instead of non-free when non-free >> firmware is required; maybe it still needs to ask for non-free as well >> for other reasons? Other teams might also need to add the new section, >> e.g. the release team, packages.d.o, ... I expect the list to be >> hard-coded in quite a few places. >> >> Then the release notes need to document that "non-free-firmware" might >> have to be added to sources.list. >> >> Finally we need to identify the packages that should move there. I >> guess all non-free packages named "firmware-*" would be a good match. >> >> Ansgar
Re: Going ahead with non-free-firmware
Hi, Is there any progress about non-free-firmware section? > Hi, > > I think there was consensus to introduce the non-free-firmware section > and move the non-free firmware blobs there. I'm wondering what we need > to do next? > > Besides the ftp team setting the new section up, I expect the installer > would need changes to enable it instead of non-free when non-free > firmware is required; maybe it still needs to ask for non-free as well > for other reasons? Other teams might also need to add the new section, > e.g. the release team, packages.d.o, ... I expect the list to be > hard-coded in quite a few places. > > Then the release notes need to document that "non-free-firmware" might > have to be added to sources.list. > > Finally we need to identify the packages that should move there. I > guess all non-free packages named "firmware-*" would be a good match. > > Ansgar -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Re: Going ahead with non-free-firmware
On Sat, 9 Jan 2016 19:27:22 -0500 Hendrik Boomwrote: > On Sat, Jan 09, 2016 at 10:36:53PM +0100, Philippe Cerfon wrote: > > And btw: > > Even if Debian doesn't want to do the non-open thing now or perhaps > > generally doesn't want to allow people to opt-out of closed source > > software while keeping other non-free software, then the name > > non-free-firmware seems to break the current naming, doesn't it? > > main > > contrib > > non-free > > > > These all give the "license status" of their packages. > > But non-free-firmware, would give license status and package type. > > > > > > Oh and since this has been brought up by someone. > > It seems better if packages wouldn't be in multiple suites. > > That's also what I'd have intended with non-open, in other words, a > > package that is in non-open is only there and not also in e.g. > > non-open/firmware (and vice versa). > > Maybe closed-source would be clearer than non-open. > > -- hendrik > One thing that really bugs me about the Debian component system is failure to differentiate between software (the functional component to any computer system) and data (the non-functional component of a computer hardware/software system). Example: I personally oppose non-free software and will not install or run it. But I have no such qualms about non-free data- that is something for the free *culture* movement, not the free *software* movement- of which Debian is a project, and in which Debian should maintain its focus. The inclusion of both non-free software and data in non-free means that in order to use, say, AlienArena, which is free software but relies on non-free data, one must enable both non-free and contrib! It is a pretty silly situation- that in order to play a free game one must sacrifice their freedom and enable the non-free component. I would divide the Debian package repository as follows: 1. free-software This would be for free software. 2. free-data This would be for free data. 3. non-free-software This would be for non-free software. 4. non-free-data This would be for non-free data. One could go even further and divide the non-free-software component into components based on exactly *what* freedom is being withheld- so 'drm' (for freedom 0), 'no-source' (for freedom 1), 'non-redistributable' (for freedom 2) and 'non-modifiable' (for freedom 3) or something along those lines. Of course, being a free software fanatic myself, I would prefer that Debian just stopped encouraging the use of and distributing non-free software, but since that isn't happening anytime soon, I see this as the best solution.
Re: Going ahead with non-free-firmware
On Sat, 9 Jan 2016 20:56:08 +0800 Paul Wisewrote: > On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote: > > > I think there was consensus to introduce the non-free-firmware section > > and move the non-free firmware blobs there. I'm wondering what we need > > to do next? > > I have a question about the implementation; will non-free firmware be > in non-free and non-free-firmware or just non-free-firmware? > If one wanted both non-free firmware and other non-free packages one would simply enable both non-free and non-free-firmware. There need be no duplication of package placement.
Going ahead with non-free-firmware
Hi, I think there was consensus to introduce the non-free-firmware section and move the non-free firmware blobs there. I'm wondering what we need to do next? Besides the ftp team setting the new section up, I expect the installer would need changes to enable it instead of non-free when non-free firmware is required; maybe it still needs to ask for non-free as well for other reasons? Other teams might also need to add the new section, e.g. the release team, packages.d.o, ... I expect the list to be hard-coded in quite a few places. Then the release notes need to document that "non-free-firmware" might have to be added to sources.list. Finally we need to identify the packages that should move there. I guess all non-free packages named "firmware-*" would be a good match. Ansgar
Re: Going ahead with non-free-firmware
On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote: > I think there was consensus to introduce the non-free-firmware section > and move the non-free firmware blobs there. I'm wondering what we need > to do next? I have a question about the implementation; will non-free firmware be in non-free and non-free-firmware or just non-free-firmware? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Going ahead with non-free-firmware
Ansgar Burchardt(2016-01-09): > I think there was consensus to introduce the non-free-firmware section > and move the non-free firmware blobs there. I'm wondering what we need > to do next? > > Besides the ftp team setting the new section up, I expect the installer > would need changes to enable it instead of non-free when non-free > firmware is required; maybe it still needs to ask for non-free as well > for other reasons? Other teams might also need to add the new section, > e.g. the release team, packages.d.o, ... I expect the list to be > hard-coded in quite a few places. As far as the installer goes, I suspect things like the following packages might need to be looked at: - apt-setup - discover, discover-data Mraw, KiBi. signature.asc Description: Digital signature
Re: Going ahead with non-free-firmware
And btw: Even if Debian doesn't want to do the non-open thing now or perhaps generally doesn't want to allow people to opt-out of closed source software while keeping other non-free software, then the name non-free-firmware seems to break the current naming, doesn't it? main contrib non-free These all give the "license status" of their packages. But non-free-firmware, would give license status and package type. Oh and since this has been brought up by someone. It seems better if packages wouldn't be in multiple suites. That's also what I'd have intended with non-open, in other words, a package that is in non-open is only there and not also in e.g. non-open/firmware (and vice versa). Thanks and regards, Philippe
Going ahead with non-free-firmware
Ansgar Burchardt wrote: > I think there was consensus to introduce the non-free-firmware > section > and move the non-free firmware blobs there. I'm wondering what we > need > to do next? While it's good that at least something happens it's really sad and kinda disturbing to see that a more narrow-minded solution is taken, while a better proposal lies on the table. Especially since the non-free-firmware seems to make it less likely, that a non-open could ever happen. When Debian is anyway about to add new suites and people will have to adapt to that, why not implementing a more powerful schema that not only allows to opt-in to closed-source firmware, but also allows to, at the same time, opt-out of other closed-source software, while allowing at the same time to opt-IN to non-free, but open software? It'll be just one further suite that needs to be added, gaining far more possibilities. - non-free (as the current non-free, excluding anything that would need to go to non-open) - non-open (everything from non-free for which there are no sources available) - non-open/firmware (firmware that would be in non-open) perhaps arguably a 4th one: - non-free/firmware (i.e.that would be firmware that is open but not e.g. freely distributable, but does that even exist?) Alternatively one could just have: - non-free (as the current non-free, excluding anything that would need to go to non-open) - non-open (everything from non-free for which there are no sources available) - firmware (any non-free or non-open firmware) So again, what's wrong with the proposal I've made few days ago in #809705? It doesn't seem to require much more technical work, just moving packages and it's a far more powerful solution. Sincerely, Philippe.
Re: Going ahead with non-free-firmware
On Sat, Jan 09, 2016 at 10:36:53PM +0100, Philippe Cerfon wrote: > And btw: > Even if Debian doesn't want to do the non-open thing now or perhaps > generally doesn't want to allow people to opt-out of closed source > software while keeping other non-free software, then the name > non-free-firmware seems to break the current naming, doesn't it? > main > contrib > non-free > > These all give the "license status" of their packages. > But non-free-firmware, would give license status and package type. > > > Oh and since this has been brought up by someone. > It seems better if packages wouldn't be in multiple suites. > That's also what I'd have intended with non-open, in other words, a > package that is in non-open is only there and not also in e.g. > non-open/firmware (and vice versa). Maybe closed-source would be clearer than non-open. -- hendrik