Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On Fri, 10 Aug 2012 05:04:40 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted: > > > On Thu, 09 Aug 2012 22:30:02 +0200 Luca Barbato > > wrote: > > > >> On 08/09/2012 09:43 PM, Michał Górny wrote: > >>> On Thu, 09 Aug 2012 10:42:15 +0200 Luca Barbato > >>> wrote: > > [W]e could discuss about why reinventing shellscript may > not be that sound and other less glaring, horrid and > appalling design choices. > >>> > >>> Yes, exactly. So why does openrc reinvent that horrible > >>> shellscript? > >> > >> It is not re-invented, in fact we can use any compatible shell. > > > > Or anything else what can be spawned for shell. And a lot more what > > you won't expect. And guess what, people are actually doing crazy > > things with it because someone forgot to tell them how a init.d > > script should work. > > Sounds interesting. A couple quick links to examples of what you had > in mind would be nice. =:^) > > (Or a bit more description, enough to both get the concept and google > with would be good, but links could be quicker if you have them > handy, and are less likely to spawn even further afield subthreads.) vdr is a first example which comes to my mind. They workaround program configuration limitations and the init.d scripts become a complex extra-configuration parser + plugin loader. Well, another thing here is that upstream AFAIK is not willing to cooperate to fix their config parsing. 'oldnet' is an another example. I'm not saying it should go; I'm saying it should be a stand-alone executable called from the init.d script. Last time I looked, squid init.d was performing post-inst in start(). Many users may find that beneficial but that's not what init.d scripts should be doing. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
On Tue, 10 Jul 2012 14:24:27 -0500 William Hubbs wrote: > On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote: > > Hello, all. > > > > Since nowadays udev is bundled within systemd, we start having two > > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making > > the long story short, I would like to introduce a virtual for > > libudev which would pull in either of those two. > > > > There are three USE flags used in conditionals when depending on > > udev: > > - gudev - for glib wrapper on udev, > > - hwdb - to pull in hwids, > > - static-libs. > > > > The former two were previously provided by 'extras' USE flag, > > and the third was unconditional. > > > > I'm attaching an example virtual/libudev which does the job. Sadly, > > because of the 'extras' compatibility it's a big ugly conditional. > > I'm going to ask here, because of the discussion on IRC, that you not > commit this yet. There are issues still we need to work out wrt > packaging systemd and udev. So, can I commit the virtual and finally start fixing people's systems or are we going to discuss this to the day when other options are no longer a possibility and virtual will be necessary? You seem still not to understand that upstream *does not care*. And either way, merging udev and systemd will result that two, four or six months from now users will need to manually re-adjust their @world to have the packages split again. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On 08/10/2012 09:43 AM, Michał Górny wrote: > vdr is a first example which comes to my mind. They workaround program > configuration limitations and the init.d scripts become a complex > extra-configuration parser + plugin loader. Well, another thing here is > that upstream AFAIK is not willing to cooperate to fix their config > parsing. > > 'oldnet' is an another example. I'm not saying it should go; I'm saying > it should be a stand-alone executable called from the init.d script. > > Last time I looked, squid init.d was performing post-inst in start(). > Many users may find that beneficial but that's not what init.d scripts > should be doing. This discussion is really derailing. Currently most people using certain features from openrc feel quite defensive and mildly uneasy with the current situation since systemd is pretty much swallowing components we used to rely on and force radical changes w/out providing explanations to people that do not care and that are perfectly happy with what they have. Now Canek seems to feel like that I'm willing to kill systemd and make it impossible to use it in Gentoo. That's not the case, I consider systemd a bad idea since it is only geared to solve some specific issues and does that in a way that I consider dangerous for the global usage patterns I'm aware of. systemd ideas are interesting and for a dumb linux desktop the implementation would be ok. systemd doesn't work in many scenarios and when it gets pointed apparently there is a disagreement on that because "systemd is perfect" like it happens with it gets pointed that pulseaudio has shortcomings (that come from its design) or avahi doesn't seem that stable. I can live with a seldom broken audio subsystem and I can cope with the fact pidgin-bonjour could randomly crash, I'm not happy to be forced to move to something with the same attitude as my init system. The whole point of the debate should be if easier to have systemd split itself in usable components so people with certain focuses could leverage it on linux and replace those on non-linux (apparently not a chance) or have what we currently have and works decently and hopefully be compatible (so have a compatible interface for user-daemons, a compatible dbus interface for the desktop integrations and so on), not which project we should help to kill the others. lu
[gentoo-dev] [RFC] euscan: Need to add more upstream info in metadata.xml
Hi everybody! euscan is available in portage as a dev package (app-portage/euscan-). This tool allows to check if a given package/ebuild has new upstream versions or not. It uses different heuristics to scan upstream and grab new versions and related urls. euscan can use either custom "handlers" for well known upstream (github, pypi, cpan, sourceforge, google-code, etc..) or use directory scanning using SRC_URI. If directory scan fails for some reason, euscan will fallback to brute force (generating possible next version number and trying to fetch those packages). The problem that we're facing with euscan is that some packages in upstream use strange version numbers or the list of available versions is placed in a location that is totally different from SRC_URI. Examples: - MySQL: most MySQL mirrors are not browsable (always fallback to brute force) - webalizer uses strange version numbers in upstream (ftp://ftp.mrunix.net/pub/webalizer/), in this case euscan should be aware that 2.21-02 is the version number in upstream and scan the ftp directory searching for webalizer-(\d+).(\d+)-(\d+).tar.gz. The last version of webalizer, 2.23.05, is not recognized by euscan and is not available in gentoo. - Authen-SASL-Cyrus in upstream uses “-server” in version numbers http://www.cpan.org/authors/id/P/PB/PBOETTCH/ - XML-Tidy that uses stranges letters in version number We thought about how to solve this issue and we agreed that the best way to handle the problem for every specific case was adding some more information in metadata.xml. In Debian, uscan uses information from debian/watch inside debian packages, hence as so much work is already done we thought about taking this info from watch files and save it in metadata.xml to make euscan use it. I wrote a simple script that patches metadata.xml adding an experimental tag with data from debian packages: https://github.com/volpino/euscan/blob/master/bin/euscan_patch_metadata A basic watch data contains a base url to scan and a pattern to search into it: Example: base: http://icedtea.classpath.org/download/source/ pattern: icedtea-([\d\.]+).tar.gz Which means "open that url and search for the links that match that pattern". This is useful for example when is not possible to retrieve the base url from SRC_URI (icedtea’s SRC_URI is http://icedtea.classpath.org/hg/release/icedtea7-forest-2.2/hotspot/archive/889dffcf4a54.tar.gz) Advanced usage with directory pattern: Example: base: http://ftp.gwdg.de/pub/misc/mysql/Downloads/MySQL-([\d\.]+) pattern: mysql-([\d\.]+).tar.gz Scans all directories that match the query looking for links that match the pattern We need also some options for mangling versions and download url: these options can contain regexps or names of mangling rules (e.g.: "cpan" means apply mangling rules for CPAN versions) Version mangling example: As mentioned above webalizer uses both dots and hyphens in version numbers, so an option like this is required versionmangle=”s/-/./” Download url mangling example: Page scan on berlios returns an url like this: http://prdownload.berlios.de/mirageiv/mirage-0.9.tar.gz that should be mangled to get a working download url with an option like downloadurlmangle=”s/prdownload/download/” (for more info see uscan manpage) Another example: dev-perl/Math-BaseCnv or XML-Tidy in upstream use strange version numbers like 1.8.B59BrZ that should be mangled to 1.8 Summarizing we need: - A base url and a file pattern to search for new upstream versions when SRC_URI is not suitable - some options for mangling retrieved data from the scan of upstream using base url and pattern or using remote-id information So our problem is: how can we store this data in a very flexible and efficient way? Proposed solutions: 1) Add an euscan tag with a custom namespace Example: http://euscan.iksaif.net";> ab Which means: apply regex s/a/b/ then apply cpan mangling rules and then gentoo mangling rules. 2) Change quite heavily the remote-id tag: - adding versionmanging and downloadmangling options that contain regexes - adding a new remote-id type called for example url, that tag will contain the base url and the pattern 3) Add a watch tag to with versionmangling and downloadmangling options. This tag can have a type (and in that case the data from remote-id is used) or can contain the base url and the file pattern. (this is what is currently implemented for our tests). So before going further, we would like some feedback from you on these approaches. What do you think about them? Which do you prefer? Do you think there’s a better approach or some steps can be changed in a more efficient way? Other examples: dev-perl/XML-Tidy: # We have to strip trailing letters in version and then apply cpan mangling rules XML-Tidy XML::Tidy sys-fs/dfc: # Download hosting sux and have download id in url http://projects.gw-computing.net/projects/dfc/files /attachments/download/[0-
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On Fri, Aug 10, 2012 at 4:45 AM, Luca Barbato wrote: > The whole point of the debate should be if easier to have systemd split > itself in usable components so people with certain focuses could > leverage it on linux and replace those on non-linux (apparently not a > chance) or have what we currently have and works decently and hopefully > be compatible (so have a compatible interface for user-daemons, a > compatible dbus interface for the desktop integrations and so on), not > which project we should help to kill the others. I understand where you're coming from, but keep in mind that upstream the debate is more along the lines of what else to integrate, not what to split apart. There is also little interest in supporting non-linux systems with systemd - I don't think anybody working on it uses anything but linux, and I think one of their goals is to not be held back by features not available elsewhere. That might make it more of a niche solution, but it is a niche that probably includes almost all of the boxes running a typical linux distro (servers, desktops, etc - not toasters, phones, DVRs, etc). Things like Prefix or FreeBSD are a very low in market share. In any case, this list is really the wrong place for such a debate, since nobody who has any power to change anything is listening. The success/failure of systemd will have almost nothing to do with how Gentoo adopts it, it is already moderately well-supported on Gentoo as a non-default, and while there are concerns about how udev/etc is packaged and where a few things are installing their files, for the most part nothing is broken. Some purists are concerned that whatever rc system they're not using is sticking files on their system that don't do anything, and that they can't control this, and that seems to be a fault with all of the options, and most of the packages in the tree that install init scripts. There is also quite a bit of people calling each other's babies ugly, which isn't terribly productive or helpful for the community. Rich
Re: [gentoo-dev] [RFC] euscan: Need to add more upstream info in metadata.xml
Having done some debian packaging for work, I find watch files from debian really helpful. Changing the format to a XML compatible one does not seem like a hard work so I'll probably leave that up for others to discuss. Since you are proposing this, a side question is: Why should we write SRC_URI in ebuilds if that info is now available in metadata.xml ? (granted that we might still want to keep over-riding this information in ebuilds) -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] SRC_URI in metadata.xml
On Fri, 10 Aug 2012 14:03:23 +0200 Gilles Dartiguelongue wrote: > Since you are proposing this, a side question is: > Why should we write SRC_URI in ebuilds if that info is now available > in metadata.xml ? (granted that we might still want to keep > over-riding this information in ebuilds) 1) The information in metadata.xml is inaccurate, it's a hint. When it fails, nothing of value is lost since the ebuild (supposedly) has what you want. 2) SRC_URI is precise. 3) SRC_URI can change over time, and across versions (even with all the variables in place). 4) Backward compatibility. 5) The inversion of your question: Why should we start handling SRC_URI outside ebuilds and eclasses? Or, how would that be practical, advantageous, an improvement on the current situation. jer
Re: [gentoo-dev] SRC_URI in metadata.xml
On 10/08/2012 07:21, Jeroen Roovers wrote: > 3) SRC_URI can change over time, and across versions (even with all the >variables in place). I agree with Jeroen here — in particular see things that come from alioth such as sys-apps/pcsc-lite and app-crypt/ccid: the SRC_URI actually has to change for each ebuild because there is one extra number that is used... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: virtual/libudev
Michał Górny schrieb: > On Tue, 10 Jul 2012 14:24:27 -0500 > William Hubbs wrote: > >> On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote: >>> Hello, all. >>> >>> Since nowadays udev is bundled within systemd, we start having two >>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making >>> the long story short, I would like to introduce a virtual for >>> libudev which would pull in either of those two. >>> >>> There are three USE flags used in conditionals when depending on >>> udev: >>> - gudev - for glib wrapper on udev, >>> - hwdb - to pull in hwids, >>> - static-libs. >>> >>> The former two were previously provided by 'extras' USE flag, >>> and the third was unconditional. >>> >>> I'm attaching an example virtual/libudev which does the job. Sadly, >>> because of the 'extras' compatibility it's a big ugly conditional. >> >> I'm going to ask here, because of the discussion on IRC, that you not >> commit this yet. There are issues still we need to work out wrt >> packaging systemd and udev. > > So, can I commit the virtual and finally start fixing people's systems > or are we going to discuss this to the day when other options are no > longer a possibility and virtual will be necessary? > > You seem still not to understand that upstream *does not care*. > And either way, merging udev and systemd will result that two, four or > six months from now users will need to manually re-adjust their @world > to have the packages split again. > I wrote it the last time you asked and i write it this time again: NO! Beside that, the last time i wrote you a mail about this topic, where you did not respond at all. So please read it again and answer it. Such change should be properly checked, before we even think about the idea of such a switch. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Questions about SystemD and OpenRC
Michał Górny posted on Fri, 10 Aug 2012 09:43:26 +0200 as excerpted: > On Fri, 10 Aug 2012 05:04:40 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted: >> >> > Or anything else what can be spawned for shell. And a lot more what >> > you won't expect. And guess what, people are actually doing crazy >> > things with it because someone forgot to tell them how a init.d >> > script should work. >> >> Sounds interesting. A couple quick links to examples of what you had >> in mind would be nice. =:^) > vdr is a first example which comes to my mind. They workaround program > configuration limitations and the init.d scripts become a complex > extra-configuration parser + plugin loader. Well, another thing here is > that upstream AFAIK is not willing to cooperate to fix their config > parsing. > > 'oldnet' is an another example. I'm not saying it should go; I'm saying > it should be a stand-alone executable called from the init.d script. > > Last time I looked, squid init.d was performing post-inst in start(). > Many users may find that beneficial but that's not what init.d scripts > should be doing. Thanks. (As I said my intent wasn't to start a subthread on it, but just to see where you were going with the comment, as it was rather opaque to me as it stood. Oldnet was an especially useful example here given that I run openrc- to more closely follow individual commits, and I've traced and reported a few bugs in oldnet over the years. Now that I know where that comment was going, I'll shutup and contemplate.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] RFC: virtual/libudev
On Fri, 10 Aug 2012 19:33:10 +0200 Thomas Sachau wrote: > Michał Górny schrieb: > > On Tue, 10 Jul 2012 14:24:27 -0500 > > William Hubbs wrote: > > > >> On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote: > >>> Hello, all. > >>> > >>> Since nowadays udev is bundled within systemd, we start having two > >>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making > >>> the long story short, I would like to introduce a virtual for > >>> libudev which would pull in either of those two. > >>> > >>> There are three USE flags used in conditionals when depending on > >>> udev: > >>> - gudev - for glib wrapper on udev, > >>> - hwdb - to pull in hwids, > >>> - static-libs. > >>> > >>> The former two were previously provided by 'extras' USE flag, > >>> and the third was unconditional. > >>> > >>> I'm attaching an example virtual/libudev which does the job. > >>> Sadly, because of the 'extras' compatibility it's a big ugly > >>> conditional. > >> > >> I'm going to ask here, because of the discussion on IRC, that you > >> not commit this yet. There are issues still we need to work out wrt > >> packaging systemd and udev. > > > > So, can I commit the virtual and finally start fixing people's > > systems or are we going to discuss this to the day when other > > options are no longer a possibility and virtual will be necessary? > > > > You seem still not to understand that upstream *does not care*. > > And either way, merging udev and systemd will result that two, four > > or six months from now users will need to manually re-adjust their > > @world to have the packages split again. > > > > I wrote it the last time you asked and i write it this time again: NO! > > Beside that, the last time i wrote you a mail about this topic, where > you did not respond at all. So please read it again and answer it. > Such change should be properly checked, before we even think about > the idea of such a switch. I'm pretty sure I replied to every mail I got from you. And please remind me: what is your relevance to systemd or udev? What do you know about history of those packages? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] euscan: Need to add more upstream info in metadata.xml
On Fri, Aug 10, 2012 at 2:03 PM, Gilles Dartiguelongue wrote: > Having done some debian packaging for work, I find watch files from > debian really helpful. Changing the format to a XML compatible one does > not seem like a hard work so I'll probably leave that up for others to > discuss. > > Since you are proposing this, a side question is: > Why should we write SRC_URI in ebuilds if that info is now available in > metadata.xml ? (granted that we might still want to keep over-riding > this information in ebuilds) It's not (only) SRC_URI, sometime it's completly different, sometimes would contain only versionmangle since SRC_URI contains enought informations for euscan... SRC_URI serves a totally different purpose :). -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] SRC_URI in metadata.xml
On Fri, Aug 10, 2012 at 4:21 PM, Jeroen Roovers wrote: > On Fri, 10 Aug 2012 14:03:23 +0200 > Gilles Dartiguelongue wrote: > >> Since you are proposing this, a side question is: >> Why should we write SRC_URI in ebuilds if that info is now available >> in metadata.xml ? (granted that we might still want to keep >> over-riding this information in ebuilds) > > 1) The information in metadata.xml is inaccurate, it's a hint. When it >fails, nothing of value is lost since the ebuild (supposedly) has >what you want. > 2) SRC_URI is precise. > 3) SRC_URI can change over time, and across versions (even with all the >variables in place). > 4) Backward compatibility. > 5) The inversion of your question: Why should we start handling SRC_URI >outside ebuilds and eclasses? Or, how would that be practical, >advantageous, an improvement on the current situation. Right, our proposal is not here to replace SRC_URI, it's here to fix the cases where SRC_URI can't be sanely used to guess new upstream versions (strange mangling rules, unbrowsable directories, etc...). -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] SRC_URI in metadata.xml
On 10/08/2012 13:05, Corentin Chary wrote: > Right, our proposal is not here to replace SRC_URI, it's here to fix > the cases where SRC_URI can't be sanely used to guess new upstream > versions (strange mangling rules, unbrowsable directories, etc...). Yes I guess Jeroen was just saying why we shouldn't abandon it as Gilles proposed. FWIW for the rest it feels right to me. Although this starts to add up to the reasons why at least metadata.xml should be validated by schema, and not DTD. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: virtual/libudev
Michał Górny schrieb: > On Fri, 10 Aug 2012 19:33:10 +0200 > Thomas Sachau wrote: > >> Michał Górny schrieb: >>> On Tue, 10 Jul 2012 14:24:27 -0500 >>> William Hubbs wrote: >>> On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote: > Hello, all. > > Since nowadays udev is bundled within systemd, we start having two > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making > the long story short, I would like to introduce a virtual for > libudev which would pull in either of those two. > > There are three USE flags used in conditionals when depending on > udev: > - gudev - for glib wrapper on udev, > - hwdb - to pull in hwids, > - static-libs. > > The former two were previously provided by 'extras' USE flag, > and the third was unconditional. > > I'm attaching an example virtual/libudev which does the job. > Sadly, because of the 'extras' compatibility it's a big ugly > conditional. I'm going to ask here, because of the discussion on IRC, that you not commit this yet. There are issues still we need to work out wrt packaging systemd and udev. >>> >>> So, can I commit the virtual and finally start fixing people's >>> systems or are we going to discuss this to the day when other >>> options are no longer a possibility and virtual will be necessary? >>> >>> You seem still not to understand that upstream *does not care*. >>> And either way, merging udev and systemd will result that two, four >>> or six months from now users will need to manually re-adjust their >>> @world to have the packages split again. >>> >> >> I wrote it the last time you asked and i write it this time again: NO! >> >> Beside that, the last time i wrote you a mail about this topic, where >> you did not respond at all. So please read it again and answer it. >> Such change should be properly checked, before we even think about >> the idea of such a switch. > > I'm pretty sure I replied to every mail I got from you. > > And please remind me: what is your relevance to systemd or udev? What > do you know about history of those packages? > Please keep this on a technical level, neither relevance nor knowledge about history should matter here. Since you seem to have missed or forgotten my mails, let me copy it here again for you: >> As discussed on IRC, there is still no consensus for installing the >> udev files with systemd, which is the beginning for the block and the >> virtual. So we should first sort that point out, before we even start >> to think about an ebuild for an udev virtual. > > Do you have a technical or policy reason prohibiting me from maintaining > a systemd ebuild following the upstream policies? How about this simple one: The udev ebuild does already install udev, so why should we have another package also installing the same thing, resulting in a blocker, the need to switch from one package to another and the need for package maintainers to switch their dependencies? Since William already said, that he will move the udev installation to /usr/lib, i dont see any technical reason left to not simply depend on the udev ebuild. And if you fear issues about not knowing which parts to install, then just check the files installed by the udev ebuild, remove them from your systemd ebuild and you are done. > >> So for now: A clear no, i am against adding a virtual/libudev ebuild. > > Please give the rationale. I did above. So if you still want to install udev yourself, please give the rationale for doing so. And neither upstream naming nor a big upstream tarball nor the Makefile do force this, so please exclude those points. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
