On Thu, May 20, 2004 at 05:06:51PM +0400, Yury Konovalov wrote: > > Это понятно, так я (ниже) и предлагаю вытянуть максимум > > независимостей в отдельный *-devel. > > > %apache_datadir %_var/www > > %apache_htdocsdir %apache_datadir/html > > %apache_cgibindir %apache_datadir/cgi-bin > > %apache_webmaster webmaster > На мой взгляд это уже специфичные вещи. Нет, ну переименовать их в httpd_* или еще как более нейтрально, понятное дело. > Я исхожу из того, что разные ветки апачей не должны иметь один > и тот-же htdocsdir (какой апач наполнит его, если у каждого > свой контент для этого?) и cgibindir также имеет пару cgi, > предоставляемых самим апачем. Насколько понимаю, "свой" (неразделяемый) контент, по-хорошему -- исключение из правила. Опять же может иметь смысл держать его тоже в /usr/share -- это нечто неизменяемое, в конце концов. > На сколько я понимаю, предлагается более тесная интеграция > апачей, предполагающая объединение контентов и разделения > общего docroot. В свою очередь, предлагаю так далеко не идти > сходу, и для начала определить простую схему при которой апачи > смогут сосуществовать. А потом с ней героически сражаться? ;-) См. mod_ssl.spec свежего разлива. А ведь тривиальная вещь, казалось бы... > Это, например, может выглядеть так: > /var/www/ > | > -apache1/ > | > -html/ > -cgi-bin/ > -manual/ > -addon1/ > -addon2/ Что здесь? (ну manual понятно, хотя и он у нас обычно жил симлинком под html) > -apache2/ > | > -html/ > -cgi-bin/ > -manual/ > -addon1/ > -addon2/ И чем отличается то, что здесь? Бишь если я собираю webalizer -- куда он кладет свой контент? (собирать два webalizer просто так -- не буду :) > -shared-cgis/ > | > -mailman > -one_more_apache_favour_ignoring_project А не большинство ли их такое? И нет ли смысла тогда здвать это просто cgi-bin/ ? :) Опять же, разделяемый html -- это то, на что (сейчас) заряжен default vhost. Было бы разумно вообще исключить запись туда вебмастером (права+README) и тут же "удобнизировать" создание нормального виртхоста -- в т.ч. дефолтного, но не здесь, в пакетной местности. > -vhosts/ > | > -vhost1/ > | > -htdoc/ > -log/ > -cgi/ > -vhost2/ > ... Тут вопросов нет. > > > Все, что специфично для данной версии Apache - manual, > > > default docroot, доки модулей, специфицные cgi и т.п. > > А у нас есть настолько специфичные cgi, или речь о том, чтобы > > обеспечить эту возможность? Просто получается множество > За то, что уже есть в сизифе не скажу (там просто не откуда > взяться apache2-specific пакетам:), но я знаю такие пакеты, > которые будут предоставлять cgi, зависящие от модулей, > имеющихся только во втором апаче (WebAuth/WebKDC как пример). С другой стороны -- и что плохого, если они окажутся в разделяемом cgi-bin? Максимум взорвется не под тем (и то уже дав намек требованием "того"). > > мощностью Nflavour x Nvirthost. > Я бы учёл, что на практике: > 1) Apache2 на данный момент решение скорее дополнительное к Apache1. Да, но уже не единственное. Сам тоже собираюсь все boa опакетить :) > 2) из первого вытекает, что большинство хостеров будут > использовать A2 в проксируемом посредством A1 режиме (что по > умолчанию действует в моем пакете почти также как и в > apache-mod_perl) А, вот как. Не учел. Т.е. именно одновременная работа... > 3) В свою очередь, из второго вытекает, что A2 будет > действовать лишь для малой части виртхостов (или даже части > контента виртхоста), а центральный cgi-bin дотачивается > по-месту. Т.е мы здесь все-равно не угадаем. Ммм.... хорошо. А наблюдались несовместимые снизу вверх CGI? > > > Вообщем все то, что попадет туда само-сабой, если изменить > > > apache_home. > > Э, не. Тогда туда и разделяемого много упадет. > Можно сказать, что это даже хорошо -- пусть сначала пакет > осознает свой контент разделяемым. Так постепенно все > образуется и не будет резких изменений. Я имею ввиду, что > пакеты(основанные на apache), даже без внесения изменений будут > собираться под A1, пока мантейнер не решит, что можно > предоставлять что-либо в %srv_dir Кажется, потерял контекст, но имелось в виду, что сейчас скорее типично использование /var/www, нежели %_apache/home: RPM/SPECS/classic> grep var/www * | cut -f1 -d: | uniq | wc -l 29 RPM/SPECS/classic> grep %apache_home * | cut -f1 -d: | uniq | wc -l 3 (это apache, packhouse, phpPgAdmin) Т.е. 1) дело не в макросах :-) и 2) незачем априори полагать, что софт является apache1-specific. В последнем могу быть неправ. > > > > Кстати, тут еще Большаков справшивал про макросы сегодня в > > > > свете желания собрать tclhttpd. Т.к. "общей частью" вопроса > > > > я тут вижу не виртхосты как таковые, подумал -- может, это > > > > httpd-common и httpd-devel? > > > > Вопрос чуть ли не вкуса, но чтоб уж потом не трогать. > > > Тут мне не совсем понятно -- эти пакеты будут предоставлять > > > макросы для обоих версий apache? > > Частично. Каждый апач может носить с собой оставшуюся часть > > сугубо своих макросов. > Это пересекается со сказанным в начале. Да, конечно. Особенно с учетом того, что я *подразумевал* там замену apache обобщенным httpd :-) > Здесь только хотелось сказать, что на данный момент, если > отказаться от идеи одного docroot'а, следует определить тот > список макросов, достаточный для сборки модулей, и использовать > одинаковые имена, при взаимно вытесняющих -devel. А что тогда делать с webalizer? ;-) Просто когда народ очень так интересовался, почему mod_perl так экстравагантно заведен -- я подумал-подумал, чего может стоить его вытаскивание из-под этой схемы (даже если течь не будет и вообще все замечательно теперь), и объявил, что делать этого в 1.3.x -- не собираюсь. Соответственно если apache2 будет этаким довеском, то когда ему придет времябыть _платформой_ -- изначальная завязка на "неполноценность" и обособленность может сыграть злую шутку. Хочется по возможности избежать в его будущем нетривиальных скриптов по обеспечению миграции и продумывания ночами %triggerpostun... > > > Я себе это представлял так: при сборке модуля, например, > > > под apache1 - в buildreq указывается apache-devel, а при > > > желании собрать под apache2 - соответственно apache2-devel. > > > Devel-пакеты должны выпихивать друг-друга ибо макросы > > > должны быть одноименные для упрощения "кросапачной:)" > > > сборки. > > Ммм... угу. Но модули и контент-часть -- штуки разные по > > степени зависимости от сервера/версии. > Иногда и с модулями идёт контент, который зависит от версии A. Кстати, можно пример? (документация не в счет, с ней понятно) > > Если забегать в раздел мыслей по web packaging policy, то мне > > очень нравится размещение скриптов под /usr/share и > > подцепление их или алиасами, или симлинками. Особенно в > > свете +/- распухшего хостинга с приличной дупликацией кода, > > который не изменяется per-instance, но порой дыряв и хорошо > > бы, чтобы его можно было обновлять одним махом. > Да - это конечно мечта, но пока у меня нет чёткого > представления. Похоже, на данном этапе это скорее усложнение. А посмотрите дебиановские пакеты. Там есть и, например, возможность сказать, в какую именно БД ходить создавать штатные базы, и это очень симпатичная автоматизация нудной и тупой "деятельности". > > Здесь для меня главный вопрос именно с выделением > > неизменяемой части (остальное симлинкуется куда-нибудь в > > /var), а также с определением реально неизменяемой части. > Да в этом все и дело. Оно, конечно, per-webpackage, но... Хотя с другой стороны -- если бы rpm2 ориентировался на ситуацию "все равно все будут хачить по месту", так бы он и остался таром на стероидах -- большим, но глупым. Так что будем ориентироваться на mature web software. Пилимое (плохое) -- в конце концов, руками по старинке разложить можно, раз все равно пилить. > По моим наблюдениям, админы часто переносят содержимое > web-пакетов в свой каталог, где хачат напильниками и > выкладывают. Видимо уже есть "доточенные" вэб-пакеты, > обновление которых на 99% пройдёт без негативных последствий -- > их и искать. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/