Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
On Wed, Apr 24, 2013 at 09:43:48PM +0200, Guillem Jover wrote: ... A distribution (any, most) is the gel that binds and gives an unified and coherent shape to the software ecosystem. +1 (to everything even the cutted part) An app store is just like a scrapyard, you might find magnificent and isolated gems there, but most of it will probably be junk, or not combine with the other scrap parts. I honestly wonder if there is some more general definition for the term app store besides what according to[1] certain companies have made out of it. Following the logic that app store is crap because some companies provide it as such we are terribly lucky that they did not choose the term distribution for their crap. I personally can not find something wrong in a *generic* term application store and I would not seriously object if someone would call Debian an app store done the right way. Where Debian's efforts should be focused is on things like license verification and helping bug reports and fixes get to upstream. So basically, getting rid of most of the fun stuff and turning it into a lawyerish play-ground and support center... I'd venture to say, not the most attractive work for most people here if it was the only thing to be done, which we do because we think it's important non the less. +1 Kind regards Andreas. [1] http://en.wikipedia.org/wiki/App_Store -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425072059.gd23...@an3as.eu
Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
On 2013-04-24 12:43, Guillem Jover wrote: Hi! On Sat, 2013-04-20 at 11:05:29 -0700, Clint Byrum wrote: [...]. IMO this is why upstream packaging should be embraced and enhanced rather than focusing on dpkg. I'm not sure if you refer to the tool here, or to the packaging work, doesn't change much anyway. I'm referring to delivering software in general, most of which falls into a few categories which are not a programming language, plumbing, and system development tools. I once worked on the 'pkgme' project for Ubuntu and there have been others, but never followed through. The idea was just to build debian source packages from upstream sources. Upstreams should be able to release a package which serves their needs, and Debian should be able to consume these almost directly. Respectfully, I think you've entirely missed the point of a distribution (and sadly I'm seeing this trend more often than before now, with all the hype around app stores and similar...). Packaging and maintaining a consistent and unified distribution cannot be delegated to upstreams (and I'm talking as an upstream developer here too), because that entails a bit more than slapping some files somewhere, tarring the thing up and calling it a day. Indeed, there is a great deal of hard work in putting together an operating system. But for the bulk of software, things like MongoDB included, I see very little point in distributions spending a lot of time tweaking and poking and prodding the software to work into a grand policy. For the most part, developers ship and test a good tarball that builds with some pretty standard and easy to detect options. The bits where that doesn't work ought be fixed upstream, and I know sometimes they are, but in the mean time, the distribution maintainers (myself included) spend their precious time conforming to the broken upstream, instead of the other way around. Building a nice distribution requires a high-level view and QA of the entire system; requires curating sane namespaces, be them on the package/project names, on the version strings, on the filesystem (by avoiding file collisions, using alternatives or diversions), on exposed programming interfaces, etc; requires making sure a diverse set of programs interact correctly with each other; performing security updates; ideally keeping single runtime versions; doing global transitions to use other or newer runtimes, programs, libraries or packages; an unified way to build from sources to cope with the endless and interesting different upstream build systems; porting and building for different binary architectures, not just what upstream might have around; documentation; translation; tagging stuff with metadata to allow for easy searches; excision of the embedded code copies cancer; even stuff like how the Delete and Backspace keys should behave; sets a qualify bar for upstream projects, stuff of low quality will not be accepted most of the time; license checks; etc, etc... All of the things you mention are huge accomplishments, but the scope is what I am suggesting has gotten out of hand. Do we really need a high level view and QA of the entire system for MongoDB? It is a daemon and some client tools. If I install it from tarball, I know this is shocking, but it actually works fine and doesn't interfere with anything else. If it does, I will complain to upstream. My suggestion is not to stop packaging, but to shift focus from make an awesome package to make an awesome upstream that results in an automatically generated awesome package. Debhelper and many of the other tools definitely help with this, but we can do more. And all this, upstream will never be able to provide (at least not as defaults), because each distribution has its own policies, some are better, some are worse, and some are just different. In general I'd never trust the packaging produced by an upstream for a distribution they are not involved in. But most of the time there will be no such packages for the desired distribution anyway. Debian wants to provide end-to-end generalized tight integration. Thus packages lagging behind upstream. I'm suggesting that this tight integration ideal actually *limits* the scope of Debian. Although there's been work on creating distribution-neutral specs that some upstreams have picked up, there's always going to be something new, the specs will just not cover all needed things, the specs might not be liked by some/many people, or might not have been fully adopted by all upstreams. Right, and Debian maintainers can, and will keep bending over backward to get all the upstreams into Debian. That doesn't mean its a good use of someone's time. A distribution (any, most) is the gel that binds and gives an unified and coherent shape to the software ecosystem. An app store is just like a scrapyard, you might find magnificent and isolated gems there, but most of it will probably be junk,
Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
Le Thu, Apr 25, 2013 at 01:50:58AM -0700, Clint Byrum a écrit : My suggestion is not to stop packaging, but to shift focus from make an awesome package to make an awesome upstream that results in an automatically generated awesome package. Debhelper and many of the other tools definitely help with this, but we can do more. Hi Clint, indeed, we do more: http://wiki.debian.org/UpstreamGuide Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425094629.gf21...@falafel.plessy.net
Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
Quoting Andreas Tille (2013-04-25 09:20:59) On Wed, Apr 24, 2013 at 09:43:48PM +0200, Guillem Jover wrote: ... A distribution (any, most) is the gel that binds and gives an unified and coherent shape to the software ecosystem. +1 (to everything even the cutted part) An app store is just like a scrapyard, you might find magnificent and isolated gems there, but most of it will probably be junk, or not combine with the other scrap parts. I honestly wonder if there is some more general definition for the term app store besides what according to[1] certain companies have made out of it. Following the logic that app store is crap because some companies provide it as such we are terribly lucky that they did not choose the term distribution for their crap. I personally can not find something wrong in a *generic* term application store and I would not seriously object if someone would call Debian an app store done the right way. If by not seriously object you mean that you would object but with a smile and continue your great meal together, rather than leave the party and file a lawsuit, then I agree with you... To me, calling Debian an app store would be only misleading. To me an app store is for topping op a system, not the system itself. Debian is no app store: content is not only apps nor app-centric, and aim is not to archive nor to sell, but to streamline and distribute. When I need an alternative term to describe what distribution means, I use library: Like librarians we care not only about the individual books of software, and not only about the novels, but about long-term cohesive structure of the library as a whole. Libraries also has the connotation of collecting dust which arguably is descriptive for (stable) Debian as well ;-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425100011.12767.1...@bastian.jones.dk
Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
On 25-04-13 10:50, Clint Byrum wrote: On 2013-04-24 12:43, Guillem Jover wrote: All of the things you mention are huge accomplishments, but the scope is what I am suggesting has gotten out of hand. Do we really need a high level view and QA of the entire system for MongoDB? We don't need it for MongoDB, but we do need it for Debian. The difference might seem to be minor, but it isn't. It is a daemon and some client tools. If I install it from tarball, I know this is shocking, but it actually works fine and doesn't interfere with anything else. That's fine, great, and dandy. But it's besides the point. I would hope that all upstream software works fine and doesn't interfere with anything else if installed from tarball. If it doesn't, they seriously need to check what they're doing. But Debian packages go beyond work fine. They are integrated. If there are other packages out there that do similar functionality to whatever it is that MongoDB does (I don't have a clue, but it doesn't matter for this discussion; I guess it's some sort of database), then it's reasonable to expect that a MongoDB package would need to behave similarly to those other packages. For a database server, this could include things like: - making sure the data is stored in the right location in the file system; e.g., postgresql upstream assumes all its stuff (binaries, configuration, data files) are stored in a single directory. Given their background (they support way more systems than we do; e.g., they also support Windows) this makes sense, but that doesn't mean we should, too. - If it's an SQL database, integrating everything with dbconfig-common. This is a Debian-specific thing to make installing database-using packages easier; it makes no sense whatsoever to push this upstream. - ... probably others, but I'm not very fluent in packaging of database systems. If it does, I will complain to upstream. My suggestion is not to stop packaging, but to shift focus from make an awesome package to make an awesome upstream that results in an automatically generated awesome package. Debhelper and many of the other tools definitely help with this, but we can do more. Yes, we do have a guideline that says you should push improvements upstream if and when they make sense there, and that is more often the case than you'd think if you were just looking at the number of patches that flow upstream. But making a distribution is so much more than just checking licenses and converting source into installable packages. Take, for instance, the apache packages. If you were to just take the upstream source, compile, and install it, then it would also Just Work. But it wouldn't have the same flexibility that the Debian packages have. On Debian, you can just install some libapache-mod-foo package, and due to how the configuration files are arranged, it will simply work. This kind of integration isn't something that can (or should!) be done upstream; it's squarely inside the realm of what a distribution does. The amount of such integration is part of what makes a distribution unique; some distributions tend to do this more than others, and at one extreme of this are Arch and Slackware, who make it a policy to ship upstream source as pristine as possible. Debian is clearly not at that extreme, and it should not be, IMO; the high level of integration, the expectation that I can have from the behaviour of a package that's part of Debian is what attracted me to Debian in the first place, and if we ever lose that I'll probably start looking for a different distribution. And all this, upstream will never be able to provide (at least not as defaults), because each distribution has its own policies, some are better, some are worse, and some are just different. In general I'd never trust the packaging produced by an upstream for a distribution they are not involved in. But most of the time there will be no such packages for the desired distribution anyway. Debian wants to provide end-to-end generalized tight integration. Thus packages lagging behind upstream. I'm suggesting that this tight integration ideal actually *limits* the scope of Debian. Sometimes packages are lagging behind, yes, and that's a problem; but I don't agree that the tight integration lies at the root of that problem. When done right, this kind of integration consists of just a few files inside a debian/ directory; they should not interfere with packaging a new upstream version. Yes, there are exceptions, and we should strive to eliminate such cases. Sometimes this is because upstream is no longer active; sometimes this happens because the maintainer isn't doing a good (enough?) job. Whatever the reason, it's something we should try to fix. But just throwing our hands up in the air and saying that we should therefore give up on trying to integrate isn't the right way forward, I'd say. [...] Although there's been work on creating distribution-neutral specs
Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
Hi, On Thu, Apr 25, 2013 at 12:00:11PM +0200, Jonas Smedegaard wrote: Quoting Andreas Tille (2013-04-25 09:20:59) I honestly wonder if there is some more general definition for the term app store besides what according to[1] certain companies have made out of it. Following the logic that app store is crap because some companies provide it as such we are terribly lucky that they did not choose the term distribution for their crap. I personally can not find something wrong in a *generic* term application store and I would not seriously object if someone would call Debian an app store done the right way. If by not seriously object you mean that you would object but with a smile and continue your great meal together, rather than leave the party and file a lawsuit, then I agree with you... It depends with whom I share that great meal. If it is my father I would simply say yes. If it is my son I would mind explaining the difference. Rationale: I have installed Debian on my fathers box and told him how he can install additional applications. Once you have a basic system running the Debian mirror serves as an app store and it makes actually the point for this kind of user (and a lot of other users as well). To me, calling Debian an app store would be only misleading. Yes. That's why I would not call Debian an app store to *you*. To me an app store is for topping op a system, not the system itself. There are actually users who do not see the system but just the topping. I would never try to blame the user about this. For my father it is even easier to understand what I'm doing in Debian because I spend most of my time with leaf packages (if I do not care for Blends infrastructure stuff). So telling him Debian is an app store and my work on it is adding apps to the store this is an very easy to understand explanation which leaves out the part that is not understandable to him: What is an operating system. (Hey, also Windows is no operating system - it is just a kick-starter for Windows, Excel, a browser and a mail client, right?) Debian is no app store: content is not only apps nor app-centric, and aim is not to archive nor to sell, but to streamline and distribute. If you do not like the selling part: Store in the sense of some storage of goods is not necessarily about bying (at least of my understanding). Or tweak it like this: We are selling our stuff but the price tag says 0€/$. Feel free to blame me about oversimplification When I need an alternative term to describe what distribution means, I use library: Like librarians we care not only about the individual books of software, and not only about the novels, but about long-term cohesive structure of the library as a whole. Libraries also has the connotation of collecting dust which arguably is descriptive for (stable) Debian as well ;-) Nice alternative explanation. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425124038.ga7...@an3as.eu
Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
On Thu, Apr 25, 2013 at 02:40:38PM +0200, Andreas Tille wrote: understandable to him: What is an operating system. (Hey, also Windows is no operating system - it is just a kick-starter for Windows, Excel, a browser and a mail client, right?) s/for Windows, Excel/for Word, Excel/ Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425125614.gb7...@an3as.eu
Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
On 04/25/2013 09:40 AM, Andreas Tille wrote: There are actually users who do not see the system but just the topping. Yes, but I don't think we should encourage any users in this skewed view of the system. I would never try to blame the user about this. Nor would I. However, I would not use this as an excuse not to educate them. For my father it is even easier to understand what I'm doing in Debian because I spend most of my time with leaf packages (if I do not care for Blends infrastructure stuff). So telling him Debian is an app store and my work on it is adding apps to the store this is an very easy to understand explanation which leaves out the part that is not understandable to him: What is an operating system. (Hey, also Windows is no operating system - it is just a kick-starter for Windows, Excel, a browser and a mail client, right?) I understand using app store as an analogy, as long as it is explained as such, and qualified as being an imperfect analogy. But the common conception of an app store as involving you solely as consumer and not as participant in the free software ecosystem encourages poor relationship between users and producers (or distributors) of free software. So long as users continue to see themselves as a tiny, insignificant recipient at the end of the production of the software with no input into the system, you've stripped them of the power to change the software to meet their needs. So using the app store analogy is walking the fine line and really needs to be qualified to avoid doing damage to the user's relationship to the community. If you do not like the selling part: Store in the sense of some storage of goods is not necessarily about bying (at least of my understanding). Or tweak it like this: We are selling our stuff but the price tag says 0€/$. Feel free to blame me about oversimplification Honestly, I don't think the selling part is the most offensive part of the concept of an app store. It's the one-way nature of the transactions carried out with them. Ben -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51792a53.7080...@sanctuary.nslug.ns.ca
