Re: [DNG] Devuan and upstream
Go Linux wrote: > I once investigated helping a friend use some open source software on her > Mac. A program that was free (gratis) in the Linux community was available in > the Apple app store for $30! That really pissed me off and soured me even > more on Apple than before (if that was possible). If ti was GPL then it would have been available free of charge if you looked in the right place. Contrary to some opinions, Apple do behave themselves in this respect. Did you try Fink or Macports ? http://www.finkproject.org https://www.macports.org I've come across other cases where "free" software has been available in a store for real money. In my case I have a couple of packages on my Android phone where I paid for them through the Google store although I could have got them free elsewhere - just for the convenience factor, plus it's a source of a small amount of income for the projects concerned. But this is off-topic for here. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Sat, 8/15/15, Simon Hobson wrote: Subject: Re: [DNG] Devuan and upstream To: "dng@lists.dyne.org" Date: Saturday, August 15, 2015, 3:53 PM Hendrik Boom wrote: >> THe way I heard the story, in the ncient days when Apple was choosing >> the kernel for OS X, they were originally planning to use Linux, but >> they changed their mind for copyright reasons. THey didn't want to risk >> any of their proprietary software becoming free software because of >> GPL contagion. >> >> The BSD licence allowed them to do what they wanted. >> > > You do realise that they do in fact use a lot of GPL software don't you ? In > fact they have contributed > some very useful software back into the > community under GPL. > I'm more inclined to think they just decided the BSD kernel was more suitable > to their needs > I once investigated helping a friend use some open source software on her Mac. A program that was free (gratis) in the Linux community was available in the Apple app store for $30! That really pissed me off and soured me even more on Apple than before (if that was possible). golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
The lack of the last two: multiple versions and shell scripts are why Debian derivatives cannot share packages, even though they use identical base code. Correction: The lack of multiple versions and packahe shell scripts are why Debian derivatives cannot share packages, even though they use identical base code. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Sat, 15 Aug 2015 20:19:03 + Stephanie Daugherty wrote: Hi, Stephanie! =) > They did, but out of all this design by committee, hidden between all > the political bullshit and bikeshedding, they also created the most > brilliant, most comprehensive set of standards for quality control, > package uniformity, license auditing, and of course. the most robust > dependency management, at least among binary distributions. Sorry, I can't agree. =( After using a number of distributions over about 20 years, I find Debian to be more or less average. Debian passes into stable roughly the same number of bugs that most of the other major distributions do. This is not to say that Debian does not make an effort. Far from it. I'm simply saying that when you take the top ten binary Linux distributions, they pretty much all have the same or similar issues. > > More importantly than that, they backed these standards up with > automated tools that are nearly as robust as the standards > themselves. I agree their tools are decent - most of the time, but the tools are really only useful for their particular use case. In my opinion, Debian packaging was the best - 15 years ago - but after that initial work was done, they stopped doing anything significant at all. I'm not saying Debian packaging is bad. I find it very good, but it also have serious limitations that should have been dealt with long ago. Their tools work 90% of the time when you confine yourself within the Debian stable repository. Debian packaging is extremely dependent on versioning in their build process. It is unable to use anything other than the last version. There are no rollbacks or test staging before final install, for example. There is no standard mechanism to allow for multiple libraries and precedence. Individual install scripts should have been replaced with a Debian standard for a simple tokenized installer so that there are no individualized shell scripts in the packages to begin with. The lack of the last two: multiple versions and shell scripts are why Debian derivatives cannot share packages, even though they use identical base code. It is also the source of the init scripts that caused at least 70% of the reason that Devuan split from Debian in the first place. What I am saying is that Debian could have raised the bar long ago, but frankly, no one cares. (It's one of the reasons I am fed up with binary Linux versions. If it was not for lack of time, I would not be using them at all.) > You don't see packages interfering with one another very > often in the Debian world, because this is caught right away by > scripts that check that every file installed by a package, or > automatically created by that package belongs to EXACTLY ONE package, > otherwise all the packages have to use some approved mechanism to > cooperate. You also see this effort it in difficult to configure > packages that set themselves up and work out of the box, and in the > modularized configuration that's common to many packages. Yes and no. I've seen plenty of packages break as soon as you use something that the majority does not. I've also seen more than few packages that require significant intervention to work properly. That has lessened the last few releases, but the spectre is always there. Take care! T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
Stephanie Daugherty wrote: > They did, but out of all this design by committee, hidden between all the > political bullshit and bikeshedding, they also created the most brilliant, > most comprehensive set of standards for quality control, package uniformity, > license auditing, and of course. the most robust dependency management, at > least among binary distributions. > > More importantly than that, they backed these standards up with automated > tools that are nearly as robust as the standards themselves. You don't see > packages interfering with one another very often in the Debian world, because > this is caught right away by scripts that check that every file installed by > a package, or automatically created by that package belongs to EXACTLY ONE > package, otherwise all the packages have to use some approved mechanism to > cooperate. You also see this effort it in difficult to configure packages > that set themselves up and work out of the box, and in the modularized > configuration that's common to many packages. > > Most importantly, this rigid attention to detail is why for more than a > decade now, in place upgrades have been fully supported, officially > recommended and for the most part, Just Work(tm(. It used to be said, back in > the day that the installer was still horrible, "thank god you only ever have > to see it once" That's how I see it too - I've been using Debian by choice for a lot of years - in fact, the only systems I run that aren't debian are where I've used a "packaged" setup, specifically I have a couple of PBX "appliances" which only support (at the time they were built) being setup on Centos. On 15 Aug 2015, at 21:33, Laurent Bercot wrote: > And their package management features: > > - no way to have several versions of the same package installed on > your machine > - no atomic upgrades for single binary packages: if you have stuff > running during an upgrade, things can break. > - no possibility to rollback. The rollback is a bit of a pain. In spite of the quality control, I have had one or two issues in the past where an upgrade has broken a combination of stuff - as in X runs on language Y and uses Z for some of it's functions, but after an upgrade it "doesn't work" and then have to start manually installing older versions of X, Y, and Z to figure out which combination work. > I'm sure there's a lot of good to say about the way Debian does > things, but quality of their package management isn't a part of it. > When you're running production servers and need reliability when > upgrading software, you just can't use Debian. I've found it pretty reliable - certainly not as bad as certain commercial ecosystems I have dealings with. My expectations of "problems" during upgrades is less with my Debian systems than it is with anything else. That's not to say I've not had problems. Hendrik Boom wrote: > THe way I heard the story, in the ncient days when Apple was choosing > the kernel for OS X, they were originally planning to use Linux, but > they changed their mind for copyright reasons. THey didn't want to risk > any of their proprietary software becoming free software because of > GPL contagion. > > The BSD licence allowed them to do what they wanted. You do realise that they do in fact use a lot of GPL software don't you ? In fact they have contributed some very useful software back into the community under GPL. I'm more inclined to think they just decided the BSD kernel was more suitable to their needs. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On 15/08/2015 22:19, Stephanie Daugherty wrote: They did, but out of all this design by committee, hidden between all the political bullshit and bikeshedding, they also created the most brilliant, most comprehensive set of standards for quality control, package uniformity, license auditing, and of course. the most robust dependency management, at least among binary distributions. And their package management features: - no way to have several versions of the same package installed on your machine - no atomic upgrades for single binary packages: if you have stuff running during an upgrade, things can break. - no possibility to rollback. I'm sure there's a lot of good to say about the way Debian does things, but quality of their package management isn't a part of it. When you're running production servers and need reliability when upgrading software, you just can't use Debian. And that is sad. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Sat, Aug 15, 2015 at 02:20:44PM -0500, T.J. Duchene wrote: > > Having a specifically defined base makes it easier for third parties to > ensure that software is going to work without a hitch. It's much more > attractive from a testing standpoint than the usual Linux hodge-podge. I > think it is also one of the reasons that Google looks at Gentoo for > Chrome OS and Apple to FreeBSD. It just simplifies everything: > testing, development and bug hunting. THe way I heard the story, in the ncient days when Apple was choosing the kernel for OS X, they were originally planning to use Linux, but they changed their mind for copyright reasons. THey didn't want to risk any of their proprietary software becoming free software because of GPL contagion. The BSD licence allowed them to do what they wanted. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Fri, Aug 14, 2015 at 8:20 PM James Powell wrote: > Slackware is maintained by 3 core people with extra help as needed. The > rest of the packages are pushed by the community at large contributing. > Devuan doesn't have to maintain every package possible. That's ludicrous to > think so. > > Debian got in over its head by allowing this. Thousands upon thousands of > packages that required a committee to oversee. > > They did, but out of all this design by committee, hidden between all the political bullshit and bikeshedding, they also created the most brilliant, most comprehensive set of standards for quality control, package uniformity, license auditing, and of course. the most robust dependency management, at least among binary distributions. More importantly than that, they backed these standards up with automated tools that are nearly as robust as the standards themselves. You don't see packages interfering with one another very often in the Debian world, because this is caught right away by scripts that check that every file installed by a package, or automatically created by that package belongs to EXACTLY ONE package, otherwise all the packages have to use some approved mechanism to cooperate. You also see this effort it in difficult to configure packages that set themselves up and work out of the box, and in the modularized configuration that's common to many packages. Most importantly, this rigid attention to detail is why for more than a decade now, in place upgrades have been fully supported, officially recommended and for the most part, Just Work(tm(. It used to be said, back in the day that the installer was still horrible, "thank god you only ever have to see it once" With that said, Debian could have accomplished far more had it not been a case of Design by committee, or if they had a competent BDFL with a firm grasp on the overall vision stepping in from time to time when all that process got out of hand, but I'm not sure if they'd have been ambitious enough to create some of the architectural masterpieces they have with different leadership. Honestly, what is needed by a distribution? Look at Slackware or BLFS > that's a lot of packages, but it's manageable by a small team. Why can't > Devuan follow suit? There doesn't need to be a bagillion packages > maintained by the main devs. If the rest need to be passed back to the > community at large, then do it. This also hits the point of why do we need > 5 different for things like, for example, SDL packages for -bin, -lib, > -doc, -dev, -src, and such? One package is easier to maintain than five > individual ones. It lightens the load significantly, especially for the > poor soul having to make 5 or more different scripts for 5 packages from > the same source tarball. Yes, it's nice to have small packages for embedded > stuff and small disks, but do you really want to raise the workload of the > maintainer that much? > > The various -bin -lib etc packages raise the workload very little, if at all - once it's properly set up, that part's effectively automated. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Sat, 15 Aug 2015 10:02:12 + Roger Leigh wrote: > That's a considerable achievement--how many other projects have been > able to achieve an equivalent scale? Not very many and I agree with you, it is very impressive, even if Debian makes internal bickering look commonplace. I'd say it is even more impressive, that in spite of that, they still manage it. > > Now I think there may have been benefits to separating the "base" > system from "everything else", and indeed it was discussed on several > occasions in Debian, but this never happened for various reasons. In > retrospect, I think it would have been a good move. I agree. I would rather that Devuan had a smaller fixed base install that was supported for at least 5 years (or two releases) with a guaranteed ABI for the life of that base. You can say that upstream Debian already does this to some extent, and yes that is true, but there really is no divider between base and the rest of the repo. It might seem rather arbitrary at all, but giving someone a clear notion of what is going on is key in IT. Even if two products are exactly the same, the one that is presented with less hassle wins the day. Having a specifically defined base makes it easier for third parties to ensure that software is going to work without a hitch. It's much more attractive from a testing standpoint than the usual Linux hodge-podge. I think it is also one of the reasons that Google looks at Gentoo for Chrome OS and Apple to FreeBSD. It just simplifies everything: testing, development and bug hunting. Heck, I'd make a reasonable guess that if Devuan had a fixed base that Valve might even chose Devuan over Debian for future versions of SteamOS, because it would be less work for them to do. They wouldn't have to dissect as much to get the base that they need. > That said, I do think multi-binary package generation could be > automated for the common cases. It's pretty trivial to distinguish > headers, libraries, documentation, translations, source, debug > symbols from the filesystem locations they live in. This is also > something which has been discussed over the years. The tool changes > to accommodate it are not insignificant though. Gentoo proved that you can set a series of global package "flags" specifying what support to include or exclude when building a binary package. It's practical and it works for large scale package chains. It's completely automated. I see no reason why Debian or Devuan cannot incorporate the idea to build sets of the same packages with and without systemd support and then let the user choose what they want. It's just my opinion, and no one has to agree, but if Devuan ever wants to be a major distribution, systemd has to become a non-issue. It should just another piece of software, installed at user's whim. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Sat, 15 Aug 2015 10:13:56 + Roger Leigh wrote: er revision for 2017, and I think they are nuts. > > I don't. I write C++ code for my day job, and I'd have to say that > these revisions make C++ better than ever to write. It's cleaner, > simpler, and more maintainable. Just last week I wrote some > prototype code in C++11, and later had to change it to use C++98 > features to comply with the project's requirements. It doubled the > line count and made it vastly less readable, and this was using only > two features: auto types and range-base for loops. The benefits it > provides are not insignificant. I don't argue against the apparent benefits. Quite the reverse, actually. The people who work on the ISO standards are far from stupid people and probably know more than I ever will on the subject. I admit I am concerned from time to time that things are not as thought out as they might be. Rapid releases curtail discussion, and one thing I do not want to see is C++ ending up like de-facto languages, where you can't depend on anything to any extent. > When you say they are "nuts", are there any changes in C++14 or C++17 > which you have found to be ill-considered? Not at presently, but to be perfectly honest, my exposure to C++11 has been limited so far. Thanks to you, I've been spending more time with it. My concern is actually over implementation. Historically, phasing in support for standards tends to be done slowly, often piecemeal, and there are always bugs. By rapidly releasing changes to the standards, I am concerned that more regressions will creep into the compiler software in the mad scramble to keep up with demand. Microsoft's Visual Studio is famous for being a pain in the backside. I would hate to see GCC get worse, because they already have a less than sterling reputation for bug resolution. I've not used Clang extensively, so I can't speak to it. > While no standard is ever "perfect", I have no complaints about > C++11 or C++14. Since these are ISO standards, the realities of the > process means there's little scope for pushing in lots of poorly > thought out changes at the last minute--most of the changes have been > planned and implemented for many years. I would agree with you, and rest easy in that the ISO is keeping things under control except that they seem to be make use of "fast track" on a number of things these days. Thankfully, most of the fast track ballots seem to be for Microsoft crap. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On 15/08/2015 05:57, T.J. Duchene wrote: On Fri, 14 Aug 2015 22:38:35 -0700 Isaac Dunham wrote: To elaborate on this, GCC 5.1 (I think) has changed the ABI for C++11 support. Packages using C++11 need to be rebuilt with the new library; libreoffice has already been rebuilt, but not KDE. That's a very good point, Isaac. C++11 is a very interesting revision, although C++14 is technically the highest available standard. I'm never a fan of rapidly changing standards, because they tend to be a mess, poorly considered. I understand they plan another revision for 2017, and I think they are nuts. I don't. I write C++ code for my day job, and I'd have to say that these revisions make C++ better than ever to write. It's cleaner, simpler, and more maintainable. Just last week I wrote some prototype code in C++11, and later had to change it to use C++98 features to comply with the project's requirements. It doubled the line count and made it vastly less readable, and this was using only two features: auto types and range-base for loops. The benefits it provides are not insignificant. When you say they are "nuts", are there any changes in C++14 or C++17 which you have found to be ill-considered? While no standard is ever "perfect", I have no complaints about C++11 or C++14. Since these are ISO standards, the realities of the process means there's little scope for pushing in lots of poorly thought out changes at the last minute--most of the changes have been planned and implemented for many years. There's only one feature I can think of which was bad--template export--and this was in C++98; and I think they learned their lesson from that one--never put in a standard a features which hasn't been implemented and tested in the real world. Regards, Roger ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On 15/08/2015 05:38, Isaac Dunham wrote: On Fri, Aug 14, 2015 at 02:42:14PM +0200, Adam Borowski wrote: On Fri, Aug 14, 2015 at 02:02:22PM +0200, Didier Kryn wrote: Seems to me there's something weird, both, in libreoffice depending on just one single version of libstdc++, and in libklabxml being broken by this version of libstdc++, be it the fault of kde or libstdc++ developpers. That's the GCC-5 transition, unstable is broken as it's supposed to. You can use testing if you're bothered by uninstallable packages (or any other form of the sky falling). To elaborate on this, GCC 5.1 (I think) has changed the ABI for C++11 support. Packages using C++11 need to be rebuilt with the new library; libreoffice has already been rebuilt, but not KDE. Technically, there's no ABI break. Since GCC5, libstdc++ uses symbol versioning to provide the old and new std::string etc. So existing C++ code will continue running without any changes. The need to rebuild is to avoid incompatibilites due to transitive dependencies between libraries using the old and new ABIs, which means that in practice all C++ libraries need rebuilding using the new ABI. Regards, Roger ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On 15/08/2015 00:19, James Powell wrote: Slackware is maintained by 3 core people with extra help as needed. The rest of the packages are pushed by the community at large contributing. Devuan doesn't have to maintain every package possible. That's ludicrous to think so. Debian got in over its head by allowing this. Thousands upon thousands of packages that required a committee to oversee. While this might be true to an extent, you can also view it this way: the organisation and structure of Debian, the project, allowed it to scale to 1000 developers who could maintain 2 packages without stepping on each others toes too often. That's a considerable achievement--how many other projects have been able to achieve an equivalent scale? Now I think there may have been benefits to separating the "base" system from "everything else", and indeed it was discussed on several occasions in Debian, but this never happened for various reasons. In retrospect, I think it would have been a good move. Honestly, what is needed by a distribution? Look at Slackware or BLFS that's a lot of packages, but it's manageable by a small team. Why can't Devuan follow suit? There doesn't need to be a bagillion packages maintained by the main devs. If the rest need to be passed back to the community at large, then do it. This also hits the point of why do we need 5 different for things like, for example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? One package is easier to maintain than five individual ones. It lightens the load significantly, especially for the poor soul having to make 5 or more different scripts for 5 packages from the same source tarball. Yes, it's nice to have small packages for embedded stuff and small disks, but do you really want to raise the workload of the maintainer that much? I think this is barking up the wrong tree. Maintaining multi-binary source packages isn't the huge burden you're making out. There's just one script to build all the binary packages, so the overhead on that side is unchanged. The separate packages are generally just lists of files/directories to be copied into each package, and this is fairly easy to maintain. Having everything in a single package is inflexible and wastes disc space. Undoing all the effort that went into this in the first place would be a significant regression. That said, I do think multi-binary package generation could be automated for the common cases. It's pretty trivial to distinguish headers, libraries, documentation, translations, source, debug symbols from the filesystem locations they live in. This is also something which has been discussed over the years. The tool changes to accommodate it are not insignificant though. Regards, Roger ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Fri, 14 Aug 2015 22:38:35 -0700 Isaac Dunham wrote: > > To elaborate on this, GCC 5.1 (I think) has changed the ABI for C++11 > support. > Packages using C++11 need to be rebuilt with the new library; > libreoffice has already been rebuilt, but not KDE. That's a very good point, Isaac. C++11 is a very interesting revision, although C++14 is technically the highest available standard. I'm never a fan of rapidly changing standards, because they tend to be a mess, poorly considered. I understand they plan another revision for 2017, and I think they are nuts. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Fri, Aug 14, 2015 at 02:42:14PM +0200, Adam Borowski wrote: > On Fri, Aug 14, 2015 at 02:02:22PM +0200, Didier Kryn wrote: > > Seems to me there's something weird, both, in libreoffice depending on > > just one single version of libstdc++, and in libklabxml being broken by this > > version of libstdc++, be it the fault of kde or libstdc++ developpers. > > That's the GCC-5 transition, unstable is broken as it's supposed to. You > can use testing if you're bothered by uninstallable packages (or any other > form of the sky falling). To elaborate on this, GCC 5.1 (I think) has changed the ABI for C++11 support. Packages using C++11 need to be rebuilt with the new library; libreoffice has already been rebuilt, but not KDE. HTH, Isaac ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
I respectfully disagree. A single package would require a new build script, but equally it will pay for itself in the long run by reducing the overall workload to maintain each package. The short term, yes its work. It will be. But why not have one single SDL2-2.0.0-x86_64-1.deb package that is sustainable in the long term? I don't want to debate long term versus short term, but at the current rate, Devuan will be sustainable, but for how long with such a small team? From: Hendrik Boom<mailto:hend...@topoi.pooq.com> Sent: 8/14/2015 5:33 PM To: dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: Re: [DNG] Devuan and upstream On Fri, Aug 14, 2015 at 05:19:25PM -0700, James Powell wrote: > Slackware is maintained by 3 core people with extra help as needed. The rest > of the packages are pushed by the community at large contributing. Devuan > doesn't have to maintain every package possible. That's ludicrous to think so. > > Debian got in over its head by allowing this. Thousands upon thousands of > packages that required a committee to oversee. > > Honestly, what is needed by a distribution? Look at Slackware or BLFS that's > a lot of packages, but it's manageable by a small team. Why can't Devuan > follow suit? There doesn't need to be a bagillion packages maintained by the > main devs. If the rest need to be passed back to the community at large, then > do it. This also hits the point of why do we need 5 different for things > like, for example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? > One package is easier to maintain than five individual ones. It lightens the > load significantly, especially for the poor soul having to make 5 or more > different scripts for 5 packages from the same source tarball. Yes, it's nice > to have small packages for embedded stuff and small disks, but do you really > want to raise the workload of the maintainer that much? It would also be folly to increase the maintainers load by naing him reunite those multiple binary packages that are prooduced from one source package. We don't have the manpower for that economy! -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Fri, Aug 14, 2015 at 05:19:25PM -0700, James Powell wrote: > Slackware is maintained by 3 core people with extra help as needed. The rest > of the packages are pushed by the community at large contributing. Devuan > doesn't have to maintain every package possible. That's ludicrous to think so. > > Debian got in over its head by allowing this. Thousands upon thousands of > packages that required a committee to oversee. > > Honestly, what is needed by a distribution? Look at Slackware or BLFS that's > a lot of packages, but it's manageable by a small team. Why can't Devuan > follow suit? There doesn't need to be a bagillion packages maintained by the > main devs. If the rest need to be passed back to the community at large, then > do it. This also hits the point of why do we need 5 different for things > like, for example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? > One package is easier to maintain than five individual ones. It lightens the > load significantly, especially for the poor soul having to make 5 or more > different scripts for 5 packages from the same source tarball. Yes, it's nice > to have small packages for embedded stuff and small disks, but do you really > want to raise the workload of the maintainer that much? It would also be folly to increase the maintainers load by naing him reunite those multiple binary packages that are prooduced from one source package. We don't have the manpower for that economy! -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
Slackware is maintained by 3 core people with extra help as needed. The rest of the packages are pushed by the community at large contributing. Devuan doesn't have to maintain every package possible. That's ludicrous to think so. Debian got in over its head by allowing this. Thousands upon thousands of packages that required a committee to oversee. Honestly, what is needed by a distribution? Look at Slackware or BLFS that's a lot of packages, but it's manageable by a small team. Why can't Devuan follow suit? There doesn't need to be a bagillion packages maintained by the main devs. If the rest need to be passed back to the community at large, then do it. This also hits the point of why do we need 5 different for things like, for example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? One package is easier to maintain than five individual ones. It lightens the load significantly, especially for the poor soul having to make 5 or more different scripts for 5 packages from the same source tarball. Yes, it's nice to have small packages for embedded stuff and small disks, but do you really want to raise the workload of the maintainer that much? -Jim From: Stephanie Daugherty<mailto:sdaughe...@gmail.com> Sent: 8/14/2015 6:21 AM To: T.J. Duchene<mailto:t.j.duch...@gmail.com>; dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: Re: [DNG] Devuan and upstream On Thu, Aug 13, 2015 at 4:06 PM T.J. Duchene wrote: > > 1. You can't mark a package as "Do not install." APT simply does not give > you the option. > > Heaven knows, there are a lot of people who dislike things like network- > manager, and do not them to install for any reason. > > Someone might say - wait you can put a hold on packages. That's true, but > that does not stop packages from being installed. It only says which > version > is preferred. There is no option for "none". > > You can block packages with APT pinning, but using pinning is very > esoteric. > > There's a less obvious, but more reliable solution that holding or pinning., and that is the dummy package. equivs makes this pretty easy to create - you simply need a package marked that conflicts with the undesired software, or if you prefer, one which tells the system that package is already installed, so that you can ignore the dependency at your own risk and without any pestering from apt. . > 2. Whenever an update has bug, you cannot rollback to the previous version > of > the package. It is always assumed that the latest version is correct. In > the > real world, we know that is not always true. > Sure you can, just not with apt. dpkg is still the actual package manager, and will happily install older versions for you, so long as you take care of the dependencies on your own. In many cases the previous packages are still sitting around in apt's download directory, but if not, they can usually still be found in the archives. Besides, unless you follow unstable, this doesn't happen often enough to be a serious concern, because of Debian's rigid "no functionality changes in stable, only fixes" policy. The situation in both of these cases should be better, but arguably, if it's a direction Devuan decides to go in, it would be best to do so as extensions to apt rather than reinventing the wheel, so as to keep as much compatibility with Debian as possible and continue to use Debian as upstream whenever possible. Without Debian as an upstream, the task of maintaining Devuan even at parity with Debian would be all but impossible for the small team of maintainers and developers currently part of Devuan. Unless a very large portion of the Debian community jumps ship, and Devuan becomes the base of Debian rather than the other way around, I think this will have to continue for the foreseeable future. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Thu, Aug 13, 2015 at 4:06 PM T.J. Duchene wrote: > > 1. You can't mark a package as "Do not install." APT simply does not give > you the option. > > Heaven knows, there are a lot of people who dislike things like network- > manager, and do not them to install for any reason. > > Someone might say - wait you can put a hold on packages. That's true, but > that does not stop packages from being installed. It only says which > version > is preferred. There is no option for "none". > > You can block packages with APT pinning, but using pinning is very > esoteric. > > There's a less obvious, but more reliable solution that holding or pinning., and that is the dummy package. equivs makes this pretty easy to create - you simply need a package marked that conflicts with the undesired software, or if you prefer, one which tells the system that package is already installed, so that you can ignore the dependency at your own risk and without any pestering from apt. . > 2. Whenever an update has bug, you cannot rollback to the previous version > of > the package. It is always assumed that the latest version is correct. In > the > real world, we know that is not always true. > Sure you can, just not with apt. dpkg is still the actual package manager, and will happily install older versions for you, so long as you take care of the dependencies on your own. In many cases the previous packages are still sitting around in apt's download directory, but if not, they can usually still be found in the archives. Besides, unless you follow unstable, this doesn't happen often enough to be a serious concern, because of Debian's rigid "no functionality changes in stable, only fixes" policy. The situation in both of these cases should be better, but arguably, if it's a direction Devuan decides to go in, it would be best to do so as extensions to apt rather than reinventing the wheel, so as to keep as much compatibility with Debian as possible and continue to use Debian as upstream whenever possible. Without Debian as an upstream, the task of maintaining Devuan even at parity with Debian would be all but impossible for the small team of maintainers and developers currently part of Devuan. Unless a very large portion of the Debian community jumps ship, and Devuan becomes the base of Debian rather than the other way around, I think this will have to continue for the foreseeable future. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
On Fri, Aug 14, 2015 at 02:02:22PM +0200, Didier Kryn wrote: > Seems to me there's something weird, both, in libreoffice depending on > just one single version of libstdc++, and in libklabxml being broken by this > version of libstdc++, be it the fault of kde or libstdc++ developpers. That's the GCC-5 transition, unstable is broken as it's supposed to. You can use testing if you're bothered by uninstallable packages (or any other form of the sky falling). > The dependency chains might be shortened by linking at least part of the > libraries statically. All this dependency buysiness mostly comes from the > abuse of dynamic linking. The only real advantage of dynamic linking is > faster upgrade in a distribution, but it often turns out to make it just > impossible. Static linking has no place in a distribution. Among numerous other downsides, any update of a dependency requires a "rebuild world". There's no way to make a security or bugfix update without such a mass recompile. -- ⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀ ⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀ (https://github.com/kilobyte/braillefont for this hack) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
Le 14/08/2015 10:16, Noel Torres a écrit : Everyone that has anytime been trapped in the Dependency Hell knows about the complicated chains of dependencies in Debian. As a simple example, today it is impossible to install LibreOffice 5 and KDE together, since libreoffice 1:5.0.1~rc1-2 ends depending on libstdc++6 5.2.1-15 while kde-full 5:81 end depending on libkolabxml1 1.1.0-3 (the highest version available), but libstdc++6 Breaks libkolabxml1 <= 1.1.0-3 Seems to me there's something weird, both, in libreoffice depending on just one single version of libstdc++, and in libklabxml being broken by this version of libstdc++, be it the fault of kde or libstdc++ developpers. The dependency chains might be shortened by linking at least part of the libraries statically. All this dependency buysiness mostly comes from the abuse of dynamic linking. The only real advantage of dynamic linking is faster upgrade in a distribution, but it often turns out to make it just impossible. As a simple rule, I don't understand why Debian accepts a package which depends on just one version of libstdc++, therefore de facto preventing any upgrade. To be accepted, this package should be linked against a static version of libstdc++6, hence dropping the dependency. But, Ok, it's Debian's buziness for now. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
James Powell escribió: [...] Devuan should follow the Debian methodology, but equally it should forge it's own path away from Debian. It doesn't need to draw from any other distribution like Funtoo, CRUX, Slackware, or anything other distributions, other than seeing what people are using and in need of. The wants will be many, but what users need will matter most of all. [...] I have thought extensively (in some sort of silence, I suppose, since you have not heard of^H read from me for a long time) in this issue of packages and dependencies, and I have come across an idea, that of boxes. Everyone that has anytime been trapped in the Dependency Hell knows about the complicated chains of dependencies in Debian. As a simple example, today it is impossible to install LibreOffice 5 and KDE together, since libreoffice 1:5.0.1~rc1-2 ends depending on libstdc++6 5.2.1-15 while kde-full 5:81 end depending on libkolabxml1 1.1.0-3 (the highest version available), but libstdc++6 Breaks libkolabxml1 <= 1.1.0-3 These chains of dependencies can be shortened if we use "boxes" of packages. They are not metapackages, but a new idea, albeit somewhat similar. Why is LibreOffice worth a dozen packages? If I want LibreOffice, I want it all (Thanks, Queen). So I install the LibreOffice box. The box on its own will install the needed packages and care for the internal dependencies, and provide a shiny dependencies inteface to the other boxes. And of course, boxes can be inside boxes. This way, boxes are managed as simple units, migrate from ceres to testing as complete units, etc. They also allow for efficient teamworking. e.g. The LAMP box contains (and iterfaces with) the Apache box and the MySQL box. The LAMP box controls the migration of all of Apache, PHP and MySQL packages, to ensure they all work properly and are coinstallable. Just two (or maybe three) euro cents. regards Noel er Envite binnlCoFEfKn8.bin Description: Clave PGP pública pgpXdOlK6cgzH.pgp Description: Firma digital PGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
As someone who's background is in Slackware, I know where automatic package dependency resolution has its good points and bad points. Pkgtools is very basic. Everything is left to the system administrator to resolve, but SlackBuilds.org offered a solution. It allows packages to have certain triggers like WITH_JPEG=yes ./.SlackBuild, but sbotools took it farther by scripting everything to work off the README, .info files, and the build scripts to resolve things at a controllable level without things getting complicated. Very akin to CRUX's and BSD's ports. Devuan should follow the Debian methodology, but equally it should forge it's own path away from Debian. It doesn't need to draw from any other distribution like Funtoo, CRUX, Slackware, or anything other distributions, other than seeing what people are using and in need of. The wants will be many, but what users need will matter most of all. Devuan should be Devuan. That's all I can say on that for now. -Jim From: T.J. Duchene<mailto:t.j.duch...@gmail.com> Sent: 8/13/2015 1:06 PM To: dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: [DNG] Devuan and upstream Everyone of course is welcome to comment but the question is really for the Devuan team.Is the general plan is just to copy Debian, or are there plans to make more changes than just systemd? Debian APT is an example. It's a good manager, but it falls short in some key areas that are not unreasonable to ask from a package manager. 1. You can't mark a package as "Do not install." APT simply does not give you the option. Heaven knows, there are a lot of people who dislike things like network- manager, and do not them to install for any reason. Someone might say - wait you can put a hold on packages. That's true, but that does not stop packages from being installed. It only says which version is preferred. There is no option for "none". You can block packages with APT pinning, but using pinning is very esoteric. 2. Whenever an update has bug, you cannot rollback to the previous version of the package. It is always assumed that the latest version is correct. In the real world, we know that is not always true. The reason I am asking is that Debian clearly has no plans to fix any of these problems. They've been around for a decade or more. I wonder if Devuan does have any plans to correct Debian's shortcomings, regardless of what upstream does? For myself, before I'd consider spending the effort to look at ways of fixing some things, I'd want to know that those efforts would be received or if they would go against the overall plan of absolutely remaining compatible with Devian upstream. For example, mentioning the problems above - if Devuan intends to eventually break away from Debian, then redesigning the packaging process would be the way to go, because you could handle rollbacks and other concerns. If Devuan plans to remain as close to Debian as possible, then perhaps a GUI attached to synaptic to simplify pinning for the average user might be in order instead. I'd just like to get some idea of what contributions to Devuan might be made in the future. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan and upstream
Everyone of course is welcome to comment but the question is really for the Devuan team.Is the general plan is just to copy Debian, or are there plans to make more changes than just systemd? Debian APT is an example. It's a good manager, but it falls short in some key areas that are not unreasonable to ask from a package manager. 1. You can't mark a package as "Do not install." APT simply does not give you the option. Heaven knows, there are a lot of people who dislike things like network- manager, and do not them to install for any reason. Someone might say - wait you can put a hold on packages. That's true, but that does not stop packages from being installed. It only says which version is preferred. There is no option for "none". You can block packages with APT pinning, but using pinning is very esoteric. 2. Whenever an update has bug, you cannot rollback to the previous version of the package. It is always assumed that the latest version is correct. In the real world, we know that is not always true. The reason I am asking is that Debian clearly has no plans to fix any of these problems. They've been around for a decade or more. I wonder if Devuan does have any plans to correct Debian's shortcomings, regardless of what upstream does? For myself, before I'd consider spending the effort to look at ways of fixing some things, I'd want to know that those efforts would be received or if they would go against the overall plan of absolutely remaining compatible with Devian upstream. For example, mentioning the problems above - if Devuan intends to eventually break away from Debian, then redesigning the packaging process would be the way to go, because you could handle rollbacks and other concerns. If Devuan plans to remain as close to Debian as possible, then perhaps a GUI attached to synaptic to simplify pinning for the average user might be in order instead. I'd just like to get some idea of what contributions to Devuan might be made in the future. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
